Oktaから内製IdPへの認証基盤移行（第2回）

はじめに

こんにちは、IT本部IT戦略部テクニカルオペレーショングループの利根川です。

DeNAでは、全社的な認証基盤の刷新を進めており、その一環として内製 IdP (Identity Provider) の構築に取り組んでいます。

前回の記事では、既存の認証基盤からの移行を決定した背景と、内製化によって目指す姿についてお話ししました。

読者の皆様からは、その壮大な挑戦に対して多くの関心を寄せていただいています。

本記事は、その取り組みの第2回として、「どうやって内製 IdP を作り上げたのか」 という具体的な構築プロセスに焦点を当ててご紹介します。

DeNAでは、セキュリティや運用品質上、極めて重要なこの認証基盤の内製化という大きなプロジェクトを、少人数かつスピーディーな体制で推進してきました。

その背景には、開発におけるAIの積極的な活用や、担当者それぞれの専門知識を最大限に活かした役割分担があります。また、初期設計から実際の開発フェーズに至るまで、どのように計画が進化していったのか、その過程でどのような意思決定が行われたのかについても掘り下げていきます。

この記事を通して、読者の皆様には、内製 IdP の具体的な構築プロセス、DeNAにおける挑戦的な開発体制、そしてAIがどのようにプロジェクトに貢献したのかといった知見を得ていただけると考えています。

なお、この記事では私が書いている関係上、設計・運用分野に関する話題が多めになります。

開発における注意点や昨今のセキュリティ技術に関して触れる部分はさほど多くありませんが、IDaaSやIdPに興味のある情報システム部門の方々、そして認証技術に関心を持つセキュリティエンジニアの皆様にとって、本記事が少しでも参考になれば幸いです。

体制

まず、内製化にあたりプロジェクトの体制をご紹介します。

全体的な方針決定や、予算管理などを行うプロジェクトマネージャーにはIT戦略部副部長
開発チームとして、セキュリティ部セキュリティ技術グループからメイン1名、スポットで補佐3名
設計・運用チームとして、我々テクニカルオペレーショングループから3名
品質管理チームから4名（兼務）
インフラチームとして3名（兼務）

という非常に小規模なメンバーで活動しています。

今年2月のAI Dayであった「AI ALL IN」宣言にもあった、「10人1組でユニコーンを量産」に近しい成果を、AIが進化する1年の間に実現した例となります。

（無論、外販を念頭に置いていないので、営業や経理・法務など本来の運用人員では10人を超えてしまいますが・・・）

このメンバー数で内製 IdP を作り、運用するにあたって、生成AIの活用は大きく貢献していますが、それは後程触れたいと思います。

設計思想と技術選定

内製 IdP の構築において、前回お話した他製品評価の過程で必要な機能は見えていましたので、まずはそれをもとに機能構成を図解しました。

その中でUIが必要なもの、DBが必要なもの、外部連携が必要なもの、など色分けして、順次開発を始めたのが2024年12月頃です。

技術選定

認証基盤という特性上、使っている言語やサービス構成に脆弱性が見つかったときに攻撃対象となってしまうため、細かい話が出来ない点はご理解ください。

技術選定においては、以下の4点を重視しました。

構築が容易であること
シンプルなデータ構造であること（IdPは複雑なデータを永続的に保管しない）
クラウドネイティブであること
自動化を前提とした仕組みであること

これらを踏まえ、社内でさまざまなサービスを開発・提供している当社だからこその構成で稼働しています。

なお、一部はOSSモジュールを使用していますが、基本的にUIから裏側まですべて内製しており、KeyCloakなど有名なIdP OSSを利用することなく、構築されています。

初期設計の概要と方針

初期設計の段階で、認証基盤の中核機能と、ユーザー管理や認可管理を行う IGA (Identity Governance and Administration) との役割を明確に切り離すことにしました。

IGAの切り離し
- 内製 IdP は、ユーザー認証そのものに特化し、シンプルさとパフォーマンスを追求しました。これにより、認証プロセスの高速化と堅牢性の向上を目指しています。
IGAとの連携
- 一方で、IGAとはAPIを通じて内製 IdPが取得する方針を取りました。この分離により、それぞれのシステムが独立して進化できる柔軟性を確保しています。

このIGAについては

の記事でご紹介しているHERBになります。

記事の中で登場する「HERBのアカウント情報を利用したい社内システム」のうち1つが、今回の内製 IdP となります。

この方針は、各コンポーネントの責任範囲を明確にし、開発の複雑性を低減するとともに、将来的な拡張性やメンテナンス性を高める狙いがありました。

そのため、一部の社内システムに利用していたユーザープロビジョニングを、OktaからHERBに移行したのちに、認証基盤を内製 IdP にする、という流れも、この段階で自然と決まっていました。

