OAuth 2.0 Token Exchangeのさまざまな顔

• 1つのセキュリティトークンを別のトークンへ変換する標準ベースのメカニズムであり、RFC 8693で定義されたOAuth 2.0の拡張仕様
• 認可サーバーをSecurity Token Service(STS) に変換し、クライアントが送信したトークンを検証して、異なるコンテキスト・対象(audience)・目的に合った新しいトークンを発行
• 動作方式は大きくインパーソネーション(Impersonation) と委任(Delegation) の2つのモードに分かれる
• 管理者インパーソネーション、プロトコル変換、サービスチェイニング、フェデレーションIDなど、それぞれ異なるユースケースごとにトレードオフとセキュリティへの影響が存在
• AIエージェントの普及により、複数のサービス・プロバイダーをまたぐ処理が本質的に委任チェーンとなるため、トークン交換の重要性はさらに高まっている

---

トークン交換(Token Exchange)とは

• クライアントがsubject_token(リクエスト主体のユーザー/エンティティを表すトークン)を送り、必要に応じてactor_token(交換を実行する当事者)もあわせて送ると、対象コンテキストに適した新しいトークンを受け取る
• 既存トークンをそのまま転送したり、新しいトークンを単純に新規発行したりする方式は直感的に見えるが、どちらも深刻な問題を引き起こすため、それを解決するために作られた仕様

• 2つの基本動作モード

  • Impersonation: リクエスト当事者が元の主体と区別できないトークンを受け取り、ダウンストリームサービスは実際のユーザーなのか、なりすましを行う当事者なのかを区別できない
  • Delegation: 2つの主体のアイデンティティを両方保持し、新しいトークンに含まれるact(actor)クレームによって、ダウンストリームサービスがユーザーと代理実行者の両方を認識できる
  • インパーソネーションは強力だが不透明で、委任は制約があるが監査(audit)可能 — この選択がセキュリティ体制と追跡可能性を決定する

管理者インパーソネーション (Administrative Impersonation)

• 顧客ダッシュボードに誤ったデータが表示される問題を診断するため、サポートエンジニアが顧客と同じ権限・データアクセスで画面をそのまま確認しなければならない状況
• 管理者が自分のトークンを顧客のアイデンティティを表すトークンに交換し、結果のトークンには顧客のsubクレーム・スコープ・audienceが含まれるため、アプリケーションの観点では顧客が送ったリクエストとして認識される
• この場合、リクエストではsubject_token(なりすます対象ユーザー)のみを使い、actor_tokenは提供しない — 完全なインパーソネーションが目的だからである

• 監査証跡の喪失という問題

  • 真のインパーソネーションであるため、実際に誰が操作を行ったのかという監査証跡が失われる
  • そのため、誰が、いつ、どのような理由で交換を開始したのかを記録する外部ロギングメカニズムを必ず併用しなければならない。そうでなければ、問題解決を口実にセキュリティ上の空白が生じる

プロトコル変換の管理 (Managing Protocol Transition)

• レガシーシステムと旧式プロトコルが残る環境で、SAML認証からOpenID Connect(OIDC) へ移行しながら両システムを同時運用するシナリオ
• SAMLでユーザーを認証するサービスが、SAML assertionをOAuth 2.0アクセストークンへ交換し、認可サーバーが受け取ったSAMLアーティファクトを検証して、ダウンストリームが理解できる標準アクセストークンを発行する

• subject_token_typeパラメータ

  • 入力トークンの形式を識別し、RFC 8693では複数のトークンタイプ識別子が定義されている
    • SAML 2.0 assertion: urn:ietf:params:oauth:token-type:saml2
    • JWTトークン: urn:ietf:params:oauth:token-type:jwt
  • 認可サーバーは、異なるプロトコル系統のトークンを受け入れ、モダンなサービス向けの一貫した形式へ正規化できる
• 企業の合併・買収によって異なるIDスタックを持つ2つの組織が、完全移行前に相互運用しなければならないときに現れるパターンであり、ユーザーは従来どおりの方法で認証し、システムが資格情報を利用先サービスの要求する形へ変換する

サービス呼び出しのチェイニング (Chaining Service Calls)

• マイクロサービスアーキテクチャで、Service Aがユーザーリクエストを処理した後、ユーザーの代わりにService Bを、さらにService BがService Cを呼び出さなければならない状況では、各サービスが次の呼び出しにどの資格情報を使うかが重要な問いになる

