OIDC アーキテクチャセッション: 日経 ID 基盤刷新プロジェクト

この文字起こしは、2023 年 12 月 12 日に開催された Authlete Customer and Partner Meetup 2023 のプレゼンテーションのひとつです。 日本経済新聞社 プラットフォーム推進室 ソフトウェアエンジニア 淵脇誠さまに、OpenID Connect のアーキテクチャや、運用基盤の選定（AWS）と構成例、また次世代認可基盤への移行に関してお話しいただきました。

はじめに

日本経済新聞社の淵脇です。よろしくお願いいたします。本日は、OIDC アーキテクチャーセッションで、弊社が行っている日経 ID 基盤刷新プロジェクト、Melissa（メリッサ）についてお話しいたします。

自己紹介

最初に、わたし及び、わたしの所属する日経 ID チームについて、軽く紹介させていただきます。

わたしは 2020 年に日本経済新聞社に入社しまして、日経 ID の開発をずっとやっています。AtCoder という競技プログラミングを、趣味でけっこうやっています。もしやっている方がいらっしゃいましたら、お声がけしていただければと思います。

わたしの所属する日経 ID チームは、Melissa という刷新プロジェクトの開発チームです。総勢10 名ほどで、スクラムチームを組んで、フルスタックな開発をしています。

Melissa はギリシャ語でミツバチを意味します。ミツバチは、生態系におけるインフラの役割を担います。ID 基盤につきましても、日経のいろいろなサービスのインフラを担っていけたらという思いから、このプロジェクトコードをつけました。

日本経済新聞社における ID 戦略

日経 ID は経営戦略の一部

このセッション自体は OIDC アーキテクチャセッションとなっていますが、アーキテクチャに入る前に、日経 ID 戦略の背景と、加えて Melissa がどう始まったのかについて、お話ししていきたいと思います。

まず、日本経済新聞社における日経 ID の位置付けです。

4 つの経営ドメイン

日本経済新聞社の事業ドメインとして、News & Insights と、Brand Communication、Decision-making、Experienceという、4 つの経営ドメインを定義しています。

それぞれ、News & Insights は、非常に馴染み深い、いわゆる新聞、報道機関としての仕事です。それに加えて、そこに載っている広告などの Brand Communication。また、たとえばエグゼクティブが経営判断をする材料とかをやるための Decision-making。そして、個人のキャリア形成などの Experience。こういったところに注力していくことを、中期経営計画などで定めています。

ユーザーを横断的に理解するための ID

こんな感じで、報道機関でありながら、いろんな分野にサービスを張り巡らしていくために、これらを統合して見渡し、ユーザーを横断的に深く理解する必要が出てきました。それを実現する基盤が日経 ID です。

よって、日経 ID は、単純にログインを行う基盤というだけではなく、経営戦略の一部として扱われている点が重要です。

事業環境とのギャップ

旧基盤は 2010 年に構築

ここにオレンジの枠で描いてあるのが、旧基盤です。2010 年、OpenID Connect 仕様がまだ正式版ではなかった時代に、日経 ID はOpenID Connect を実装した基盤を提供しており、その稼働実績が 10 年以上ありました。

ところが、当然 2010 年に作ったものですので、いろいろレガシーな部分が出ていました。また、昨今の最新のセキュリティ事情への対応だとか、新しい認証のトレンドへの追従が非常に難しくなってきたという課題があります。

新たな要件への対応

とくに日経 ID の新ミッションとして、赤枠で囲ってあるような「ポートフォリオ最適化」などを、非常に求められてくるようになりました。そして、日経 ID の基盤自体に高いアジリティが求められるようになってきた現実があります。

ですので、これを実現するために新しいことを始めなきゃね、というところが起点になっています。

ID 基盤の完全刷新

そこで、この下の部分の、とくにアジリティ（新しい要件に対する変更容易性）を確保するために、基盤を完全に刷新しようと始まったのが、この Melissa プロジェクトになります。他に求められることについては、様々なチームと協業することによって、経営からの日経 ID に対する期待を満たし、この全体をカバーしていくことを目指しています。

多岐にわたる要求