設計における担当者の役割と専門知識の活用

少人数体制でプロジェクトを進める上で、各メンバーの専門知識を最大限に活かした役割分担は不可欠でした。

開発者
- アプリケーション、DB、各種処理ロジック全般の構築を担当しています
- セキュリティ技術の分野で業務をしてきているため、ライブラリやコード自体の脆弱性に十分な知識を有しています
- 認証部分についても構造を熟知していることから、IdPを内製する上で欠かせない存在です
設計者
- Oktaの運用を行っていたメンバーで構成され、UI・機能要件定義を担当しています
- 認証に関する基礎的な知識だけでなく、日常的な運用においてユーザーがどういったことをするか、何を望んでいるかを熟知しています
- 運用において課題に感じていること、自動化できることなどを機能化することで「SaaSにはない利便性」を実現することができます
品質管理
- テスト戦略の策定、セキュリティテストの実施を担当しています
- 認証基盤の信頼性を確保するための厳格な品質基準と、セキュリティ脆弱性に対する深い知見が不可欠です
- DeNAが提供する数々のサービスを検証した知見が活きています

各担当者が自身の得意分野に集中することで、効率的に高品質な設計を進めることができました。

設計におけるAIの活用: 活用箇所

少人数での開発を成功させる上で、AIはまさにプロジェクトの救世主とも言える存在でした。私たちは、様々なフェーズでAIを活用し、その効果を実感しています。

開発におけるAI活用
- GitHub Copilotによるコーディング補助で、コーディング時間の短縮に役立ちました
設計時の技術調査
- 機能を設計する際に、無論開発者であるセキュリティ技術のエンジニアに聞けばそれ相応の答えは得られますが、それでは設計・運用側の知識が伸びませんし負荷になります
- 一般的な認証に関する知識（RFCやOASISなどのドキュメント、認証技術にかかわる用語や構成など）はGeminiをかなり活用できました
フローの可視化
- 機能設計で様々なユースケースがある場面において、処理パターンは複雑化します
- その処理を考える際に、当社内でDifyをベースに24新卒の新入社員たちが作った「SAI」の業務インタビューアプリというものが大活躍しました
- 考えている処理条件を伝えると、それでフロー図を起こし、さらに深堀をするインタビュー形式でフローを明確にしてくれます。厄介なロジックを考えて図にしてくれることで、設計段階でユースケース漏れに気づきやすくなりました
テストのAI活用
- シナリオテストやリグレッションテストを行う際に、評価項目の下準備などをAIに作成させ、評価しています
- 受け入れテストにおいても仕様書・評価結果をConfluenceに残す関係上、Atlassian Intelligenceを用いて整理しています
ドキュメント生成の効率化
- 設計書や技術仕様書の作成において、AIはドラフト生成や構成案の提案を行うことで、ドキュメント作成にかかる時間を大幅に短縮しました
- 手順書作成のにおいては、テンプレをAIが作り、AIに仕様書を読ませて運用時の手順やチェックリストを作り、ユーザー向け手順書を作るルーティンを回すことで、人は軽微な修正と補足画像の添付だけでよくなりました
- この部分にはAtlassian IntelligenceとRovoの成長が大きくインパクトを与えています

AIの活用により、私たちは限られたリソースの中で、設計の網羅性を高めつつ、意思決定を迅速に進めることができました。

これは、少人数でのスピーディーな開発体制を支える上で、極めて重要な要素であったと言えます。

設計におけるAIの活用: 効果

具体的にどの程度のサイクルで回っているかというと

機能設計：規模によりますが大体1機能半日～1日
機能開発：半日～1日
受け入れテスト：半日
リグレッションテスト：1日半

上記のように非常に短い期間で設計～実装が可能なため、他業務や、移行作業などの運用をしながら2週間に1回は何らかのアップデートをかけ続けられています。

開発プロセスと設計の進化

内製 IdP の開発は、計画通りに進むことばかりではありませんでした。

初期設計の段階では見えていなかった課題や、技術的な詳細を詰める中で明らかになった制約も多く、その都度、設計の進化を余儀なくされました。

稼働開始時点で実装した機能

開発開始から3ヶ月後の2025年3月には基本機能が完成し、稼働できる状態となりました。

ここでいう基本機能は以下の機能です。

ユーザー向け
- ログイン画面
- プロフィール画面
- 多要素認証設定画面
  - 秘密の質問（Security Question）、OTP、Passkey
管理者向け
- ActiveDirectoryからのユーザー/グループの取得
- ユーザーの操作（アカウント停止、セッションリセットなど）
- 許可IPリストの登録/削除UI
- SSOするアプリの登録UI（SAML/OIDC認証設定、ブックマーク用）
- アクセスポリシー設定UI
- 管理者ロール管理
- その他設定機能

