Oktaから自社開発IdPへの認証基盤移行（第2回）

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

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

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

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

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

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

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

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

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

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

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

全体的な方針決定や、予算管理などを行うプロジェクトマネージャーには IT 戦略部副部長

開発チームとして、セキュリティ部セキュリティ技術グループからメイン 1 名、スポットで補佐 3 名

設計・運用チームとして、我々テクニカルオペレーショングループから 3 名

品質管理チームから 4 名（兼務）

インフラチームとして 3 名（兼務）

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

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

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

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

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

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

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

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

シンプルなデータ構造であること（IdP は複雑なデータを永続的に保管しない）

自動化を前提とした仕組みであること

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

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

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

IGA の切り離し 内製 IdP は、ユーザー認証そのものに特化し、シンプルさとパフォーマンスを追求しました。これにより、認証プロセスの高速化と堅牢性の向上を目指しています。

IGA との連携 一方で、IGA とは API を通じて内製 IdP が取得する方針を取りました。この分離により、それぞれのシステムが独立して進化できる柔軟性を確保しています。

の記事でご紹介している 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 日

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

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

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

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

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

多要素認証設定画面 秘密の質問（Security Question）、OTP、Passkey

管理者向け ActiveDirectory からのユーザー/グループの取得

ユーザーの操作（アカウント停止、セッションリセットなど）

許可 IP リストの登録/削除 UI

SSO するアプリの登録 UI（SAML/OIDC 認証設定、ブックマーク用）

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

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

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

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

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

各部署がオーナーで、部署・業務毎に利用頻度が高い「時期/時間帯」が異なる

IdP 側だけでなく、各クラウドサービス側でも設定変更が必要

各クラウドサービスで設定する値は、それぞれ環境毎に異なる

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

Okta を IdP（Identity Provider：アイデンティティプロバイダー）、内製 IdP を SP（ServiceProvider：サービスプロバイダー）として扱い、内製 IdP 自体の認証がなければ Okta に認証を求めに行く、という形です。

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

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

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

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

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

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

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つだけあります。それは多要素認証（Multi-Factor Authentication）の「秘密の質問（Security Question）」です。

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

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

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

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

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

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

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

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

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

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

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

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

単体テスト・結合テスト コーディング品質自体のチェックですが、こちらは開発内で行っています

受け入れテスト 設計/運用チームで、開発が終わったものを検証環境にリリースし、仕様書との整合性チェックを網羅的に行います

脆弱性診断・シナリオテスト 品質管理チームで、脆弱性診断およびシナリオテストを行っています

こちらは、DeNAからリリースされた様々な製品を見てきたテストのスペシャリストが担うことで、安全性を担保しています

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

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

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

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

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

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

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

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

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

内製に振り切る決断をした強力なリーダーシップ

これまでゲームやライブ配信事業など培われてきた強力なインフラ基盤とその運営力

システムの構成～活用・保全までの攻守各分野に長けたスペシャリストの存在

過去作られたものや現在も新規で作られる社内のシステム群との密な連携、全体アーキテクト

短期間で入れ替えが可能になった IdP 利用者のリテラシーの高さ

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

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

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

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

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

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

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

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

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

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

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

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

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

最後まで読んでいただき、ありがとうございます！この記事をシェアしていただける方はこちらからお願いします。