Skip to content

OAuth Identity and Authorization Chaining Across Domains

draft-ietf-oauth-identity-chaining-06

Abstract

この仕様は、OAuth 2.0 Frameworkを使用する信頼ドメイン間で、アイデンティティおよび認可情報を保持するための仕組みを定義する。

Discussion Venues

この注記は、RFCとして公開する前に削除される予定である。

本文書に関する議論は、Web Authorization Protocol Working Groupのメーリングリスト（oauth@ietf.org）で行われる。このメーリングリストは https://mailarchive.ietf.org/arch/browse/oauth/ にアーカイブされている。

このドラフトのソースおよび課題トラッカーは https://github.com/oauth-wg/oauth-identity-chaining にある。

Status of This Memo

このInternet-Draftは、BCP 78およびBCP 79の規定に完全に準拠して提出されている。

Internet-Draftsは、Internet Engineering Task Force (IETF) の作業文書である。他のグループも作業文書をInternet-Draftとして配布する場合があることに留意されたい。現行のInternet-Draftsの一覧は https://datatracker.ietf.org/drafts/current/ にある。

Internet-Draftsは最大6か月間有効なドラフト文書であり、いつでも更新、置換、または他の文書によって廃止され得る。Internet-Draftsを参照資料として用いたり、「作業中（work in progress）」として以外に引用したりするのは不適切である。

このInternet-Draftは2026年3月16日に失効する。

Copyright (c) 2025 IETF Trust および本文書の著者として識別される者。無断転載を禁ずる。

本文書は、本書の公開日に有効なBCP 78およびIETF Trustの「IETF文書に関する法的規定」（https://trustee.ietf.org/license-info）の適用を受ける。これらの文書には本文書に関する権利および制約が記述されているため、注意深く確認されたい。本文書から抽出されたCode Componentsには、Trust Legal ProvisionsのSection 4.eに記述されているRevised BSD Licenseの本文を含めなければならない。また、Revised BSD Licenseに記述されているとおり、これらは保証なしで提供される。

Table of Contents

1. Introduction

アプリケーションは、複数の信頼ドメインに分散したリソースへのアクセスを必要とすることが多い。各信頼ドメインには、それぞれ固有のOAuth 2.0 authorization serverが存在する。1つのリクエストは、完了するまでに複数の信頼ドメインにまたがる複数のResource Serverを横断する場合がある。そのようなリクエストに関与するすべての保護されたリソースは、リクエストが元々誰の代理で開始されたのか（すなわちユーザー）、どのような認可が付与されたのか、そして任意で、認可判断を行う前に他にどのResource Serverが呼び出されたのかを把握する必要がある。これらの情報は、リクエストが1つ以上の信頼ドメインをまたぐ場合であっても保持されなければならない。本書ではこれを「チェイニング（chaining）」と呼び、OAuth 2.0 Token Exchange [RFC8693] と、OAuth 2.0 Client Authentication and Authorization GrantsのためのJSON Web Token (JWT) Profile [RFC7523] を組み合わせて、複数の信頼ドメインにまたがるリソースへアクセスしつつ、アイデンティティおよび認可情報を保持するための共通パターンを定義する。

1.1. Requirements Language

本書におけるキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」「OPTIONAL」は、ここに示すようにすべて大文字で記載されている場合に限り、BCP 14 [RFC2119] [RFC8174] に記述されるとおりに解釈される。

2. Identity and Authorization Chaining Across Domains

本仕様は、ドメインをまたいだアイデンティティおよび認可のチェイニングを実現するために、OAuth 2.0 Token Exchange [RFC8693] と、OAuth 2.0 Client Authentication and Authorization GrantsのためのJWT Profile [RFC7523] の組み合わせについて説明する。

信頼ドメインAのクライアントが信頼ドメインBのResource Serverへアクセスする必要がある場合、信頼ドメインAのauthorization serverに対して、OAuth 2.0 Token Exchange [RFC8693] のプロファイルを用いてJWT authorization grantを要求する。次に、信頼ドメインAのクライアントは、受け取ったgrantをassertionとして信頼ドメインBのauthorization serverへ提示し、[RFC7523] のJWT authorization grant機能を用いて、信頼ドメインBの保護されたリソース向けのaccess tokenを取得する。

一部の導入形態では、信頼ドメインAのクライアントは、OAuth 2.0 Token Exchangeプロトコル [RFC8693] 以外の、独自APIやインターフェースを用いてJWT authorization grantを取得する場合がある。そのようなインターフェースの詳細は本書の対象範囲外であるが、JWT authorization grantを取得するための代替手段を本書が排除するものではない。どのような方法で取得したかに関係なく、JWT authorization grantは、本書のSection 2.4で説明するように、信頼ドメインBのauthorization serverからaccess tokenを要求するために使用しなければならない（MUST）。

2.1. Overview

以下に示すアイデンティティおよび認可のチェイニングフローは、特定されたユースケースに対処するために、OAuth 2.0 Token Exchange [RFC8693] と、OAuth 2.0 Client Authentication and Authorization GrantsのためのJWT Profile [RFC7523] の組み合わせがどのように使用されるかを説明する。

  +-------------+         +--------+         +-------------+ +---------+
  |Authorization|         | Client |         |Authorization| |Protected|
  |Server       |         | Trust  |         |Server       | |Resource |
  |Trust        |         |Domain A|         |Trust        | |Trust    |
  |Domain A     |         |        |         |Domain B     | |Domain B |
  +-------------+         +--------+         +-------------+ +---------+
         |                    |                     |             |
         |                    |----+                |             |
         |      (A) discover  |    |                |             |
         |      Authorization |<---+                |             |
         |      Server        |                     |             |
         |      Trust Domain B|                     |             |
         |                    |                     |             |
         | (B) exchange token |                     |             |
         |   [RFC 8693]       |                     |             |
         |<-------------------|                     |             |
         |                    |                     |             |
         | (C) <authorization |                     |             |
         |       grant JWT>   |                     |             |
         | - - - - - - - - - >|                     |             |
         |                    |                     |             |
         |                    | (D) present         |             |
         |                    | authorization grant |             |
         |                    | [RFC 7523]          |             |
         |                    | ------------------->|             |
         |                    |                     |             |
         |                    | (E) <access token>  |             |
         |                    | <- - - - - - - - - -|             |
         |                    |                     |             |
         |                    |               (F) access          |
         |                    | --------------------------------->|
         |                    |                     |             |

            Figure 1: Identity and Authorization Chaining Flow

