On-Behalf-OfはパターンでありToken Exchangeは標準規格

本記事は「On-Behalf-Of Is a Pattern. Token Exchange Is the Standard.」を翻訳した記事です。

2つ目のAPIを呼び出す必要があるWeb APIがあり、2つ目のAPIが誰のデータにアクセスしているかを知る必要があるとします。わかりやすい近道はユーザーの元のアクセストークンをダウンストリームサービスにそのまま転送することです。しかし、実行してはいけません。発行先ではないパーティにトークンを中継すると、トークンが本来スコープとしていた信頼境界が壊れます。中間層サービスにはユーザーの実際のクレデンシャルを再利用せずに、ユーザーのアイデンティティを保持する独自のトークンが必要です。

On-Behalf-Of(OBO)フローはまさに問題を解決します。しかし、On-Behalf-Ofという名前が実際に何を指しているのかを正確に理解しておく価値があります。なぜなら、後述する混乱は競合するフローに関するものではないからです。On-Behalf-Ofはアーキテクチャパターンであり、問題の形を表すラベルであって、解決するためのプロトコルではありません。OAuth 2.0 Token Exchange(RFC 8693)は相互運用可能な方法でパターンを実装するために最終的に構築されたIETF承認の標準規格です。Microsoft独自の「OBO」フローはまた別のものです。標準規格より前に存在し、標準規格に準拠していない、パターンの特定の非標準実装です。

パターン、標準規格、ベンダーの実装という3つを区別してください。そうすれば領域における混乱のほとんどは自然に解決します。RFC 8693の実装が「On-Behalf-Of」と名付けられ、すべてMicrosoftと同じ処理をしていると人々が思い込んでいる部分も含めてです。

まずパターンを確認し、次に独自に理解する価値のある1つのレガシー実装について説明します。続いてパターンを形式化した標準規格を解説します。最後にどちらも対応するように設計されていない部分である、ユーザーからダウンストリームサービスやエージェントへの明示的な委譲について順に説明します。

課題:中間層サービスがユーザーとして機能する必要がある

シナリオのすべてのバージョンに3つのアクターが登場します。

• クライアント:ユーザーが対話しているアプリケーション
• 中間層API:ユーザーのリクエストを受信し、別の場所からのデータを必要としているサービス
• ダウンストリームAPI:実際にデータを保持しているサービス

クライアントは一度認証し、中間層API用のトークンを取得しました。現在、中間層APIはダウンストリームAPI用のトークンを必要としており、トークンは中間層API自身ではなくユーザーを表す必要があります。

これにより、2つの魅力的な近道が排除されます。

• クライアントの元のトークンをダウンストリームに転送することは安全ではありません。トークンのオーディエンスはダウンストリームAPIではなく中間層APIだからです。
• 中間層APIが独自のサービスクレデンシャルを使用してダウンストリームAPIを呼び出すと、オーディエンスの問題は解決します。しかし、ダウンストリームAPIには中間層自身のアイデンティティしか見えないため、実際のユーザーがデータを見る認可を得ているかどうかを判断できなくなるという、さらに悪い問題が発生します。

必要なのは委譲です。ユーザーをリクエストの主体として識別しつつ、中間層APIが呼び出していることも記録する新しいトークンです。On-Behalf-Ofはまさにパターンの名前です。

パターン実装としてのOBO

Microsoftの実装(ほとんどの開発者が「OBO」と言うときに意味するもの)は、上記の問題に対する最も古くから広く展開されている解決策です。多くの本番システムが依然としてMicrosoftの実装で稼働しているため、独自に理解する価値があります。図に示すように、固定のシーケンスに従います。

番号付きのステップに従います。

1. クライアントが認証し、アクセストークンをリクエストします。
2. トークンエンドポイントは中間層APIをスコープとするトークンAを発行します。
3. クライアントはトークンAを使用して中間層APIを呼び出します。
4. 中間層APIはトークンエンドポイントに対して自身を認証し、ダウンストリームAPI用の新しいトークンをリクエストします。
5. トークンエンドポイントは中間層API自身のクレデンシャルとトークンAを検証します。
6. トークンエンドポイントはダウンストリームAPIをスコープとするトークンBを発行します。
7. 中間層APIはトークンBを使用してダウンストリームAPIを呼び出します。
8. ダウンストリームAPIが応答します。
9. 中間層APIは結果をクライアントに返します。