その後、さらに機能を改修・拡張、追加が始まります。

開発中に直面した技術的課題

開発の過程では、様々な技術的課題に直面しました。

Oktaとの並行稼働

当社では350～400ほどのアプリが、Oktaと繋がっています。

そのうち、SAMLが300ほど、OIDCが30ほど、ブックマークやSWA（Secure Web Authentication）アプリが30ほど、という比率です。

それらの多くは、以下の理由で一斉に変えることができません。

各部署がオーナーで、部署・業務毎に利用頻度が高い「時期/時間帯」が異なる
IdP 側だけでなく、各クラウドサービス側でも設定変更が必要
各クラウドサービスで設定する値は、それぞれ環境毎に異なる

この問題を解決するため、Oktaを稼働しながら、認証先を内製 IdP に切り替えるということをしなくてはなりませんでした。そこで、各アプリから IdP に送られてくる認証を処理するため、以下のような構成で実現をしました。

OktaをIdP、内製 IdP をSP（ServiceProvider）として扱い、内製 IdP 自体の認証がなければOktaに認証を求めに行く、という形です。

SAMLではRelayStateを引き継ぐことができる特性があるため、内製 IdP からOktaに対してSAML Request（AuthNRequest）を送信しつつ、RelayStateを含ませることで本来のSPからの認証要求に関する情報を欠落させることなく、実現しています。

Oktaから内製 IdP を経由して各サービスに遷移する場合も、ブックマークアプリに設定するURLに、「内製 IdP へのSAMLログイン」と「内製 IdP が各サービスにSSOするためのアプリ」のURLを組み合わせたURLを設定することで、それを可能にしています。

これにより、各アプリごとの設定切替作業のほんの数分を除いてダウンタイムなしで切り替えを進めることができました。

各アプリ別の特性

移行段階ではいくつかの問題に直面しました。

というのも、300ほどのSAMLアプリは独自の手段で構築されており、Auth0やAmazon Cognito、Firebaseなどに完全委任しているもの、Shibbolethなど特定分野向けに広く展開されているもの、node-samlなどOSSに依存しているものなど、様々なツールに対応する必要がありました。

それぞれに対応するために、いくつもの改修を重ねました。

SAML
- Recipient URL/Destination URLを個別設定できるように
- Requestable SSO URLを設定できるように（Firebase対応）
- Default RelayStateを設定できるように
- Custom Attributesを設定できるように
- SAML Responseの中で、AssertionタグだけではなくResponse自体への署名もするように
- 署名付きSAML Request（AuthNRequest）を受けるために、SP側の証明書をインポートできるように
OIDC
- .well-known/openid-configurationの作成
- SPA（Single Page Application）のオリジン問題、PKCE対応
- MCPサーバとの認可フロー処理（introspectionのエンドポイント構築）
その他
- Credential Providerの開発

内製 IdP はOASISやRFC7522に準拠して構築しているため、基本的な認証部分で詰まることはありませんでした。

しかし、それだけでは不足しており、上述のように各サービスやOSSの特性に合わせ機能改修を行うことで、製品も成熟します。

また、改修に当たって調査が必要だったため、内製 IdP だけでなく各サービスやOSSに対する理解が深まりました。

詰まった場面においても、課題に対し、チームは即時即応で改修、必要であれば即リリースすることで、大きな滞留を発生させることなく移行を進め、350～400あるアプリを9か月の間にすべて移行完了させました。

初期設計からの変更点とその理由

ここまで見ていただいたように「機能の追加・拡張」はあれど、大きな「変更」は入っていませんが、実は「廃止」したものが1つだけあります。それは多要素認証の「秘密の質問（Security Question）」です。

廃止した背景は単純で、初期設計段階で実装はしていましたが、いざ2025年に入ってNIST SP 800-63Bのドキュメントを見たところ、第4版が出ており、秘密の質問が多要素認証の推奨からなくなっていたためです。

管理者向けの通知機能

新たな機能として通知機能を追加しました。これは内製 IdP のログで一定条件を満たすとSlackに通知する機能となります。

IdPのような、様々なシステムのハブになる24/365で動くシステムを内製化する、ということはインフラ監視だけではなくアプリケーションレイヤーもしっかり監視が必要です。

HTTP500エラー通知

システム開発において、想定外のバグを完全に防ぐことは至難の業です。

しかしながら、発生したことを検知し、自発的に修正することで、ユーザー影響を最小限に抑えることは可能です。

そのため、通常アカウント・ポリシー・権限で起きるHTTP400のエラーコードではないエラーを検知し、Slackに通知するようにしています。

同期エラー通知

前述したように、内製 IdP はActiveDirectoryやHERBと接続しています。