Figure 1に示すフローは、信頼ドメインAのクライアントが信頼ドメインBの保護されたリソースへアクセスするために実行する必要がある手順を示している。このフローでは、クライアントは、Token Exchange（Section 2.3）で定義されるtoken exchangeフローの一部としてauthorization serverが受理するtokenを所持している。本仕様は、クライアントがこのtokenをどのように取得したかを対象範囲外とする。クライアントには、ドメインBのauthorization serverを発見する方法があり、ドメインAとドメインBの間には信頼関係が存在する。フローは以下を含む。

  • (A) 信頼ドメインAのクライアントは、信頼ドメインBのauthorization serverの場所を発見する。Authorization Server Discovery（Section 2.2）を参照。
  • (B) 信頼ドメインAのクライアントは、所持しているtokenを信頼ドメインAのauthorization serverと交換し、信頼ドメインBのauthorization serverで使用可能なJWT authorization grantを取得する。Token Exchange（Section 2.3）を参照。
  • (C) 信頼ドメインAのauthorization serverはリクエストを処理し、信頼ドメインBのauthorization serverでクライアントが使用できるJWT authorization grantを返す。これは、信頼ドメインAと信頼ドメインBのauthorization server間の信頼関係を必要とする（フェデレーションと呼ばれることもある。このような信頼関係は通常、鍵素材の交換として具現化され、ドメインBのauthorization serverが、JWT authorization grantsに署名するためのドメインAの公開鍵を信頼する）。
  • (D) 信頼ドメインAのクライアントは、authorization grantを信頼ドメインBのauthorization serverに提示する。Access Token Request（Section 2.4.1）を参照。
  • (E) 信頼ドメインBのauthorization serverはJWT authorization grantを検証し、access tokenを返す。JWT authorization grantの検証には、ドメインAの公開鍵および、認可grantを発行する権限を信頼することが必要である。これは、ドメインB側の設定およびポリシーとして、ドメインAに対応する公開鍵群を関連付ける形を取り得る。あるいは、「OAuth 2.0 Authorization Server Metadata」[RFC8414] に記載される、ドメインAのjwks_uriで公開されている鍵に依存する場合もある。
  • (F) 信頼ドメインAのクライアントは、信頼ドメインBのauthorization serverから受け取ったaccess tokenを用いて、信頼ドメインBの保護されたリソースへアクセスする。

2.2. Authorization Server Discovery

本仕様はauthorization server discoveryを定義しない。クライアントは、OAuth 2.0 Protected Resource Metadata [RFC9728] で定義されるauthorization_serversプロパティを使用する、静的な対応表を維持する、またはその他の手段を用いてauthorization serverを特定してもよい（MAY）。

2.3. Token Exchange

信頼ドメインAのクライアントは、[RFC8693] で定義されるtoken exchangeを信頼ドメインAのauthorization serverと実行し、[RFC6749] のsection 1.3で規定されるとおり、信頼ドメインBのauthorization serverで使用できるJWT authorization grantを取得する。

2.3.1. Token Exchange Request

[RFC8693] のsection 2.1で説明されるパラメータが、以下の制約付きで適用される。

  • scope\ OPTIONAL。返されるJWT authorization grantに含まれるscopeを示す追加のscopes。Claims transcription（Section 2.5）を参照。
  • resource\ audienceが設定されていない場合はREQUIRED。信頼ドメインBのauthorization serverのURI。
  • audience\ resourceが設定されていない場合はREQUIRED。信頼ドメインBのauthorization serverの周知の／論理的な名前。

2.3.2. Processing rules

  • リクエスト自体が有効でない場合、または与えられたresourceやaudienceが不明である場合、あるいはポリシーに基づき受け入れられない場合、信頼ドメインAのauthorization serverはリクエストを拒否しなければならない（MUST）。
  • 信頼ドメインAのauthorization serverはclaimsを追加、削除、または変更してもよい（MAY）。Claims transcription（Section 2.5）を参照。

2.3.3. Token Exchange Response

[RFC8693] のsection 2.2がすべて適用される。加えて、この仕様に適合する実装には以下が適用される。

  • 返されるJWT authorization grantの"aud" claimは、要求された信頼ドメインBのauthorization serverを識別しなければならない（MUST）。これはRFC 7523 Section 3, Point 3（https://datatracker.ietf.org/doc/html/rfc7523#section-3）に対応し、誤用を減らすこと、および、例えばクライアントがaccess tokensを信頼ドメインBのauthorization serverへauthorization grantとして提示するといった行為を含め、様々な不正利用を防ぐ目的がある。
  • 返されるJWT authorization grantに含まれる"aud" claimは、信頼関係（例：フェデレーション）を持つ複数のauthorization serversを識別してもよい（MAY）。信頼ドメインBのauthorization serverが、クライアントのauthorization grantを別の信頼ドメインのauthorization serverへ提示してしまうことを防ぐため、"aud" claimを信頼ドメインBの単一のauthorization serverに制限することが推奨される（RECOMMENDED）。例えばこれにより、信頼ドメインBのauthorization serverが、信頼ドメインAのクライアントから受け取ったauthorization grantを、信頼ドメインCのauthorization serverへ提示することを防げる。