Microsoftの実装では、最小限のリクエストは次のようになります(共有シークレットのバリアント)。

POST /oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&client_id={middle-tier-api-client-id}
&client_secret={middle-tier-api-client-secret}
&assertion={token-a}
&scope=https://downstream-api.example.com/.default
&requested_token_use=on_behalf_of

本記事では2つの詳細が重要です。

• 第一に、実装はユーザープリンシパルに対してのみ機能します。元のトークンがサインインしたユーザーではなく、独自のクライアントクレデンシャルを使用して呼び出すアプリを表す場合、引き継ぐユーザーアイデンティティが存在しません。そのため、フローは適切なツールではありません(クライアントクレデンシャルチェーンが適切です)。
• 第二に、トークンBをクライアントに中継して戻してはいけません。ダウンストリームAPIのオーディエンス向けに発行されたものであり、他の場所に送信すると、スコープ付きの委譲がまさにパターンが防ごうとしているトークン転送の問題に変わってしまいます。

実際によく見られるのは、Microsoft Graphや他のEntraで保護されたリソースへの呼び出しチェーンです。Webアプリが独自のバックエンドを呼び出し、バックエンドはサインインしたユーザーにスコープされたGraphデータを必要とします。フローはユーザーの元のセッショントークンをバックエンドのダウンストリーム依存関係に公開することなく、Graphスコープのトークンを生成します。

目立ちませんが本当に便利なバリアントがあります。SAMLアサーションを作成するための実装の非標準拡張です。一部のSSO統合ではOAuth 2.0アクセストークンの代わりに依然としてSAMLアサーションを想定しています。Entra IDと並行してSAMLアイデンティティプロバイダーを実行する代わりに、サービスはユーザーのOAuthトークンをレガシーなダウンストリームサービスにスコープされたSAMLアサーションと交換できます。これにより、完全な移行を強制することなく2つのプロトコル世代を橋渡しします。ほとんどのRFC 8693展開はすでにOAuth2からOAuth2への移行を完了しているため、標準化されたアプローチが複製する必要があるものではなく、実装に固有のレガシープロトコルブリッジです。

Token Exchange:パターンを形式化する標準規格

OAuth 2.0 Token Exchangeは上記で説明した同じ委譲パターンのための、IETF承認のベンダー中立なプロトコルです。独自のグラントタイプ(grant_type=urn:ietf:params:oauth:grant-type:token-exchange)を定義します。ユーザーのアイデンティティを引き継ぐためにsubject_tokenを使用し、誰が呼び出しているかを記録するためにオプションのactor_tokenを使用します。Microsoftの実装とは異なり、明示的でチェーン可能なactクレームも指定します。マルチサービス呼び出しの各ホップを前のホップ内にネストできるため、ダウンストリームサービスはリクエストがたどった完全なパスを確認できます。

本記事ではToken Exchangeの仕組みの詳細には踏み込みません。Auth0のRFC 8693実装の全容については、The Many Faces of OAuth 2.0 Token ExchangeおよびA Developer's Guide to Flexible Token Exchange on Auth0のブログ記事を確認し、ドキュメントを読んでください。

本記事で重要なポイントはより限定的です。Token ExchangeはOn-Behalf-Ofのライバルではありません。相互運用可能な標準規格として書き起こされた場合のパターンの姿です。

誰が何を実装しているか

パターンには現在2つの実装があり、どちらを利用できるかはアイデンティティプロバイダーに依存します。Auth0、Okta、およびその他のアイデンティティ製品はRFC 8693を直接実装しています。Microsoft Entra IDやその他の製品は実装していません。依然として古いベンダー固有のjwt-bearerグラントを必要とするか、代わりに他のカスタム実装を使用します。