他にもいくつか同期しているサービスはあるのですが、それらとの連携でエラーが出てしまうと、割当ができないであったり、認証ができないといったことになる可能性も考えられます。

同期が失敗した場合は、手動で再実行する機能を作っているため、通知を受けて確認することで影響を抑えています。

品質保証と運用の考慮

IdPの安定性は、業務のパフォーマンスに直結します。私たちは、認証基盤としての信頼性を確保するために、多角的な品質保証と運用設計を行いました。

認証基盤としての信頼性を確保するためのテスト戦略

認証基盤の信頼性を確保するためには、徹底したテストが不可欠です。

単体テスト・結合テスト
- コーディング品質自体のチェックですが、こちらは開発内で行っています
受け入れテスト
- 設計/運用チームで、開発が終わったものを検証環境にリリースし、仕様書との整合性チェックを網羅的に行います
脆弱性診断・シナリオテスト
- 品質管理チームで、脆弱性診断およびシナリオテストを行っています
- こちらは、DeNAからリリースされた様々な製品を見てきたテストのスペシャリストが担うことで、安全性を担保しています

これらのテスト戦略により、リリース後も安心して利用できる認証基盤の実現を目指しています。

スケーラビリティと可用性への配慮

現在、ほぼすべてのアプリの移行が完了したため、未開放のユーザー画面への負荷はないものの、認証プロトコルの捌きだけで1割程度のリソース消費をしています。

今後、Oktaを廃止し内製 IdP を本格的に使い始めるにあたり、トランザクションの増加は避けられません。

また、マルチAZにすることで可用性を担保していますが、余裕をもってそれぞれを稼働させています。

無論コストは倍かかってしまうのでオートスケーリングなどは今後ユーザー画面開放に伴って調整を始めますが、これらの配慮により、十分なマージンを用意しておくことで、業務に影響を与えないように構築しています。

まとめ

本記事では、Oktaから内製 IdP への認証基盤移行プロジェクトの第2回として、その具体的な構築プロセス、特に 「どうやって内製 IdP を作り上げたのか」 技術・設計に焦点を当ててご紹介しました。

このプロジェクトは、既存認証基盤の課題を解決し、DeNAの多様な事業要件に最適化された、より堅牢で柔軟な認証基盤を自らの手で作り上げるという大きな挑戦でした。

特に、少人数体制でのスピーディーな設計と開発が実現でき、こうやってお話できることは、「永久ベンチャー」を標榜し、ユニコーン量産を掲げるDeNAの進む未来の礎になっているのではないかと考えます。

その背景に

内製に振り切る決断をした強力なリーダーシップ
生成AIの存在
これまでゲームやライブ配信事業など培われてきた強力なインフラ基盤とその運営力
システムの構成～活用・保全までの攻守各分野に長けたスペシャリストの存在
過去作られたものや現在も新規で作られる社内のシステム群との密な連携、全体アーキテクト
短期間で入れ替えが可能になったIdP利用者のリテラシーの高さ

があったからこそ、というのが伝わっていればと思います。

このプロジェクトを通じて得られた学びは

「IdP自体はさほど目新しいものではなく、本質は安全性のためにある」

「盛りだくさんな業務システムとは異なり、シンプルイズベストでよい」

「限られたリソースでも、明確なビジョンとAIという強力なパートナーがいれば、大規模かつ重要なシステムの内製化は可能である」

ということです。

そして、変化を恐れず、常に最適な解を探求し続けるDeNAのエンジニアリングに向ける情熱と真っ向から立ち向かう姿勢が、この挑戦を成功へと導く原動力となりました。

さいごに

DeNAの IdP 内製化プロジェクトは、まさに技術的な挑戦の連続です。本記事でご紹介したように、少人数でスピーディーに進めるための工夫や、AIとの協調が、このプロジェクトの成功に大きく貢献しています。

作って終わりではありません。まだこれからIPアドレスやアプリの自動棚卸機能、デバイス認証の本格化など「便利で安全なシステム」を磨き続ける計画があります。

次回の記事は2026年春～夏を予定しています。

2026年1月中旬には内製 IdP のユーザー画面を開放し、本格的な活用が始まります。社内にどんな反応があるのか、非常に楽しみです。

次回はその内製 IdP のリリース後についてお話しする予定です。サービス開始後の実際の利用状況や、運用を通じて見えてきた課題、そしてそれをどのように改善していくのかなど、さらなる具体的な情報をお届けできるかと思います。

DeNAの認証基盤への挑戦はまだ道半ばですが、これからも技術的な学びと知見を共有し、読者の皆様にとって価値ある情報を提供し続けていきたいと思います。

引き続き、DeNA Engineering Blogにご期待ください。