OAuth/OIDC におけるトークンエクスチェンジの理解

RFC 8693 で導入されたトークンエクスチェンジは、既存のトークンを異なる属性やスコープを持つ新しいトークンと交換するために信頼されたクライアントを可能にする OAuth の拡張です。このメカニズムは特に、サービス、アプリケーション、またはエンドユーザーが、事前に承認されたトークンを介して通常の OAuth アクセストークンを取得する際に、完全な OAuth フローを経る必要がない場合に有効です。

認可コードフローとの比較#

まず、アクセス トークンを取得するための最も一般的なフローである OAuth 認可コードフローを見てみましょう。

そして、これがトークンエクスチェンジフローです:

リダイレクト#

主な違いは、認可コードフローでは、クライアントアプリケーションがユーザーを認可サーバーにリダイレクトしてアクセストークンを取得するのに対し、トークンエクスチェンジでは、ユーザーをリダイレクトすることなく、クライアントアプリケーションが認可サーバーとトークンを交換できることです。

これは、認可コードフローでは、クライアントアプリケーションが "信頼されていない"ため、ユーザーの資格情報を知る必要があるのに対し、トークンエクスチェンジでは、クライアントアプリケーションがすでにトークンをユーザーから取得したことを信頼されており、認可サーバーがトークンを検証し、新しいトークンを発行するためです。

トークン発行者とトークンエクスチェンジサービス#

トークンエクスチェンジフローでは、「Auth Server」が次の2つの参加者になります:

1. トークン発行者: クライアントアプリケーションに subject token を発行します。
2. トークンエクスチェンジサービス: subject token を検証し、新しいトークンをクライアントアプリケーションに発行します。

トークンエクスチェンジサービスは、認可コードフローにおける「Auth Server」と同じで、トークン発行者はサードパーティのアイデンティティプロバイダーであったり、「Auth Server」から分岐した専用サービスであったりすることができます。

トークンエクスチェンジをいつ使用するか?#

トークンエクスチェンジフローはユーザーのインタラクションなしに実行できるため、以下のシナリオで役立ちます:

• 偽装: サービス (例:バックエンドマイクロサービス) または管理者ユーザーが完全なユーザー資格情報を公開せずにユーザーに代わってアクションを実行できるようにします。
• 自動化: 信頼されたサービスがマニュアルの介入なしに自動的にアクションを実行したり、自動化されたテストを実行したりできるようにします。
• 他の IdP との統合: 異なるアイデンティティシステム間でトークンを変換してシームレスなユーザーエクスペリエンスを維持し、権限を効果的に管理します。一般的なシナリオの1つは、SSO トークンを下流サービス用のトークンに変換することです。
• 移行: トークンを1つの認可サーバーから別のサーバーに移行します。例えば、レガシーシステムから最新の OAuth/OIDC 準拠システムへ移行する場合など。

トークンエクスチェンジプロセス#

新しいアクセストークンの交換は最も一般的なユースケースであり、これを例として取り上げます。アクセストークンに限らず、トークンエクスチェンジはリフレッシュトークン、ID トークンなど他の種類のトークンを発行するためにも使用できます。

クライアントアプリケーション#

トークンエクスチェンジを実行するには、認可サーバーに登録されたクライアントアプリケーションが必要です。

そして、クライアントアプリケーションはトークンエクスチェンジフローを開始する前に subject_token を持っている必要があります。このトークンは通常、認可サーバーまたは信頼されたサードパーティのアイデンティティプロバイダーによって付与されます。このトークンを持つことで、クライアントアプリケーションはユーザーの資格情報やインタラクションなしでトークンを交換することを "信頼" できるようになります。

トークンエクスチェンジのリクエスト#

クライアントは、既存のトークンを交換するために認可サーバーのトークンエンドポイントにリクエストを送信します。これには subject_token (交換されるトークン) および任意で、目的のターゲットオーディエンス、スコープ、トークンタイプが含まれます。

1. grant_type: 必須。このパラメータの値は urn:ietf:params:oauth:grant-type:token-exchange であり、トークンエクスチェンジが実行されていることを示します。
2. subject_token: 必須。ユーザーの PAT。
3. subject_token_type: 必須。subject_token パラメータで指定されたセキュリティトークンのタイプ。このパラメータの一般的な値は urn:ietf:params:oauth:token-type:access_token ですが、交換されるトークンに基づいて変わることがあります。
4. resource: 任意。アクセス トークンのターゲットリソースを指定するためのリソースインジケータです。
5. audience: 任意。アクセス トークンのオーディエンスを示し、トークンの目的の受信者を示します。audience が指定されない場合、認可サーバーは resource の値を使用することがあります。
6. scope: 任意。要求されたスコープ。

また、リクエストにはクライアント情報を含める必要があり、これは Basic 認証ヘッダーとしてエンコードするか、フォームデータとして送信できます。

ここにリクエストの例があります:

Logto におけるトークンエクスチェンジ#

Logto は、偽装および個人のアクセストークンを含む、トークンエクスチェンジをすぐにサポートします。