2.3.4. Example

以下の例は、信頼ドメインAのクライアントが、信頼ドメインAのauthorization server（https://as.a.org/auth）とtoken exchangeを実行して、信頼ドメインBのauthorization server（https://as.b.org/auth）のためのJWT authorization grantを受け取る際に起動されるメッセージを示す。

POST /auth/token HTTP/1.1
Host: as.a.org
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&resource=https%3A%2F%2Fas.b.org%2Fauth
&subject_token=ey...
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token

Figure 2: Token exchange request

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJo
  dHRwczovL2FzLmEub3JnL2F1dGgiLCJleHAiOjE2OTUyODQwOTIsImlhdCI6MTY5N
  TI4NzY5Miwic3ViIjoiam9obl9kb2VAYS5vcmciLCJhdWQiOiJodHRwczovL2FzLm
  Iub3JnL2F1dGgifQ.304Pv9e6PnzcQPzz14z-k2ZyZvDtP5WIRkYPScwdHW4",
  "token_type": "N_A",
  "issued_token_type": "urn:ietf:params:oauth:token-type:jwt",
  "expires_in": 60
}

Figure 3: Token exchange response

2.4. JWT Authorization Grant

信頼ドメインAのクライアントは、信頼ドメインAのauthorization serverから取得したJWT authorization grantをassertionとして用い、[RFC7523] に記述されるとおり、信頼ドメインBのauthorization serverに対してaccess tokenを要求する。

2.4.1. Access Token Request

本仕様の文脈では、以下の説明が適用される。

  • grant_type\ REQUIRED。[RFC7523] のSection 2.1で定義されるとおり、値urn:ietf:params:oauth:grant-type:jwt-bearerは、このリクエストがJWT bearer assertionのauthorization grantであることを示す。
  • assertion\ REQUIRED。ドメインAのauthorization serverから返されたauthorization grant（Token Exchange（Section 2.3）のレスポンスを参照）。
  • scope\ OPTIONAL。

信頼ドメインAのクライアントは、scopeパラメータ、または [RFC8707] で定義されるresourceパラメータを通じて、アクセスしようとしている保護されたリソースを示してもよい（MAY）。

2.4.2. Processing rules

信頼ドメインBのauthorization serverは、[RFC7523] のSections 3および3.1で規定されるとおりにJWT authorization grantを検証しなければならない（MUST）。以下の処理規則も適用される。

  • "aud" claimは、[RFC7523] のSection 3で説明されるtoken endpoint、または [RFC8414] のSection 2で定義されるissuer identifierのいずれかを用いて、assertionの妥当な意図されたaudienceとして信頼ドメインBのauthorization serverを識別しなければならない（MUST）。
  • 信頼ドメインBのauthorization serverは、subjectを識別できない場合、リクエストを拒否するべきである（SHOULD）。
  • ポリシーによりリクエストが拒否される場合がある（MAY）（例えば、信頼ドメインAとのフェデレーションが確立されていない場合）。

2.4.3. Access Token Response

信頼ドメインBのauthorization serverは、[RFC6749] のsection 5.1で説明されるとおり、access tokenを返す。

2.4.4. Example

以下の例は、信頼ドメインAのクライアントが、信頼ドメインBのauthorization server（https://as.b.org/auth）にauthorization grantを提示し、信頼ドメインBの保護されたリソース向けのaccess tokenを受け取る方法を示す。

POST /auth/token HTTP/1.1
Host: as.b.org
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&assertion=ey...

Figure 4: Assertion request

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJo
  dHRwczovL2FzLmIub3JnL2F1dGgiLCJleHAiOjE2OTUyODQwOTIsImlhdCI6MTY5N
  TI4NzY5Miwic3ViIjoiam9obi5kb2UuMTIzIiwiYXVkIjoiaHR0cHM6Ly9iLm9yZy
  9hcGkifQ.CJBuv6sr6Snj9in5T8f7g1uB61Ql8btJiR0IXv5oeJg",
  "token_type": "Bearer",
  "expires_in": 60
}

Figure 5: Assertion response

2.5. Claims transcription

Claims transcriptionは、ユーザーおよびクライアント識別子、認可コンテキスト、その他の関連情報を信頼境界をまたいで伝播させる必要性により動機付けられている。これにより、関与する様々な主体が、リクエストが誰の代理で行われているのか、どのような認可が付与されたのか、そして場合によっては、以前にどのResource Serverが関与していたのかを判断できるようになる。

Authorization serversは、token exchangeフローでJWT authorization grantsを生成する場合、またはassertionフローでaccess tokensを生成する場合にclaimsを転記してもよい（MAY）。Claimsの転記は以下の理由により必要になる場合がある。

  • subject識別子の転記: subject識別子は、関与する当事者間で異なる場合がある。例えば、ユーザーは信頼ドメインAでは "johndoe@a.org" として識別されるが、信頼ドメインBでは "doe.john@b.org" として識別される、といったケースである。ある識別子から別の識別子へのマッピングは、token exchangeステップで行われて更新された識別子が返されるJWT authorization grantに反映される場合もあれば、assertionステップで行われて更新された識別子がaccess tokenに反映される場合もある。これを支援するため、両方のauthorization serversは、上述のとおりclaimsを追加、変更、または削除してもよい（MAY）。
  • データ最小化: Authorization serversは、プライバシー要件や、転送先の信頼ドメインに対する信頼度の低下により、特定のclaimsを削除または秘匿してもよい（MAY）。例として、第三者の決済ゲートウェイと統合する金融機関がある。ドメインA（金融機関）は、JWT authorization grantに "account type: premium" や "transaction limit: $10,000" のような詳細なclaimsを含める。しかしドメインB（決済ゲートウェイ）に必要なのは、アクセス制御ポリシーのための "transaction limit" のようなclaimsだけである。ドメインAは、不要な情報を除外するようにclaimsを転記し、ドメインBが自らの業務に関連するclaimsのみを受け取ることを保証する。
  • scopeの制御: クライアントは、scopeパラメータを用いて転記されるclaimsを制御してもよい（MAY）（例：downscoping）。Authorization Serversは、要求されたscopesが、提示されたsubject_tokenのscopesよりも高い権限を持たないことを検証するべきである（SHOULD）。例えば、開発者が複数の信頼ドメインにまたがるAPIへアクセスできるクラウドベースの開発プラットフォームを考える。ドメインAの開発者がドメインBのAPIへのアクセスを要求するが、必要なのは "read-only" のような限定的な権限だけである。この場合、ドメインAのauthorization serverは、JWT authorization grant内のclaimsを転記してdownscopedされた権限を反映し、"write" や "admin" といったより高権限のclaimsを削除する。これにより、ドメインBが発行するaccess tokenが、開発者が意図したアクセス範囲と整合することが保証される。
  • JWT authorization grantのclaimsを含める: assertionフローを実行する信頼ドメインBのauthorization serverは、信頼ドメインAのクライアントが提示するJWT authorization grantからclaimsを活用し、それらを返されるaccess tokenに含めてもよい（MAY）。設定されるclaimsは、無効なclaimsの注入を防ぐため、名前空間を付与するか検証されるべきである（SHOULD）。

