トークン交換を使用すると、サービスはユーザーに再認証を要求することなく、あるアクセストークンを、より狭いスコープまたは異なるオーディエンスを持つ別のアクセストークンに交換できます。
概要
あるサービスがユーザーに代わって別のサービスを呼び出す必要がある場合、自身の広範なトークンを転送するべきではありません。トークン交換 (RFC 8693) は、既存の subject_token を、ダウンストリームサービスにスコープを限定した新しいトークンと交換する標準の POST /oauth/token リクエストを定義することで、この問題を解決します。
IDaaS は、OAuth 2.0 拡張としてトークン交換を実装しています。新しいトークンは、元のユーザーの ID を維持しつつ、オーディエンスと権限をダウンストリームサービスが必要とするものだけに制限します。
トークン交換で実現できること
スコープの制限：トークンをより少ない権限を持つものに交換します。ダウンストリームのトークンが侵害された場合、影響範囲は狭いスコープに限定されます。
トークンタイプの変換：システム間の相互運用性のために、JWT や SAML などのフォーマット間で変換します。
ID の伝播：認証情報を公開したり再認証を要求したりすることなく、ユーザーの ID をダウンストリームサービスに渡します。
クロスドメインの信頼確立：別々の信頼ドメインにあるサービス間の安全な統合を可能にします。
仕組み
一般的なトークン交換のフローには、4つのステップが含まれます。
ユーザー認証：フロントエンドがシングルサインオン (SSO) を通じてユーザーを認証し、サービス A のアクセストークンを取得します。
サービス A が新しいトークンをリクエスト：サービス A は、IDaaS の認可サーバーにトークン交換リクエストを送信します。リクエストには、元のアクセストークンを
subject_tokenとして含め、ターゲットオーディエンス (サービス B) を指定します。IDaaS が検証と発行：認可サーバーは
subject_tokenを検証し、サービス A がリクエストされたオーディエンスとスコープに対して認可されているかを確認し、新しいアクセストークンを発行します。サービス A がサービス B を呼び出し：サービス A は新しいトークンを使用してサービス B を呼び出します。サービス B は、トークン内にサービス A の ID ではなく、元のユーザーの ID を認識します。
インパーソネーションのセマンティクス
IDaaS はトークン交換に偽装セマンティクスを使用します。新しいトークンは元のユーザーを完全に表現し、リクエスト元のサービスの ID は含まれません。監査ログでは、操作は元のユーザーに起因するものとして記録されます。
このモデルは、サービスがユーザーに代わって透過的に動作する場合に適用されます。例えば、メールサービスがユーザーとしてメッセージを送信する場合、受信者には送信者としてサービスではなくユーザーが表示されます。
IDaaS は偽装セマンティクスのみをサポートしています。委任セマンティクス (ユーザーと呼び出し元サービスの両方の ID がトークンに含まれる) はサポートされていません。
ユースケース
エージェントからサービスへの ID 伝播
ある企業が、人事データサービスをバックエンドに持つ AI 旅行計画エージェントを運用しているとします。従業員がエージェントに旅行の計画を依頼すると、エージェントは人事サービスからその従業員の職務レベルと出張予算を取得する必要があります。
トークン交換がない場合、エージェントは自身のサービスアカウント (M2M 認証情報) を使用して人事サービスを呼び出します。人事サービスは、どの従業員がリクエストを行っているかを判断できず、ユーザーごとのアクセスポリシーを適用できません。
トークン交換を使用すると、フローは次のようになります。
従業員は旅行システムに認証し、エージェントにスコープされたアクセストークンを取得します。
エージェントはそのトークンを、従業員の ID を維持したまま、人事サービスにスコープされた新しいトークンに交換します。
人事サービスはトークンを検証し、従業員の ID を確認して、その従業員のデータのみを返します。
交換されたトークン (AT_obo) は、旅行システム → エージェント → 人事サービスという完全な認可チェーンを保持します。これにより、監査のためのエンドツーエンドのトレーサビリティが提供されます。
制限事項
IDaaS が発行したトークンのみ：認可サーバーは自身が発行したトークンのみを受け入れます。サードパーティのトークンは交換できません。
アクセストークンからアクセストークンへの交換のみ：他のトークンタイプ (リフレッシュトークンや ID トークンなど) は、入力または出力としてサポートされていません。
クライアントの認可が必要：リクエスト元のサービスは、ターゲットのオーディエンスとスコープに対する権限を持っている必要があります。
トークンが有効であること：
subject_tokenは、有効期限が切れておらず、取り消されていない必要があります。交換の深さの制限：循環的な認可チェーンを防ぐため、トークンは限られた回数しか交換できません。