基盤の刷新にあたっては、要件定義が必要になります。このときには、皆さん、言いたい放題言ってきます。たとえばここに書いていますが、レガシー機能の互換性であったりとか、サービス継続性であったりとか、あともちろん ID 基盤としてのプロダクトの価値向上といったものが求められるわけです。こんな感じでいろいろ要求が出てきます。

レガシー機能の互換性

もともとサポートしていたのだからこれも引き続きサポートしてね、というのも当然出てくるわけです。この基盤自体はかなり古いので、セキュリティ上問題がある機能や、OIDC の仕様に違反している機能とかも、もともとあったのだから当然やってくれるよね、みたいな要求は、まあ出てきます。

サービスの継続性

さらに、サービスの継続性も、ID 基盤には非常に強く求められるものです。もちろんIDが止まっちゃうとすべてのサービスが使えなくなってしまうので、無停止での移行といったことも出てきます。

プロダクトの価値向上

それに加えて、一番やりたかったのは、ID 基盤としての価値向上です。

基盤刷新におけるシステム要件定義の難しさ

基盤刷新におけるシステム要件定義の難しさはいろいろあります。とくに、技術的挑戦が受け入れられにくいであるとか、事業継続性の要求が極めて強く安定思考である、といったことがあります。

今回の例では、元々 2010 年に作った基盤が残っているので、それを多少アップデートすればいいのではないか、みたいな圧力もあるわけです。そうすれば一応安定はしますし、挑戦とかもないので、これまでの使い心地はそのまま続きます。一方で、もともと一番やりたかったアジリティの向上とかは、かなりやりにくくなってしまいます。

なので、安定して稼働するシステムが正義だよということで、既存システムの改修で終わりがち、みたいなところがあったりします。

基盤刷新での要件定義にありがちな結論

そういうことを繰り返していくとどうなるか。ここに緑の枠で囲ってあるんですが、結果としてレガシー機能の互換性とサービスの継続性にフォーカスし、プロダクトの価値向上につながらないといったことが、けっこうあります。

これはプラットフォームに限らず、基盤システムとか基盤系では、かなりよくある話なのかなと思っています。プロダクトの価値向上として、要求を積んだけれども結局要件定義の段階で落されちゃったみたいなところは、けっこうある話かなと思っています。

基盤刷新の方針策定

こういった要求とか、ID 基盤チームの思いを考えつつ、基盤刷新にどのようなミドルウェアを使うかを検討しました。ここにいくつか製品を並べています。もうちょっと選択肢としては多かったですが、代表的なものを並べています。

Authlete は「エンジニアフレンドリー」

まず Authlete については、一般的には SaaS での提供がメインかなと思いますが、オンプレミス版もあります。オンプレミス版は、Authlete 社からアプリケーションを提供してもらって、それを自分でホスティングする方法です。それも選択肢に加えています。

我々はどちらかというとソフトウェアエンジニアが集まったチームなので、その観点で評価すると、やはり Authlete が非常にエンジニアフレンドリー、とにかくぱっと見で作りやすそう、というのが第一印象でした。たとえば、Authlete 社のサイトに並んでいる API ドキュメントなどを見て、実際うちのシステムを刷新したときにどういうアーキテクチャになるのか、ある程度経験を積んだ人ならほぼ一瞬でわかるような、そんな非常にいいアーキテクチャだな、という印象でした。

他の製品に感じた「ベンダー開発前提の雰囲気」

一方ここに書いている、製品 A とか製品 B に関しては、ソフトウェアエンジニアの観点からは、非常になんていうか、とっつきにくいというか、ある程度ベンダーを入れた開発を前提にしているんだろうな、みたいな雰囲気があって、ある意味ブラックボックスみたいな雰囲気でした。

最終的に Authlete を選定

このような比較を経て、最終的に、疎結合で、高凝集で、イミュータブルなサービスであることとか、最新の標準仕様を実装したサービスであるとか、コスト面の競争力とかを考え、ソフトウェアエンジニアからも強く要望を受けて、最終的に Authlete を選ぶことに決まりました。

Authlete を選ぶことで、我々がもともと目指したかったアジリティ性の向上にフォーカスできるのではということで、非常に期待していました。

Authlete を選定したことを要件合意の説得材料に

その結果、要件レベルとしては、Authlete で対応できないものはばっさり切り捨てましょう、ということで、レガシー機能の互換性はがんばって切り捨てる方向に動きました。