転記されるclaimsの表現およびその形式は、本仕様では定義しない。

Claimsを転記する際には、claimsが与えられる場所と、それが解釈される場所の双方で意味（semantics）について合意し、アクセス制御が一貫していることが重要である。

3. Authorization Server Metadata

本仕様は以下のauthorization server metadataパラメータを定義し、「OAuth 2.0 Authorization Server Metadata」[RFC8414] により確立された "OAuth Authorization Server Metadata" レジストリに登録する。

  • identity_chaining_requested_token_types_supported\ OPTIONAL。Identity and Authorization Chaining Across Domainsを実行する際に、Token Exchangeリクエストのrequested_token_typeとして要求可能なToken Typesの一覧を含むJSON配列。Authorization serversは、このパラメータが使用されている場合でも、サポートしているrequested token typesの一部を広告しないことを選択してもよい（MAY）。また、値が存在しないことは、そのtoken typeが未サポートであることを必ずしも意味しない。

4. IANA Considerations

4.1. OAuth Authorization Server Metadata Registry

本仕様は、[RFC8414] により確立された "OAuth Authorization Server Metadata" レジストリにおいて、以下のパラメータを定義する。

4.1.1. Registry Contents

  • Metadata Name: identity_chaining_requested_token_types_supported
  • Metadata Description: Identity and Authorization Chaining Token Exchange（[RFC8693]）リクエストにおいて、requested_token_typeとしてサポートされるToken Type Identifiersの一覧を含むJSON配列。
  • Change Controller: IETF
  • Specification Document(s): Section 3

このレジストリは、[RFC8693] Token Exchangeにおいて要求可能なサポート済みtoken typesを記録する。

4.2. Media Types

本仕様は新たなmedia typesを定義しない。

JSON Web Token Best Current Practices [RFC8725] で定義される明示的なtypingを、任意のプロファイルまたは導入固有の実装が採用し、[RFC6838] で説明される方法に従い、"Media Types" レジストリ [IANA.media-types] に新しいmedia type [RFC2046] を定義することが推奨される（RECOMMENDED）。

5. Security Considerations

5.1. Client Authentication

Authorization Serversは、クライアント認証についてOAuth 2.0 SecurityのBest Current Practice [RFC9700] に従うべきである（SHOULD）。

5.2. Sender Constraining Tokens

Authorization Serversは、sender constraining tokensについてThe OAuth 2.1 Authorization Framework [I-D.draft-ietf-oauth-v2-1] に従うべきである（SHOULD）。

5.3. Authorized use of Subject Token

信頼ドメインAのauthorization serverは、authorization grantを発行する前に、クライアント認証を実行し、token exchangeフローにおけるsubject_tokenとして使用されるtokenをクライアント（信頼ドメインA）が提示することを認可されていることを検証するべきである（SHOULD）。これにより、攻撃者が信頼ドメインAから盗んだtokenを用いてauthorization grantを取得し、それを使って信頼ドメインBのauthorization serverに対して認証し、信頼ドメインBのResource Server向けのaccess tokenを要求する、といった横方向への移動（lateral move）のリスクを最小化できる。

5.4. Refresh Tokens

信頼ドメインBのauthorization serverは、本仕様の範囲内ではクライアントにRefresh Tokenを発行するべきではない（SHOULD NOT）。access tokenの期限が切れた場合、クライアントは元のJWT Authorization Grantを再提示し、新しいAccess Tokenを取得するべきである（SHOULD）。JWT Authorization Grantの期限が切れている場合、クライアントは信頼ドメインBのauthorization serverへ提示する前に、信頼ドメインAのauthorization serverから新しいgrantを要求するべきである（SHOULD）。信頼ドメインBのauthorization serverによるRefresh Tokenの発行は、追加のセキュリティ対策を要する冗長なクレデンシャルを導入し、不必要なセキュリティリスクを生み出す。また、信頼ドメインAにおける初期セッションが終了した後（例えばユーザーがログアウトした、またはアクセスが取り消された場合）であっても、クライアントが信頼ドメインB内でaccess tokensを取得できてしまう。この段落は、信頼ドメインAのauthorization serverによるrefresh tokensの発行とは関係しない。

5.5. Replay of Authorization Grant

