OAuth 2.0の上に構築されたOpenID Connectは、モダンなスタックにおける主要なフェデレーテッドアイデンティティプロトコルです。あらゆる主要なエンタープライズIdPがそれをサポートし、あらゆるクラウドワークフォースIdPがそれを提供し、あらゆるモダンなアプリケーションフレームワークがそのためのライブラリを用意しています。簡単だと思われる部分は、アプリケーションごとに数行のSDKコードで十分だと仮定することです。
実際には、本番トラフィックを運ぶOIDC relying partyには、正しく行うべき長いリストがあります。IDトークンの署名は、IdPが公開するJWKSに対して正しいキーkidを選択して検証されなければならず、IdPがキーをローテーションしたらキャッシュを更新しなければなりません。audienceクレームは構成済みのクライアントIDと一致しなければなりません。issuerは構成済みの期待されるissuerと一致しなければなりません。有効期間は限定的なクロックスキュー許容範囲とともに検証されなければなりません。IDトークン内のnonceは、AAMが認可リクエストで送信したnonceと一致しなければなりません — 一致しない場合、それはパースエラーではなくリプレイの試行です。
下層のOAuth 2.0レイヤーには独自の落とし穴があります。stateはユーザーのセッションにCSRF対策として紐づけられ、短いTTLを持たなければなりません。PKCE（できればS256）を使用し、盗まれた認可コードを攻撃者が交換できないようにしなければなりません。mixup攻撃 — 攻撃者がrelying partyを誤ったIdPと通信させるよう仕向ける状況 — は、コールバックを特定のIdPに紐づけ、それに応じてissuerを検証することで阻止されます。素朴なSDK統合では、これらの防御のどれも自動ではありません。
もう一つの失敗形態は、OIDC SDKを各アプリケーションに直接埋め込むことです。この場合、各アプリケーションが独自の信頼判断、JWKSキャッシュ、監査ログ、IdP構成を個別に抱えます。単一のIdP変更が、調整された複数アプリケーションのロールアウトになります。MFA、条件付きアクセス、デバイストラスト、ログアウト挙動が、アプリケーションごとに個別に、しばしば一貫性なく再び解決されます。
運用面も同様に重要です。IdPのdiscoveryドキュメントの更新、署名キーのローテーション対応、テナントごとに異なるIdPルーティング、異なるアプリケーション向けの異なるクレームマッピング、ログアウトフローは、後から付け足す細部ではありません。これらはOIDCフェデレーションが安全かつ持続可能に機能するための基本部品です。
正しい場所はアクセスエッジです。OIDCは単一ポイントで検証され、認証、MFA、条件付きアクセス、デバイストラスト、Backend SSOと同じレイヤーで管理されるべきです。これによりアプリケーションはフェデレーションプロトコルの複雑さを抱えず、検証済みでクリーンかつ信頼できるアイデンティティのみを受け取ります。
OIDCを正しく管理するとは、単にSDKでIdPに接続することではありません。IDトークンを単一ポイントで — MFA、条件付きアクセス、デバイストラスト、Backend SSOと同じエンジンで — 標準準拠の方法で検証し、監査し、アプリケーションへ安全に運ぶことです。
単一のAAMゲートウェイがエッジでOIDCを正しく終端します；アクセスエンジンの残りはその上に重なります。
PKCE付き認可コードフロー、JWKSを介したIDトークン署名検証、nonceに紐づくリプレイ防御、stateに紐づくCSRF防御、audience/issuer/有効性の適用。同じエンジンはIDトークンを提供しないIdP向けにプレーンなOAuth 2.0を話します；これによりトークンのみを提供するプロバイダーと完全なOIDCプロバイダーが単一のコードベースを共有します。
単一のAAMゲートウェイは、異なるアプリケーションを異なるIdPへ、また同一アプリケーションの異なるテナントを異なるIdPへ、同時にルーティングできます。IdPの選択は、アプリケーションまたはテナントのコンテキストからリクエストごとに行われます — IdPごとの別ゲートウェイなし、ユーザー向けの手動セレクターなし。
nonceはIDトークンをそれを要求した認可リクエストに紐づけ、stateはコールバックをユーザーのセッションに紐づけ、PKCEはコード交換を元のpublicクライアントに紐づけます。これらはいずれも統合者が忘れうるオプションのフラグではありません — デフォルトのフロー自体です。
OIDC認証は単独では機能しません — エッジのMFA（IdPがステップアップを適用しなかった場合）、条件付きアクセスの式、継続的トラスト評価、バックエンドへのBackend SSO注入とともに組み立てられます。IDトークンはAAMセッションへの一入力となります；セッション全体にはなりません。
標準準拠のOIDC relying party、加えてフェデレーションを大規模に安全かつ管理可能にする運用機能。
AAMはOAuth 2.0認可コードフローをPKCEをデフォルトで有効にして開始します — code_challenge_method=S256、リクエストごとに新鮮なcode_verifier、決して再利用しません。verifierを生成しない攻撃者は、盗んだ認可コードをトークンと交換できません。プレーンPKCEはそれを必須とするIdP向けに利用可能なまま残りますが、S256が構成済みのデフォルトです。
コールバックが到着すると、AAMはIdPのJWKSを取得し、IDトークンのkidヘッダーから署名キーを選択し、ヘッダーで指定されたアルゴリズム（RS256および標準ファミリーの残り）でIDトークンの署名を検証します。kidでキャッシュミスが起きるとJWKSを即座に更新します；これにより、IdPのキーローテーションが進行中のサインインを行き詰まらせません。
IDトークンのaudienceクレームは構成済みのクライアントIDを含まなければなりません；issuerは構成済みの期待されるissuerと一致しなければなりません；有効期間（exp/nbf）は限定的なクロックスキュー許容範囲とともに適用されます；nonceはAAMが認可リクエストで送信したnonceと一致しなければなりません。nonceの不一致はパースエラーとしてではなく、独自の監査イベントを伴うリプレイのシグナルとして扱われます。
JWKS応答は、ワーカープロセスとゲートウェイインスタンス間で共有されるストアに1時間のTTLでキャッシュされます。キャッシュヒットは各サインインでのネットワークラウンドトリップを排除します；要求されたkidでのキャッシュミスはJWKS URIからの即時更新をトリガーします；これにより日常的なIdPキーローテーションがサインインの中断を生みません。
標準のOIDC認可パラメータは第一級の構成です：scope（openidは自動付与）、IdPのサインイン体験向けのdisplay、強制再認証向けのmax_age、ローカライズされたIdPページ向けのui_locales、特定の認証コンテキストクラスを要求するためのacr_values — IdPにステップアップMFAの適用を要求するのに有用です。
組み込みプロファイルは一般的なプロバイダー向けに妥当なデフォルト（well-knownエンドポイント、JWKS URI、scopeの慣習）を備えています。標準準拠のあらゆるOIDCまたはOAuth 2.0プロバイダー向けに、エンドポイント、scope、マッピングを手動で指定するカスタムIdPの経路も利用可能なまま残ります。
署名検証の後、IDトークンのクレームはIdPのuserinfoエンドポイントからの応答とマージされます。衝突がある場合、署名済みIDトークンのクレームが署名なしのuserinfoフィールドより優先されます；これにより、userinfo応答を改ざんする攻撃者が署名済みのアイデンティティクレームを密かに変更できません。
RP-Initiated Logout（OIDC仕様の署名付きフロントチャネルログアウト）と、IdPからのセッション終了通知向けのバックチャネルログアウトがロードマップにあります。OIDC動的クライアント登録 — 新しいアプリケーションをIdPへ自動登録して導入すること — も計画されています。セッションおよび監査基盤はすでにこれらのフローに対応する形になっています。
OIDCフェデレーションを安全、最新、観測可能に保つメカニクス。
OAuth stateパラメータは、ユーザーのセッションに対して10分のTTLで保存されます。コールバックが到着すると、AAMはstateがフローを開始したのと同じセッションに属することを検証します — state値を別のユーザーのブラウザにリプレイする攻撃者は、OAUTH_STATE_MISMATCH監査イベントとともに拒否されます。
IDトークン署名検証が運用上の理由でスキップされた場合 — JWKSにアクセス不可、一致するkidなし、不正なJWK、JWKS URI欠如 — 専用の監査イベントが特定の根本原因を記録します。オペレーターは、一時的なJWKS障害を、設定ミスやサポートされないキータイプから、ランタイムログを読み直すことなく区別できます。
IDトークンはiat、nbf、expのタイムスタンプを持ちます。実際のクロックはずれます；AAMは限定的なクロックスキュー許容範囲を適用します（下層のJWT検証器はデフォルト60秒）；これにより小さなずれが有効なサインインを拒否せず、大きなずれ — 設定ミスやリプレイの兆候 — は引き続き拒否されます。
IdPに対するトークン交換とuserinfoリクエストは、限定的な接続、DNS、合計タイムアウトを使用します；これにより遅いまたは応答しないIdPがゲートウェイのワーカーを占有できません。トークン交換は30秒の合計予算で動作し、userinfoは15秒の予算で動作します；両者とも接続とDNSの予算はより短く、これにより障害は速やかに失敗します。
OIDCフローの各ステップ — フロー開始、コールバック成功、トークン交換（どのトークンが返されたか）、IDトークン署名検証の結果、JWKS取得の結果 — が、AAMセッションとその背後のバックエンドに紐づく相関IDとともに記録されます。「誰がどのIdP経由でいつサインインしたか」は単一のクエリで答えられます。
.well-known/openid-configurationエンドポイント経由の自動OIDCプロバイダーディスカバリーと、検出されたエンドポイントや署名キーセットが変化したときのオペレーターへのアラートがロードマップにあります。JWKSローテーションテレメトリー — 署名キー変更メトリクス、現在のキーの有効期限までの残日数のヒント、自動ローテーションのrunbook — も計画されています。
ワークフォースをすでにOIDC経由で認証している既存のエンタープライズIdP。AAMは、IdPチームに何かを変更させることなく、relying partyとして接続します。新しいアプリケーションは、各コードベースに新しいOIDC SDKを追加するのではなく、AAMに登録を追加することでフェデレーションに参加します。
組織のGoogle Workspaceテナントに対して認証する社内ツールや、GitHubをIdPとして使う開発者ツール。AAMはGoogleにはOIDCを、GitHubにはOAuth 2.0を話します — 同じエンジンから — そして各々を正規のAAMセッション形式にマッピングします。
各顧客が自身のOIDC IdPを持ち込むSaaSアプリケーション。単一のAAMゲートウェイがすべてのテナントを前面で受け持ちます；各テナントのトラフィックはそのテナントのIdPへルーティングされます。テナントを追加することは、デプロイではなく、IdP登録ストアへの構成変更を追加することです。
一部のIdPは認証はしますが、すべてのアプリケーションに対してステップアップMFAや条件付きアクセスを均等には適用しません。AAMはIdPの認証を受け入れ、その後アプリケーションへのアクセスを許可する前に、独自のMFA、条件付きアクセスの式、継続的トラスト評価をその上に重ねます。
AAMをあなたのOIDC IdP — エンタープライズ、クラウド、またはセルフホスト — に接続し、アクセスエンジンの残りをMFA、条件付きアクセス、デバイストラスト、Backend SSOとともに検証済みIDトークンの上に重ねましょう。