これはソフトウェア開発、とくに「サービス開発あるある」ですが、たとえば皆さんが AWS とか Azure とかを使うときに、「それは AWS では対応してない機能です」というのは、レガシーな要件を落とすための非常に強い説得力になるところがあると思います。

ここまでで、日経 ID の戦略と、Melissa に至るまでの背景をお話ししました。

日経 ID 基盤刷新プロジェクト

次に、この Melissa プロジェクトのアーキテクチャについてお話ししていこうと思います。

Authlete のオンプレミス版を選択

先ほど、Authlete にオンプレミスという選択肢があるという話をしました。これは Authlete 社の Web サイトにもプランとして載っています。Authlete 社のクラウドサービスで提供する SaaS のプランと、Authlete 社からアプリケーションをいただいて自分たちでホスティングするオンプレミスプランがあります。

どちらがいいかは非常に悩ましいところですが、ひとつはコスト面です。あとメンテナンスについて、オンプレミスプランなら自分でホスティングするので、タイミングを自由に制御できます。またオンプレミスプランについては、どのクラウドを使うかといったことは自由です。自社でノウハウのある AWS スタックを使うことも可能になります。

そういったことを検討した結果、日経ではオンプレミス版を選択しました。つまり Authlete 社からアプリケーションファイルをいただいて、それらを自分でデプロイして運用するかたちです。

技術力を背景に内製を選択

さらにもうひとつ、決めるべき要素として、内製 or 外注といったものがあります。

内製も外注も、やはり一長一短あるというのが実際のところです。内製だからいいとか、外注だから安心とか、そういったことはないわけですね。

たとえば、アジリティ（変更容易性）に関して言えば、内製の場合ですと、「開発チームの技術力を確保できれば高い」という、条件付きで高い、みたいな感じになります。外注だともちろんこれは低くはなるんですけども、ただ内製だからといって、アジリティが必ず高いかというと、それはチームの実力によるところがあります。

開発コストについても、外注の場合は変動費が高くなるとか、内製の場合は社員を抱えないといけないので固定費が高くなるとか、そういったリスクがあります。

これらは会社によります。幸い日経 ID チームは、エンジニア採用に成功していたので、ある程度エンジニアリングリソースが確保できる状況でした。

そういうこともありまして、内製のメリットを活かせると判断し、内製を選択しました。

強力な ID 基盤開発体制

アーキテクチャ

Authlete のオンプレミス版をどういう風にAWS上で動かしているかの、アーキテクチャ図がこちらになります。

認証の部分は AWS の ECS（コンテナベースの実行基盤）で稼働しており、それと同じように、Authlete も ECS で動かしています。そこに、マネージドデータベースである Aurora MySQL をつなげて、Authlete を運用しています。

Authlete のオプションとして Redis を使うという選択肢があり、何か高速な応答が必要であれば Redis をキャッシュにする方法もあります。しかし今のところは、Aurora MySQL の性能がある程度高いこともあり、Redis は入れずに使っています。この図に Redis がありますが、これは認証の方で使っているものでして、Authlete の方は MySQL + ECS のコンテナ基盤という、非常にシンプルな構成で動かしています。

また、ここに乗っているもの以外にも、Datadog とか PagerDuty とか、運用に必要な各種 SaaS を使いまして、日経のエンジニアのみで運用までカバーしています。

標準を軸に「認証」を実装

Authlete を使うとひとつ出てくるのが、認証については自前で実装しなければいけないという話です。ただ、これについてはけっこう方針を立てやすいです。なぜなら、OpenID Connect の仕様が、意外と認証についても少し踏み込んで決めているんですね。ここに一例を並べています。

prompt=none

たとえば、ログインをせずに認可をしたいという要件がたまにあったりします。これは組み込みの WebView とかで、既に認証は終わっているから、認可コードだけ発行してくれといった話です。そういうユースケースに備えて、OpenID Connect では、prompt=none と言われる認可リクエストのオプションを用意しています。

OAuth 2.0 Token Exchange

あと、モバイルアプリの中の WebView の中で、ログインセッションを共有したいといったことがあります。ここには Token Exchange と書いていますが、その派生で Native SSO という仕様がありまして、それを使うとシングルサインオンができる、といったものが OIDC 系の中でいろいろ定義されているわけですね。