• オプション 1 — サービス自身の資格情報を使う

  • Service Aがユーザーコンテキストを無視し、自分のクライアント資格情報でService Bを呼び出す方式で、バッチ処理・システム状態の確認・データ同期など、ユーザーコンテキストが不要なサービス間呼び出しに適している
  • ユーザーが関与する場合、Service Bはユーザーレベルの認可を強制できない — 誰のリクエストなのか分からず、アクセス権を確認できないためであり、セキュリティコンテキストが失われる

• オプション 2 — サービスがユーザーをインパーソネーションする

  • Service Aがユーザーの元トークンをそのままService Bへ渡すか、ユーザーと区別できないトークンへ交換し、Service Bはそれをユーザー本人からのリクエストとして扱ってユーザーレベルの認可を適用する
  • Service Bはユーザー本人の直接操作とService Aによる代理操作を区別できず、Service Aが侵害されるとユーザー権限内のあらゆる呼び出しが可能になり、直接リクエストとプロキシ経由リクエストに異なる信頼レベルを適用できない — ユーザーコンテキストは保持されるが、サービスコンテキストは失われる

• オプション 3 — ユーザーの代わりに行動する (Delegation)

  • Service Aがユーザートークンを、ユーザー(subject)とService A(actor) の両方を識別する新しいトークンへ交換し、結果トークンのactクレームが「ユーザーXに関するリクエストをService Aが実行している」ことを伝える
  • RFC 8693が主にサポートするよう設計された委任モデルであり、Service Bはより精密な認可判断を行える — Service Aがユーザーの許可していない操作を試みた場合、リクエストは失敗する
  • actクレームはネスト可能で、Service BがService Cを呼び出すと委任チェーンが拡張され、完全な監査証跡を提供する
  • トレードオフは複雑さにある — 各ホップでトークン交換が必要になるためレイテンシが増え、各サービスは認可サーバーにクライアントとして登録されていなければならない。しかし、セキュリティと監査が重要なアーキテクチャでは原則的な選択となる

トークン交換とフェデレーションID

• サービスがセキュリティドメインをまたぐとき(例: サードパーティ組織が提供するサービス)、チェーンのシナリオははるかに複雑になる
  • Service AはMyCompanyセキュリティドメイン内のユーザーの代わりにService Bへアクセスするトークンを保持している
  • Service BはExternal Providerドメインで保護されたService Cを呼び出す必要があり、そのためのアクセストークンが必要になる
• MyCompany認可サーバーが発行したトークンはExternal Providerドメインでは意味を持たない — ある認可サーバーが発行したトークンを別のサーバーが自動的に受け入れるわけではなく、信頼境界は被害範囲(blast radius)を限定するために存在する

• フェデレーション構成の限界

  • External Provider認可サーバーがMyCompanyドメインのトークンを有効なsubjectトークンとして受け入れるよう構成されていなければならず、メタデータ交換・証明書検証・直接構成による事前の信頼と、ドメイン間のアイデンティティマッピングが必要になる
  • ドメインが増えるほど(エンタープライズ統合、SaaSエコシステム、マルチクラウド)、二者間信頼関係のマトリクスは管理不能になる

• Cross App AccessとIdentity Chaining

  • このスケーリング問題を解決するためのCross App Access(XAA) は、Identity Assertion JWT Authorization Grantを実装し、クロスドメイン交換にエンタープライズIdPを仲介者として導入する
  • IdPがすでに両アプリケーションとユーザーの関係を把握しているという洞察を活用し、すべてのドメインペアが二者間信頼を結ぶ代わりに、アクセス判断をIdPに集中させる

  • XAAフローの4つの当事者

    • Requesting App: 別ドメインのリソースへアクセスする必要があるMyCompanyドメインのアプリケーション(またはAIエージェント)
    • Enterprise IdP: 従業員を認証し、クロスアプリポリシーを管理するMyCompanyドメインのIDプロバイダー
    • Resource App: External Providerドメインで保護されたAPIを所有するアプリケーション
    • Resource Authorization Server: Resource Appの保護API向けアクセストークンを発行する認可サーバー

  • XAAのステップごとのフロー

    • 従業員がSSOでRequesting Appにログインし、IdPからIDトークンを取得する
    • Requesting AppがそのIDトークンを再びIdPへ送り、クロスドメイン用のアイデンティティアサーション(ID-JAG、クロスアプリ向けにスコープされた特別なJWT)を要求する
    • IdPがXAAポリシーを確認し、このユーザーの代わりにResource Appへのアクセスが許可されるか判断し、許可されればID-JAGを返す
    • Requesting AppがID-JAGをResource Appの認可サーバーへ提示する
    • Resource App認可サーバーがOIDC discoveryを通じてIdP公開鍵を使いID-JAGを検証した後、アクセストークンを発行する
    • Requesting AppがそのアクセストークンでResource App APIを呼び出す
  • 通常のトークン交換との決定的な違いは、3番目のステップでIdPがポリシー判断を強制する点にある — 管理者はどのアプリがどのリソースへ到達できるかを明示的に構成でき、ITに可視性と統制を提供しながら、ユーザーは繰り返しの同意フローを回避できる
  • Identity Chainingは、ユーザーのアイデンティティアサーションが最初の認証からすべてのダウンストリームサービスまで標準化された方法で流れる、より広いパターンであり、XAAはそのOAuthプリミティブに基づく1つの実装である
  • 単一のユーザーリクエストが複数のサードパーティプロバイダーのサービス呼び出しを引き起こすAIエージェントのシナリオでは特に重要である

