メインコンテンツへスキップ
Custom Token Exchange を使用すると、RFC 8693 で定義されているとおり、アプリケーションは /oauth/token エンドポイントの呼び出し時に、既存のトークンを Auth0 トークンに交換できます。Custom Token Exchange の一般的なユースケースには、次のようなものがあります。
  • 別の 向けの Auth0 トークンを取得する
  • 外部の と統合する
  • Auth0 へ移行する
  • 委任された認可: プリンシパル (サービス、AI エージェント、サポート エージェントなど) がユーザーに代わって動作する
詳細については、Example Use Cases and Code Samples を参照してください。 各 Custom Token Exchange リクエストは、Action によって制御される Custom Token Exchange Profile にマッピングされます。ここでは、次のことを行えます。
  • /oauth/token エンドポイントに渡される subject_tokens をデコードして検証するカスタム コードを記述する
  • アクセスを認可し、トランザクションを続行するユーザーを設定する。
アプリケーションには、複数の Custom Token Exchange Profile を設定 できます。Auth0 認可サーバーが、Custom Token Exchange リクエストが有効であり、既存の Custom Token Exchange Profile にマッピングされることを検証すると、Custom Token Exchange trigger により、そのプロファイルに関連付けられた単一の Action が実行されます。その後、アプリケーションは Custom Token Exchange を利用して認証を行い、ユーザーの Auth0 のアクセストークン、IDトークン、リフレッシュトークンを取得できます。
Custom Token Exchange では、トランザクションに使用するユーザーを設定できる柔軟性が得られる一方で、そのユーザーを識別する対応する subject token を安全に検証する責任も伴います。Custom Token Exchange で使用する subject token と actor token は、Action コードで解釈できる限り、必要に応じて任意のトークン形式やトークンタイプを使用できます。受け取ったトークンについては、必ず厳格な検証を実装してください。 これを怠ると、なりすましやリプレイ攻撃など、さまざまな攻撃ベクトルにさらされ、不正な第三者が他人のユーザー ID で認証したり、許可なくそのユーザーに代わって行動したりできるようになります。subject token の安全な検証を実装するさまざまな方法については、Example Use Cases and Code Samples に記載されている推奨事項を確認し、適用してください。また、Attack Protection の機能についても考慮し、適用してください。

​
テナントログ

各 Custom Token Exchange トランザクションでは、テナントイベントログが生成されます。
  • 成功したトランザクション: secte ログ
  • 失敗したトランザクション: fecte ログ
setActor() でアクターが設定されている場合、監査目的で、sub とネストされた actor を含む actor プロパティが secte ログエントリに含まれます。 トークン交換で発生した問題のトラブルシューティングには、テナントログを活用してください。

​
制限事項

Custom Token Exchange では、以下はサポートされていません。
  • MFA API メソッド api.authentication.challengeWith() および api.authentication.EnrollWith()
  • インポートモードが ON の Custom DB Connections は、setUserByConnection() 操作ではサポートされません
  • サードパーティ製クライアントおよび OIDC 非準拠のクライアント
  • 非インタラクティブフローでは同意を取得できないため、対象の API では Allow Skipping User Consent を有効にしておく必要があります。