名前の混乱が実際に生じているのもこの部分です。Auth0を含むいくつかのベンダーはRFC 8693実装を構築し、「On-Behalf-Of」と名付けました。Auth0のOn-Behalf-Of(OBO) Token Exchangeは実際のRFC 8693グラントであるgrant_type=urn:ietf:params:oauth:grant-type:token-exchangeを使用し、actクレームを最大5レベルの深さまでネストします。これは「OBO」の2つ目の競合する意味ではありません。Microsoftのフローが非標準化された実装に付けられたパターンの名前であるのと同じように、標準化された実装に付けられたパターンの名前です。名前だけでどの実装について読んでいるかを判断しないでください。ベンダーのドキュメントで実際のgrant_typeを確認してください。

実用的な決定ルールは名前の混乱をそのまま乗り越えます。「On-Behalf-Of」が1つの特定のワイヤープロトコルを説明していると思い込む前に、アイデンティティプロバイダーが実際にどのグラントタイプを実装しているかを確認してください。

AIエージェントの委譲には何があるか

パターンとその標準化されたプロトコルの両方は、交換するユーザートークンがすでに存在することを前提としています。どちらにもユーザーが名前付きエージェントに代行を明示的に同意するフロントチャネルステップはありません。交換はすでに互いを信頼しているサービス間で完全にバックチャネルで行われます。ユーザーが「エージェントXがあなたの代わりにアクションを実行しようとしています」というメッセージを見て、具体的に承認する瞬間はありません。

ダウンストリームサービスの観点からは、人間、cronジョブ、自律エージェントのいずれが呼び出しを行ったかに関係なく、従来は同じように見えていました。監査側では変化が始まっています。Auth0のAgent as Principal機能(現在アーリーアクセス)を使用すると、テナントは永続的なエージェントアイデンティティを登録し、トークン交換中にactクレームに表示できます。そのため、オプトインしたリソースサーバーはどのクライアントが呼び出したかだけでなく、どの特定のエージェントがアクションを実行したかを判別できます。しかし、これは監査証跡に対するバックチャネルの改善であり、同意に対するフロントチャネルの改善ではありません。委譲フローは依然としてユーザーが事前の段階で「この特定のエージェント」を承認できるように設計されていません。また、監査証跡はエージェントがアクションを実行したことだけを伝え、そもそもアクションを決定する認可を得ていたかどうかを伝えることはできません。

いくつかの個別のIETFドラフトがギャップに対処することを目指しています。まだコンセンサスステータスに達したものはありませんが、追跡する価値があります。

• On-Behalf-Of User Authorization for AI Agentsは認可リクエストでのrequested_actorパラメーターとトークンリクエストでのactor_tokenパラメーターを提案しています。これにより、特定のエージェントのアイデンティティがキャプチャされ、明示的に同意されます。バックチャネルではなくフロントチャネルであり、既存のパターンと標準規格の両方に欠けているまさにその部分です。
• OAuth Actor Profile for Delegationは認可ポリシーを規定することなく、実装全体でactクレームの形状を標準化します。ちなみに、これはAuth0がAgent as Principal機能に現在採用しているドラフトです。
• Attenuating Authorization Tokensはエージェントがホップごとに認可サーバーとラウンドトリップするのではなく、オフラインでより狭いトークンを派生させることを可能にし、中央の調停と独立性をトレードオフします。トレードオフはマルチホップエージェントチェーン、つまり他のエージェントを呼び出すエージェントの長いチェーンにとって重要です。コンテキストにおいて、RFC 8693の同期的なホップごとの交換モデルは実際のレイテンシを追加し始めます。

これらはすべて個別の提出物であり、ワーキンググループのドラフトではありません。個別の提出物はIETFプロセスにおいて正式な地位を持ちません。執筆時点で一部はすでに期限切れになっているか、期限切れになろうとしています。標準規格の議論は活発ですが、純粋に未解決の領域です。

しかし、IETFのWIMSEワーキンググループは現在、一般的な領域でさらなる標準化を追求しています。Workload Identity in a Multi System Environment(WIMSE) Architectureです。こちらもまだ初期段階ですが、決着の行方を追跡したい場合に注目すべきグループです。