旧基盤との併存

もうひとつ重要な話です。先ほどの DX セッションでは、ゼロから指数関数的に伸びたサービスの話を聞きました。我々の要件はその逆でして、もともとユーザーベースがいるところをどうやって切り替えるかの話になります。

1,000万人規模の「旧日経 ID 基盤」を全部停止して、一気に切り替えることは、非常に難しいです。それをやる案もあったのですが、リスクが高すぎるので、徐々に切り替えていくという方式にしました。

Relying Party ごとに異なる事情

これは ID 基盤自体だけではなく、ID 基盤を使っているクライアント（Relying Party）側の事情もありました。

開発チームが Relying Party ごとにいるのですが、対応できる工数がそれぞれバラバラです。ある開発チームは外注のベンダーを使っているから予算確保してから発注しなきゃいけないとか、別の Relying Party は非常にエンジニアリングリソースがあるので即日対応できるとか、そういった事情がいっぱいあるわけです。

イントロスペクションを工夫

そのため、「旧日経 ID 基盤」と「新日経 ID 基盤」は、基本共存するという方式でいくことにしました。そして、Authlete は柔軟に対応できました。「新日経 ID 基盤」から、「旧日経 ID 基盤」と Authlete の両方にイントロスペクションリクエストを出してみて、どちらかでオッケーだったらオッケー、みたいな実装をすればかんたんに共存できるわけです。

実際には、オートグロインを組み合わせてユーザーにあまり意識させないようにするとか、かなり細かいテクニックがありますが、それらを組み合わせると、このブラウザから見て、「新」なのか「旧」なのかをまったく意識せずに、徐々に切り替えていくことができます。

Authlete の効果

Authlete を使って 2 年ほど開発を継続して、感じられる効果がいくつあります。ここに 3 つ挙げています。

独自仕様や非標準仕様からの脱却

まず、レガシーからの脱却が確実に進んでいます。OpenID Connect の当時のドラフト版にはあったけど正式版になって削られたような部分や、そもそもセキュリティ的にまずいものも、どんどん脱却が進んでいます。

クライアント設定のメンテナンス性向上

あとこれはちょっと細かい話ですが、「Client as a Code」、これはわたしの造語ですけれど、Relying Party のクライアント設定のことです。これを、Authlete の Terraform を使ってコードベースで管理できます。いままでの旧基盤では Web の GUI からやっていたので、バージョン管理が難しかったです。コードベース管理によって、バージョン管理とか revert（元に戻す）とかが非常にやりやすくなり、メンテナンス性も上がったかなと思っています。

標準仕様の理解を深めるモチベーションに

あともうひとつ、開発チームの、標準仕様への解像度ですね。これはもう非常に上がったと思います。やはり Authlete を理解して使わないといけないので、OIDC に関する仕様はそうですし、それにプラスして、Authlete は認証に関するところは何も提供しないので、じゃあどうやったら業界標準でできるのかといったところで、たとえば他社の認証の実装を研究して、業界標準を理解しよう、というモチベーションはかなり高くなったと思っています。

日経 ID の今後

最後に、今後の日経 ID について少しお話ししたいと思います。

Passkeys の導入

これはほとんど個人的願望ですが、Passkeys は、いつかやりたいなと思っているところです。

日経のユーザー層は年齢層の高い人も多いので、複雑なログインをしてください、つまり MFA を設定してくださいといったものに対して、非常に抵抗のある方が多いわけですね。パスワードに複雑なものを使ってくださいと言っても、なかなか難しいところがあったりします。

そういったところでも、高い UX を提供できる Passkeys は、かなり我々のユーザー層に合っているのではと思っています。また会員数が非常に多いため、単純なパスワードが大量にあったりすると、インシデントの影響もかなり大きくなってしまいます。

モバイルユーザーが多く、Passkeys 導入の下地ができているなど、非常にポテンシャルが高いです。このあたりをやっていきたいと思っています。

ちなみにチームの中で、プライベートで Passkeys を実装した人が、エンジニア 8 人中 2 人くらいいます。それくらい、やりたいという熱量が高まっているところです。

End

ご清聴、ありがとうございました。