トークン交換とAuth0

• Auth0は、前述したスペクトラムの異なるポイントを扱うメカニズムとしてトークン交換を実装している

• Custom Token Exchange

  • Auth0の/oauth/tokenエンドポイントでRFC 8693を実装し、検証ロジックに対する完全な開発者制御を提供する
  • subject_token_type URIをカスタムActionにマッピングするToken Exchange Profileを定義し、リクエスト到着時にAuth0がActionコードを呼び出して、トークン検証・認可ルールの強制・テナント内ユーザーへの紐付けを行う
  • Auth0はsubject_tokenを不透明な文字列として扱うため、他のIdPのJWT、レガシーSAML assertion、パートナーAPIの独自トークンなど、どのような形式でも受け入れられる — プロトコル変換やカスタムフェデレーション向けのメカニズム

• Token Vault

  • 複数のプロバイダーにまたがってユーザーの代わりにサードパーティAPIを呼び出すAIエージェントのシナリオ向けで、トークン交換に安全な保管と自動ライフサイクル管理を追加する
  • ユーザーは認証後にアカウント(Google、GitHub、Slack、Microsoftなど)を連携し、Token Vaultがトークンを安全に保存して更新を自動処理し、AIエージェントはトークン交換によって有効なアクセストークンを保管庫から取得する
  • 結果トークンにはAIエージェントを識別するactクレームが含まれ、どのエージェントがどのユーザーの代わりにどのサービスへアクセスしたのかという監査証跡を生成する — 何が自動化を引き起こしたのかを把握する必要があるエンタープライズコンプライアンスに不可欠である

• On-Behalf-Of (OBO) Token Exchange

  • サービスチェーンのシナリオ向けに委任パターンを直接実装し、中間層サービスが受け取ったユーザートークンをダウンストリームAPI向けにスコープされた新しいトークンへ交換し、actクレームで委任チェーンに自分自身を追加する
  • 最大5段階の委任チェーンネストをサポートし、各トークンはsub(ユーザーアイデンティティの維持)・aud(対象サービスのスコープ)・ネストされたact(関与したサービスチェーンの記録)クレームを持つ

• Cross App Access (XAA)

  • リクエスト元アプリケーションが、別の認可サーバーによって保護されたリソースAPIを呼び出さなければならないフェデレーションIDのシナリオ向けで、Identity Assertion Authorization GrantのOAuth拡張を実装する
  • Auth0がResource Authorization Serverの役割を果たし、Requesting AppはユーザーIDトークンをOktaなどのIdPへ送ってID-JAGを受け取り、管理者がAdmin Consoleでクロスアプリ接続を構成した場合にのみIdPがアサーションを発行する
  • Requesting AppがID-JAGをAuth0へ提示すると、OIDC discoveryで検証した後、スコープされたアクセストークンを発行し、ITにクロスアプリのデータ共有に関する集中管理された可視性を提供する

正しいアプローチを選ぶ

• トークン交換は単一のソリューションではなくパターンの集合であり、どのコンテキストを保持し、どの信頼境界を越えるかによって選択が変わる
  • 管理者インパーソネーション: 問題解決の際に、ユーザーが見ている画面をそのまま見る必要があるとき
  • プロトコル変換: 移行中にレガシーIDシステムとモダンIDシステムをつなぐ橋が必要なとき
  • 委任(Delegation): サービスチェーンが完全な監査可能性とともにユーザーコンテキストを必要とするとき
  • Cross App Access / Identity Chaining: 委任が複数のセキュリティドメインにまたがるとき
  • Token Vault: AIエージェントがユーザーの代わりにサードパーティAPIへ管理されたアクセスを必要とするとき
• 複数のサービス・プロバイダーにまたがってユーザーの代わりに作業をオーケストレーションするAIエージェントは本質的に委任チェーンであり、トークン交換メカニズムは、そのチェーンを監査可能で、認可され、ユーザーの意図にスコープされたものにするためのセキュリティ基盤を提供する