Token Exchangeプロセスで取得したauthorization grantはbearer tokenである。攻撃者が信頼ドメインAのクライアントに発行されたauthorization grantを入手した場合、それを信頼ドメインBのauthorization serverに対してリプレイし、access tokenを取得できる可能性がある。実装は、このリスクを評価し、自身のThreat modelおよび導入環境に基づいて適切な緩和策を配備するべきである（SHOULD）。緩和策には、以下が含まれるが、これらに限られない。

  • authorization grantsを短命に発行し、露出の時間窓を最小化する。
  • authorization grantsを単回使用に制限し、繰り返しのリプレイを防ぐ。
  • client authenticationを要求し、grantを提示するクライアントが信頼ドメインBのauthorization serverに既知であることを保証する。

信頼ドメインBのauthorization serversは、これらの緩和策を強制してもよい（MAY）。

本仕様の実装およびプロファイルは、特定のユースケースおよび運用状況に合わせた追加の緩和策を定義してもよい（MAY）。

6. Privacy Considerations

[RFC8693] および [RFC7523] で概説されるプライバシー考慮事項に加え、以下の項目が本仕様に関連する。

OAuth federationは、異なる信頼ドメイン間でtokenおよびclaimsを交換する。過剰または不要なユーザーデータがこれらのtokenに含まれると、意図しないプライバシー上の結果につながる可能性がある。[RFC8693] および [RFC7523] で述べられているとおり、導入では交換を完了するために必要な最小限の情報を決定し、その情報のみがtokenに含まれるようにするべきである。

OAuth federationにおけるユーザープライバシーの取り扱いがドメイン間で一貫しない場合、各ドメインにおけるプロトコルの解釈や実装が異なることにより、プライバシー取り扱いの不整合が生じ得る。この不整合は、どのデータが共有され、誰と共有されるのかについて、透明性およびユーザー制御の欠如につながり得る。これを緩和するため、ドメイン間のフェデレーション信頼関係は、ユーザープライバシーを考慮して慎重に確立・維持されなければならない。これには、プライバシーポリシーが信頼ドメイン間で整合していることを検証し、ユーザーデータがどのように収集され、利用され、保護されるかを明確に定義することが含まれる。

7. References

7.1. Normative References

[RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
           RFC 6749, DOI 10.17487/RFC6749, October 2012,
           <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC8693]  Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
           and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
           DOI 10.17487/RFC8693, January 2020,
           <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC7523]  Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
           (JWT) Profile for OAuth 2.0 Client Authentication and
           Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
           2015, <https://www.rfc-editor.org/rfc/rfc7523>.

[RFC8707]  Campbell, B., Bradley, J., and H. Tschofenig, "Resource
           Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
           February 2020, <https://www.rfc-editor.org/rfc/rfc8707>.

[RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
           Authorization Server Metadata", RFC 8414,
           DOI 10.17487/RFC8414, June 2018,
           <https://www.rfc-editor.org/rfc/rfc8414>.

[RFC8725]  Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
           Current Practices", BCP 225, RFC 8725,
           DOI 10.17487/RFC8725, February 2020,
           <https://www.rfc-editor.org/rfc/rfc8725>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

7.2. Informative References

[I-D.draft-ietf-oauth-v2-1]
           Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1
           Authorization Framework", Work in Progress, Internet-
           Draft, draft-ietf-oauth-v2-1-13, 28 May 2025,
           <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
           v2-1-13>.

[RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
           Extensions (MIME) Part Two: Media Types", RFC 2046,
           DOI 10.17487/RFC2046, November 1996,
           <https://www.rfc-editor.org/rfc/rfc2046>.

[RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
           Specifications and Registration Procedures", BCP 13,
           RFC 6838, DOI 10.17487/RFC6838, January 2013,
           <https://www.rfc-editor.org/rfc/rfc6838>.

[RFC9700]  Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
           "Best Current Practice for OAuth 2.0 Security", BCP 240,
           RFC 9700, DOI 10.17487/RFC9700, January 2025,
           <https://www.rfc-editor.org/rfc/rfc9700>.

[RFC9728]  Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0
           Protected Resource Metadata", RFC 9728,
           DOI 10.17487/RFC9728, April 2025,
           <https://www.rfc-editor.org/rfc/rfc9728>.

[IANA.media-types]
           IANA, "Media Types",
           <https://www.iana.org/assignments/media-types>.

Appendix A. Use cases

本セクションでは、本書で説明するアイデンティティおよび認可のチェイニングを適用できるユースケースの一部を概説する。ここで説明されるユースケースは網羅的ではないが、本仕様が可能にするユースケースの種類を代表するものである。本仕様により、他のユースケースもサポートされ得る。

A.1. Preserve User Context across Multi-cloud, Multi-Hybrid environments

ユーザーは、オンプレミスおよびクラウドベースの複数のワークロードとして実装されたサービスへアクセスしようとする。オンプレミスおよびクラウドベースのサービスはいずれも、1つ以上のオンプレミスまたはクラウドサービス環境にまたがる複数の信頼境界により分割されている。各ワークロードは、元のユーザーのコンテキストに加え、中継するサービスのコンテキストも考慮する認可ポリシーを適用できる。これは、ワークロードがどこで実行されているかに依らず、また、ある信頼ドメインのワークロードが別の信頼ドメインの別サービスを呼び出す場合であっても成り立つ。

A.2. Continuous Integration Accessing External Resources

継続的インテグレーション（CI）システムは、例えば成果物（artifact）をアップロードしたり、テストを実行したりするために、外部リソースへアクセスする必要がある。これらのリソースは、異なるauthorization serversによって保護されている。ビルドのアイデンティティ情報、例えばコミットハッシュやリポジトリといったメタデータは、ドメイン境界を越えて保持され、運搬されるべきである。これにより、クレデンシャルを維持する必要をなくすだけでなく、リソースにおいて粒度の細かいアクセス制御も可能になる。

A.3. API Security Use Case

住宅向けデバイス企業が、家庭用カメラへのアクセスを可能にするために「Camera API」を提供している。パートナー企業は、このCamera APIを利用して、カメラ映像を自社のセキュリティダッシュボードに統合する。パートナーとCamera APIの間でOAuthを用いることで、パートナーは家庭用カメラからの映像を、ダッシュボードに表示するために要求できる。ユーザーはカメラ提供者にアカウントを持つ。ユーザーは、パートナーが提供するダッシュボードを閲覧するためにログインしている場合もあれば、緊急時のカメラアクセスを認可する場合もある。住宅向けデバイス企業は、そのリクエストが、要求された家庭用カメラの映像を閲覧する権限を持つユーザーによって発生し、かつ認可されたものであることを独立に検証できなければならない。

A.4. Extend Single Sign-On to API Access

企業のIdentity Provider (IdP) に認証されたユーザーは、SaaSアプリケーションが企業IdPを信頼するように設定されていれば、複数のSaaSアプリケーションへサインインし直す必要がない。このSSO関係は、Clientが企業IdPへ連絡し、以前に企業IdPから受け取ったidentity assertion（ID TokenまたはSAML Token）をauthorization grantへ交換できるようにすることで、APIアクセスへ拡張できる。企業IdP（authorization grantの発行者）とSaaS authorization serverの間に信頼関係が確立されていることを条件に、そのauthorization grantを用いてSaaSアプリケーションのauthorization serverからaccess tokenを取得できる。その結果、企業IdPを信頼するSaaSサーバーは、SaaS提供者のAPIへアクセスするためのaccess tokenを取得するにあたり、ユーザーが対話的な委任OAuth 2.0フローを完了することを要求しない。

A.5. Cross-domain API authorization

電子メールクライアントは、各電子メールクライアントと各電子メールサーバーの間に事前に関係が確立されていなくても、任意のメールサーバーとともに使用できる。電子メールクライアントは、IdPからidentity assertion（ID TokenまたはSAML token）を取得する。電子メールクライアントが、第三者のカレンダーアプリケーションのような別のAPIへアクセスする必要がある場合、電子メールクライアントはidentity assertionをauthorization grantへ交換し、このauthorization grantを用いて、第三者カレンダーアプリケーションが信頼するauthorization serverから、第三者カレンダーアプリケーション向けのaccess tokenを取得する。authorization serverがauthorization grantのissuerを信頼するなら、電子メールクライアントは追加のユーザー操作なしにaccess tokenを取得できる。

Appendix B. Examples

本セクションには2つの例があり、異なる環境と特定要件において本仕様がどのように使用され得るかを示す。1つ目の例はResource Serverがクライアントとして振る舞うケースを示し、2つ目の例はauthorization serverがクライアントとして振る舞うケースを示す。

B.1. Resource server acting as client

リクエストを完了する過程で、信頼ドメインAのResource Serverが、信頼ドメインBのResource Serverへアクセスする必要が生じる場合がある。これには、信頼ドメインBのauthorization serverからAccess Tokenを取得し、それを信頼ドメインBのResource Serverへ提示することが必要となる場合がある。信頼ドメインAのResource Serverは、信頼ドメインBのResource Serverへアクセスしようとする際にクライアントの役割を担うことで、本仕様で説明するフローを使用できる。Resource serversは、以下が成り立つ場合にクライアントとして振る舞える。

  • Resource Serverが、信頼ドメインAの外部にある保護されたリソースのauthorization serverを特定できる能力を持つ。
  • 信頼ドメインBのauthorization serverへ、信頼ドメインAのResource Serverから到達可能であり、必要に応じて適切なクライアント認証を実行できる。

フローは以下のようになる。

 +-------------+       +---------------+     +-------------+ +---------+
 |Authorization|       |Resource Server|     |Authorization| |Protected|
 |Server       |       |Trust Domain A |     |Server       | |Resource |
 |Trust        |       |(acting as     |     |Trust        | |Trust    |
 |Domain A     |       | a client)     |     |Domain B     | |Domain B |
 +-------------+       +---------------+     +-------------+ +---------+
        |                     |                     |             |
        |                     |   (A) request protected resource  |
        |                     |      metadata                     |
        |                     | --------------------------------->|
        |                     | <- - - - - - - - - - - - - - - - -|
        |                     |                     |             |
        | (B) exchange token  |                     |             |
        |   [RFC 8693]        |                     |             |
        |<--------------------|                     |             |
        |                     |                     |             |
        | (C) <authorization  |                     |             |
        |        grant>       |                     |             |
        | - - - - - - - - -  >|                     |             |
        |                     |                     |             |
        |                     | (D) present         |             |
        |                     |  authorization      |             |
        |                     |  grant [RFC 7523]   |             |
        |                     |-------------------->|             |
        |                     |                     |             |
        |                     | (E) <access token>  |             |
        |                     |<- - - - - - - - - - |             |
        |                     |                     |             |
        |                     |               (F) access          |
        |                     | --------------------------------->|
        |                     |                     |             |

               Figure 6: Resource server acting as client

このフローは以下のステップからなる。

信頼ドメインAのResource Serverは、信頼ドメインBの保護されたリソースへアクセスする必要がある。そのためにはaccess tokenが必要である。必要なaccess tokenを取得するために、信頼ドメインAのResource Serverはクライアントとして振る舞う。

(A) 信頼ドメインAのResource Server（クライアントとして動作）は、[RFC9728] に記述されるとおり、信頼ドメインBのResource Serverに対してprotected resource metadataを要求する。このresource metadataを用いて、信頼ドメインBのauthorization serverに関する情報を発見する。このステップは、discoveryが不要であれば省略してもよい（MAY）。また、他のdiscovery手段を用いてもよい（MAY）。信頼ドメインBの保護されたリソースは、信頼ドメインAにおけるauthorization server情報とともに、自身のmetadataを返す。

(B) 信頼ドメインAのResource Server（クライアントとして動作）が信頼ドメインBのauthorization serverを特定したら、信頼ドメインAのauthorization server（自分自身のauthorization server）に対して、信頼ドメインBのauthorization server向けのJWT authorization grantを要求する。これはtoken exchangeプロトコル（Token Exchange（Section 2.3）を参照）を通じて行われる。

(C) 成功した場合、信頼ドメインAのauthorization serverは、信頼ドメインAのResource Server（クライアントとして動作）にJWT authorization grantを返す。

(D) 信頼ドメインAのResource Server（クライアントとして動作）は、信頼ドメインBのauthorization serverにJWT authorization grantを提示する。

(E) 信頼ドメインBのauthorization serverは、JWT authorization grantからclaimsを用いてユーザーを識別し、追加の認可コンテキストを確立する。アクセスが許可される場合、信頼ドメインBのauthorization serverはaccess tokenを返す。

(F) 信頼ドメインAのResource Server（クライアントとして動作）は、access tokenを用いて信頼ドメインBの保護されたリソースへアクセスする。

B.2. Authorization server acting as client

Authorization serversもクライアントとして振る舞う場合がある。これは以下の理由から必要になり得る。

  • 信頼ドメインAのクライアントは、信頼ドメインBのauthorization serversを知らない場合がある。
  • 信頼ドメインAのクライアントは、信頼ドメインBの他のauthorization serversへのネットワークアクセスを持たない場合がある。
  • 信頼ドメインBのリソースに対して厳格なアクセス制御が必要である。このアクセス制御は、信頼ドメインBのauthorization serversによって強制される。
  • 信頼ドメインBのauthorization serversはクライアント認証を要求するが、信頼ドメインBの外にあるクライアントを管理できない。

これらの条件下では、信頼ドメインAのauthorization serverは、信頼ドメインAの任意のクライアントの代理で、信頼ドメインBのauthorization serverからaccess tokenを取得できる。これにより、信頼ドメインAのクライアントは信頼ドメインBの保護されたResource Serverへアクセスできる。信頼ドメインAのResource serversは、リクエストを完了するために、信頼ドメインBの保護されたリソースへアクセスするaccess tokenを取得する目的で、信頼ドメインAのauthorization serverに対するクライアントとして振る舞う場合がある。

信頼ドメインAのauthorization serverは、まず自分自身に対するクライアントとして振る舞いassertion grantを取得し、その後、信頼ドメインBのauthorization serverに対するクライアントとして振る舞って、信頼ドメインBの保護されたリソース向けのaccess tokenを要求することで、本仕様で説明するフローを使用できる。Authorization serversが、自分自身の信頼ドメイン内の別クライアントの代理としてクライアントとして振る舞う場合のフローを以下に示す。

 +--------+          +--------------+       +--------------+ +---------+
 |Client  |          |Authorization |       |Authorization | |Protected|
 |Trust   |          |Server        |       |Server        | |Resource |
 |Domain A|          |Trust Domain A|       |Trust Domain B| |Trust    |
 |        |          |(acting as    |       |              | |Domain   |
 |        |          |client)       |       |              | |         |
 +--------+          +--------------+       +--------------+ +---------+
     |                      |                       |             |
     | (A) request          |                       |             |
     | token for            |                       |             |
     | protected resource   |                       |             |
     | in trust domain B.   |                       |             |
     | -------------------->|                       |             |
     |                      |                       |             |
     |                      |----+                  |             |
     |                      |    | (B) determine    |             |
     |                      |<---+ authorization    |             |
     |                      |      server trust     |             |
     |                      |      domain B         |             |
     |                      |                       |             |
     |                      |----+                  |             |
     |                      |    | (C) generates    |             |
     |                      |<---+ authorization    |             |
     |                      |      grant            |             |
     |                      |                       |             |
     |                      | (D) present           |             |
     |                      |   authorization grant |             |
     |                      |   [RFC 7523]          |             |
     |                      | --------------------->|             |
     |                      |                       |             |
     |                      | (E) <access token>    |             |
     |                      | <- - - - - - - - - - -|
     |                      |                       |             |
     |  (F) <access token>  |                       |             |
     | <- - - - - - - - - - |                       |             |
     |                      |                       |             |
     |                      |           (G) access  |             |
     | ---------------------------------------------------------->|
     |                      |                       |             |

            Figure 7: Authorization server acting as client

このフローは以下のステップからなる。

(A) 信頼ドメインAのクライアントは、信頼ドメインBの保護されたリソース向けのtokenを、信頼ドメインAのauthorization serverから要求する。本仕様はこのステップを定義しない。Token Exchange [RFC8693] のプロファイルが使用され得る。

(B) 信頼ドメインAのauthorization serverは、信頼ドメインBのauthorization serverを決定する。これはクライアントから渡される場合も、静的に維持される場合も、動的に解決される場合もある。

(C) 信頼ドメインBのauthorization serverが決定されると、ドメインAのauthorization serverは、信頼ドメインBのauthorization serverへの提示に適したJWT authorization grantを生成する。

(D) 信頼ドメインAのauthorization serverはクライアントとして振る舞い、JWT authorization grantを信頼ドメインBのauthorization serverへ提示する。この提示はauthorization servers間で行われる。信頼ドメインAのauthorization serverは、その際にクライアント認証を実行する必要がある場合がある。これは本仕様におけるAccess Token Request（Section 2.4.1）に対応する。

(E) 信頼ドメインBのauthorization serverは、信頼ドメインAのauthorization server（クライアントとして動作）に対して、信頼ドメインBの保護されたリソース向けのaccess tokenを返す。

(F) 信頼ドメインAのauthorization serverは、信頼ドメインAのクライアントへaccess tokenを返す。

(G) 信頼ドメインAのクライアントは、受け取ったaccess tokenを用いて信頼ドメインBの保護されたリソースへアクセスする。

B.3. Delegated Key Binding

一部の環境では、信頼ドメインBのauthorization serverが発行するaccess tokenを、信頼ドメインAのクライアントが保持する秘密鍵に紐付ける必要がある。これは、信頼ドメインBのResource Serverが、信頼ドメインAのクライアントが信頼ドメインBのResource Serverへtokenを提示する際に、信頼ドメインAのクライアントの秘密鍵の所持（proof of possession）を検証できるようにするためである。信頼ドメインAの任意のアプリケーションがクライアントとして振る舞い得る。これには、信頼ドメインAのResource serversであり、リクエストを完了するために信頼ドメインBのResource serversへアクセスする必要があるアプリケーションも含まれる。

信頼ドメインAのResource Serverがクライアントとして振る舞う場合には、Security Considerations（Sender Constraining Tokens（Section 5.2）を参照）に記述される既存手法を用いてaccess tokenを制約できる場合がある。

信頼ドメインAのauthorization serverがクライアントとして振る舞うケースは、信頼ドメインAのauthorization server（クライアントとして動作）が、access tokenが要求されるクライアントの鍵素材へアクセスできないため、より複雑である。

しかし、信頼ドメインAのauthorization serverと信頼ドメインBのauthorization serverの間の信頼関係を活用することで、信頼ドメインBのauthorization serverが発行するaccess tokenに対してsender constrainingを行える。これは以下のとおり実現できる。

  • 信頼ドメインAのauthorization serverは、クライアントが提示する鍵の所持証明（proof of possession）を検証する。
  • その後、信頼ドメインAのauthorization serverは、信頼ドメインBのauthorization serverへ送信するtoken requestの中で、信頼ドメインAのクライアントの鍵を伝達する。例えば、信頼ドメインBのauthorization serverへ送るassertion authorization grantにおいて、信頼ドメインAのクライアントの"cnf" claimを含む"requested_cnf" claimを含めることで実現できる。
  • 次に、信頼ドメインBのauthorization serverは、返されるaccess tokenにおいて、authorization grantに含まれる"requested_cnf" claimの値に一致する"cnf" claimを含める。
  • access tokenを提示する信頼ドメインAのクライアントは、Resource Server（信頼ドメインB）へaccess tokenを提示する際に、"cnf" claimに一致する鍵を使用してDPoP proofを生成するか、またはmTLSセッションを確立しなければならない。

Appendix C. Acknowledgements

編集者は、この作業への貴重な入力、フィードバック、および一般的な支援を提供してくれた Patrick Harding、Joe Jubinski、Watson Ladd、Justin Richer、Adam Rusbridge、Dean H. Saxe、ならびにその他の方々（誤って欠落している場合はお知らせください）に感謝する。

Appendix D. Document History

[[ 最終仕様から削除予定 ]]

-06

  • toolingが明示的なtargetなしでmedia typesレジストリを見つけられるように、IANA.media-typesを使用する
  • 信頼ドメインAのプラットフォームがJWT authorization grantを取得する別手段を提供する場合、RFC8693のtoken exchangeが厳密には不要であることに言及する
  • 必要な信頼関係をより良く説明する（ドメインBは、ドメインAがJWT authorization grantsを発行すること、および署名鍵を信頼しなければならない）とともに、AS Metadataのjwks_uriを用いて信頼ドメインAの検証鍵を取得できることに言及する
  • claimsを転記する際に、意味（semantics）などについて合意する必要がある旨の注記を追加する
  • 編集上の修正

-05

  • 付録の整合性のための編集パス
  • Introductionを明確化
  • 制約されていないauthorization grantsに関するSecurity Considerationsを追加
  • 一部のContributorsの所属および連絡先情報を更新
  • Claims transcriptionの本文に例を追加
  • JWT Authorization Grantセクションの一部の文章を簡略化
  • 一部のtoolchainの苦情およびその他の細かな指摘を修正
  • Privacy Considerationsを追加
  • 彼の貢献を踏まえ、謝辞（acknowledgements）からcontributorsへMr. Pareckiを移動
  • サポートされるToken Exchange requested token typesを公開するために、Authorization Server Metadataレジストリを追加

-04

  • authorization serverがクライアントとして振る舞う図と説明を明確化
  • sd-jwtへの参照を削除
  • 明示的なtypingの使用を推奨する文章を追加

-03

  • 編集上の更新

-02

  • RFC8693のrequested_token_typeを使わないという推奨を削除
  • Resource serverがクライアントとして振る舞う例における、図のアルファベット表記と本文の不一致を修正

-01

  • authorization grant形式をRFC7523のJWTに限定
  • 例の軽微な修正
  • 編集上の修正
  • Aaron Pareckiを謝辞に追加
  • セクション見出しを、より明確になるよう改名
  • より具体的な用語 "JWT authorization grant" を使用
  • 名称を "OAuth Identity and Authorization Chaining Across Domains" に変更
  • ユースケースを付録へ移動し、継続的インテグレーションのユースケースを追加

-00

  • Working Groupの初期版（以前はdraft-schwenkschuster-oauth-identity-chaining）

Contributors

Atul Tulshibagwale\ SGNL\ Email: atuls@sgnl.ai

George Fletcher\ Practical Identity LLC\ Email: gffletch@gmail.com

Rifaat Shekh-Yusef\ Ciena\ Email: rifaat.s.ietf@gmail.com

Hannes Tschofenig\ Email: hannes.tschofenig@gmx.net

Aaron Parecki\ Okta\ Email: aaron@parecki.com

Authors' Addresses

Arndt Schwenkschuster\ SPIRL\ Email: arndts.ietf@gmail.com

Pieter Kasselmann\ SPIRL\ Email: pieter@spirl.com

Kelley Burgin\ MITRE\ Email: kburgin@mitre.org

Mike Jenkins\ NSA-CCSS\ Email: mjjenki@cyber.nsa.gov

Brian Campbell\ Ping Identity\ Email: bcampbell@pingidentity.com