MCP(Model Context Protocol)は問題の実用的な形を示しています。MCP自身のアクターをOAuth 2.0のロールにマッピングすると、パターンはおなじみのものになります。MCPサーバーはリソースサーバー、エージェントランタイムはクライアント、ホストアプリケーションは全体をオーケストレーションするOAuth 2.0クライアントです。しかし、MCP自体は認可をオプションとして扱い、アイデンティティと委譲を背後にある外部アイデンティティプロバイダーに完全に委ねます。マッピングによりプロトコルのロールが明確になります。特定のエージェントがどのユーザーの代わりにアクションを実行しているかはわかりません。仕様が提供するものではなく、インテグレーターが解決すべき責任として残ります。

これはユーザーの代わりにアクションを実行するエージェントに特有の問題でもありません。混乱した代理人問題(confused deputy problem)と似ています。特権サービスが正当な命令と注入された命令を区別できないため、自身の権限を悪用するように騙されるという何十年も前のパターンです。誰が何を認可したかの明確な記録なしにエージェントに広範な委譲権限を付与することは、古いバグに新しくより有能なホストを与えるだけです。

今日実際にすべきこと

上記のドラフトが安定するのを待たないでください。標準規格の議論がどのように解決するかにかかわらず、有効な対策は次のとおりです。

• アイデンティティプロバイダーがサポートしている場合は、標準規格であるRFC 8693 Token Exchangeを利用してください。ベンダーが強制する場合にのみ、ベンダー固有のjwt-bearerパターンにフォールバックします。機能名だけでなく、ドキュメントで実際のグラントタイプを確認してください。
• ダウンストリームシステムがまだネイティブに消費できない場合でも、すべての委譲されたトークンにactクレーム、またはプロバイダーの最も近い同等のものをログに記録してください。トークン自体が保持しない場合は、アプリケーション層でアクター、タスク、承認者を記録します。Closing the audit gap in human-to-agent delegationでは相関IDと承認チェックポイントを使用して実行する具体的な方法を説明しています。
• 目的ごとにエージェントにつき1つのクレデンシャルを発行してください。エージェントに人間の生のトークンを保持させたり中継させたりしないでください。エージェント向けインフラストラクチャを構築している場合、Auth0のToken Vaultのようなメカニズムはまさに制約を中心に設計されています。サードパーティAPIアクセスのための、管理され監査可能なエージェントごとのトークンです。Auth0のAgent as Principalはさらに一歩進んで、すべてのエージェントの代わりとなる共有M2Mクライアントやサービスアカウントに依存するのではなく、安定したIDを持つ独自の登録済みアイデンティティを各エージェントに付与します。
• すべての委譲されたトークンを特定のタスクにスコープしてください。呼び出しを行っているクレデンシャルの完全な権限セットではありません。より狭いトークンはエージェントが誤動作したり、自身の権限を悪用するように騙されたりした場合の影響範囲を制限します。
• 標準規格が定着したときではなく、今すぐ監査証跡を構築してください。自動化された意思決定に関する規制上の透明性要件はすでに多くの管轄区域で発効しており、過去のログを事後に再構築することはできません。「どのエージェントが誰の権限で実行したか」に答えるために今日構築するものは、来年構築する理論的によりクリーンなバージョンよりも価値があります。

パターン、標準規格、そしてアイデンティティの疑問

冒頭のシナリオの中間層APIを考えてみましょう。実際のトークンを公開せずにユーザーのアイデンティティを使用してダウンストリームサービスを呼び出す方法という主要な疑問は、何年も前に解決されています。On-Behalf-Ofのようなパターンを通じて非公式に始まり、現在ではRFC 8693 Token Exchangeを通じて標準化されています。特定の実装はアイデンティティプロバイダーに依存しますが、コアとなる設計戦略は十分に確立されています。

しかし、AIエージェントは新たな複雑さをもたらします。疑問はもはや単にサービスがユーザーの代わりにアクションを実行できるかどうかではなく、特定の指定されたエージェントが明示的なユーザーの同意と認可の監査可能な記録を持っているかどうかです。OBOもToken Exchangeも機能のために設計されておらず、対処する提案されたドラフトはまだIETFのコンセンサスを得ていません。標準規格が登場するまで、詳細なロギング、きめ細かなスコープ設定、および専用のエージェントごとのクレデンシャルを通じてギャップを管理する必要があります。