Web Authorization Protocol                                    A. Parecki
Internet-Draft                                                      Okta
Intended status: Standards Track                           K. McGuinness
Expires: 22 April 2026                                       Independent
                                                             B. Campbell
                                                           Ping Identity
                                                         19 October 2025

draft-ietf-oauth-identity-assertion-authz-grant-01

Abstract

本仕様は、共通のエンタープライズ Identity Provider を介して調整しながら、Token Exchange [RFC8693] と JWT Profile for OAuth 2.0 Authorization Grants [RFC7523] を用いて、アプリケーションが identity assertion を利用し、サードパーティ API 向けの Access Token を取得できる仕組みを提供する。

About This Document

この注記は、RFC として公開する前に削除すること。

このドラフトの最新改訂版は、以下で確認できる。\ https://drafts.oauth.net/oauth-identity-assertion-authz-grant/draft-\ ietf-oauth-identity-assertion-authz-grant.html.\ この文書のステータス情報は https://datatracker.ietf.org/doc/\ draft-ietf-oauth-identity-assertion-authz-grant/ で確認できる。

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

このドラフトのソースと Issue トラッカーは、以下で確認できる。\ https://github.com/oauth-wg/oauth-identity-assertion-authz-grant.

Status of This Memo

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

Internet-Drafts は Internet Engineering Task Force（IETF）の作業文書である。なお、他のグループも作業文書を Internet-Drafts として配布する場合がある。現行の Internet-Drafts の一覧は https://datatracker.ietf.org/drafts/current/ にある。

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

この Internet-Draft は 22 April 2026 に失効する。

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.

本文書は、この文書の公開日に有効な 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

• Identity Assertion JWT Authorization Grant
  • Abstract
  • About This Document
  • Status of This Memo
  • Copyright Notice
  • Table of Contents
• 1. Introduction
• 2. Conventions and Definitions
  • 2.1. Roles
    • Client
    • IdP Authorization Server (IdP)
    • Resource Authorization Server (AS)
    • Resource Server (RS)
• 3. Identity Assertion JWT Authorization Grant
  • 非規範的な JWT 例（header/payload 展開）
• 4. Cross-Domain Access
  • 4.1. Overview
    • Table 1
    • Sequence Diagram
  • 4.2. User Authentication
    • Token Endpoint への交換例
• 4.3. Token Exchange
  • 4.3.1. Processing Rules
  • 4.3.2. Response
    • 4.3.2.1. Issued Identity Assertion JWT Authorization Grant
    • 4.3.2.2. Error Response
• 4.4. Access Token Request
  • 例
  • 4.4.1. Processing Rules
  • 4.4.2. Response
  • 4.4.3. Refresh Token
• 5. Cross-Domain Client ID Handling
• 6. Authorization Server (IdP) Metadata
• 7. Security Considerations
  • 7.1. Client Authentication
  • 7.2. Step-Up Authentication
  • 7.3. Cross-Domain Use
• 8. IANA Considerations
  • 8.1. Media Types
  • 8.2. OAuth URI Registration
  • 8.3. JSON Web Token Claims Registration
• 9. References
  • 9.1. Normative References
  • 9.2. Informative References
• Appendix A. Use Cases
  • A.1. Enterprise Deployment
  • A.1.1. Preconditions
  • A.2. Email and Calendaring Applications
  • A.2.1. Preconditions
  • A.3. LLM Agent using Enterprise Tools
  • A.3.1. Preconditions
  • A.3.2. Example Sequence
• A.3.2.1. LLM Agent establishes a User Identity with Enterprise IdP
• A.3.2.2. IdP Authorization Request (with PKCE)
• A.3.2.3. User authenticates and authorizes LLM Agent
• A.3.2.4. LLM Agent calls Enterprise External Tool
• A.3.2.5. LLM Agent obtains an Identity Assertion JWT Authorization Grant for Enterprise External Tool from the Enterprise IdP
• A.3.2.6. LLM Agent obtains an Access Token for Enterprise External Tool
• A.3.2.7. LLM Agent makes an authorized External Tool request
• Acknowledgments
• Document History
  • -01
  • -00
• Authors' Addresses

1. Introduction

典型的なエンタープライズのシナリオでは、アプリケーションは OpenID Connect または SAML を用いて、エンタープライズ Identity Provider（IdP）へのシングルサインオン向けに設定される。これにより、ユーザーは IdP における 1 つのアカウントを用いて必要なエンタープライズアプリケーションすべてへアクセスでき、さらにエンタープライズ側は、どのユーザーがどのアプリケーションへアクセスできるかを管理できる。

あるアプリケーションが別のアプリケーション上のユーザーデータへアクセスしたい場合、ユーザーの代理として当該アプリケーション向けの Access Token を取得するため、対話的な OAuth フロー [RFC6749] を開始する。この OAuth フローは、2 つのアプリ間の直接的なアプリ間接続を可能にし、各アプリへのログインに使われる IdP からは見えない。

本仕様は、この種の「Cross App Access」を、IdP が個々のアプリケーションへのシングルサインオンを管理するのと同様に、エンタープライズ IdP によって管理できるようにする。

ドラフト仕様 Identity Chaining Across Trust Domains [I-D.ietf-oauth-identity-chaining] は、Authorization Server から JWT authorization grant を要求し、それを別の信頼ドメインにある別の Authorization Server で Access Token と交換する方法を定義している。この仕様は OAuth 2.0 Token Exchange [RFC8693] と JSON Web Token（JWT）Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523] を組み合わせたものである。このドラフトは、token exchange request と JWT authorization grant の多くの詳細を未規定のままにすることで、複数の異なるユースケースを支援する。

本仕様は、2 つのアプリケーションが同一のエンタープライズ Identity Provider へのシングルサインオン向けに設定されている場合に、エンタープライズシナリオで相互運用可能な実装を支援するために必要な追加の詳細を定義する。特に、本仕様では token exchange request の入力として identity assertions を使用する。これにより、シングルサインオンでアプリケーションから信頼されている同一のエンタープライズ Identity Provider を、API へのアクセスを仲介する用途へ拡張できる。

2. Conventions and Definitions

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

2.1. Roles

Client

サインイン済みユーザーの代理として、外部／サードパーティのアプリケーションの API（下記 Resource Server）に対する OAuth 2.0 access token を取得したいアプリケーション。[I-D.ietf-oauth-identity-chaining] では、信頼ドメイン A における Client に相当する。このアプリケーションは、Relying Party としてシングルサインオンのために IdP Authorization Server と直接の関係を持ち、さらに信頼ドメイン B の Resource Authorization Server とは、別個の独立した OAuth 2.0 クライアント関係を持つ。

IdP Authorization Server (IdP)

SAML 2.0 Identity Provider または OpenID Connect Provider (OP) [OpenID.Core]。シングルサインオンおよびクロスドメインの authorization grants（Section 3）向けの identity assertions を、組織のアプリケーションエコシステム内の信頼されたアプリケーション群に対して発行する。[I-D.ietf-oauth-identity-chaining] では、信頼ドメイン A の Authorization Server に相当し、これは信頼ドメイン B の Resource Authorization Server からも信頼される。

Resource Authorization Server (AS)

Resource Server により提供される保護リソース向けの OAuth 2.0 access tokens を発行する。[I-D.ietf-oauth-identity-chaining] では、信頼ドメイン B の Authorization Server に相当し、IdP Authorization Server からのクロスドメイン authorization grants（Section 3）を信頼する。

Resource Server (RS)

保護リソースをホストし、Resource Authorization Server が発行した access tokens を検証する。[I-D.ietf-oauth-identity-chaining] では、信頼ドメイン B の Protected Resource に相当する。Resource Server は IdP Authorization Server と直接の信頼関係を持たない。代わりに、信頼する Resource Authorization Server が発行した access tokens を検証することで、誰がリソースへアクセスすべきかを判断する。

3. Identity Assertion JWT Authorization Grant

Identity Assertion JWT Authorization Grant（ID-JAG）は、JWT Authorization Grant [RFC7523] のプロファイルであり、Authorization Server における直接のユーザー承認手順なしに、別の信頼ドメインのリソースへ、ユーザーの代理としてクライアントに委任アクセスを付与する。

Identity Assertion JWT Authorization Grant は、ID Token [OpenID.Core] と同様に IdP によって発行・署名され、End-User に関する claims を含む。assertion の intended audience としてクライアント（[OpenID.Core] における Relying Party）向けに発行されるのではなく、別の信頼ドメインにある Authorization Server を audience として発行される。これは、Resource Authorization Server から Authorization Code を取得してクライアントへアクセスを委任する必要を置き換え、代わりに Authorization Server から信頼されている IdP により、クライアントへのアクセス委任を行う。

[OpenID.Core] に記載のとおり、ID Tokens は（ID Token の audience により示される）Relying Party、または（例：revocation のための）Issuer によって処理されることのみを意図しており、Authorization Server のような、別の信頼ドメインの他アクターによって処理されることは意図していない。

以下の claims が Identity Assertion JWT Authorization Grant 内で使用される。

• iss: REQUIRED - [RFC8414] で定義される IdP authorization server の issuer identifier
• sub: REQUIRED - [OpenID.Core] で定義される、Resource Authorization Server における Resource Owner の subject identifier（例：ユーザー ID）
• aud: REQUIRED - [RFC8414] で定義される Resource Authorization Server の issuer identifier
• client_id: REQUIRED - Resource Owner の代理として動作するクライアントの識別子。Resource Authorization Server によって認識されなければならない。相互運用性のため、クライアント識別子は [RFC8693] の Section 4.3 で定義される client_id であることが望ましい。追加の考慮事項は Section 5 を参照。
• jti: REQUIRED - [RFC7519] の Section 4.1.7 で定義される、この JWT の一意な ID
• exp: REQUIRED - [RFC7519] の Section 4.1.4 で定義されるとおり
• iat: REQUIRED - [RFC7519] の Section 4.1.6 で定義されるとおり
• resource: OPTIONAL - Resource Server の Resource Identifier（[RFC8707] の Section 2）（単一の URI または URI 配列）
• scope: OPTIONAL - [RFC6749] の Section 3.3 で記述される形式で、token に関連付けられた scopes の空白区切りリストを含む JSON 文字列
• tenant: OPTIONAL - [OpenID.Enterprise] で定義されるマルチテナント issuer の tenant identifier を表す JSON 文字列
• auth_time: OPTIONAL - [OpenID.Core] で定義される、End-User が Client に認証した時刻
• acr: OPTIONAL - [OpenID.Core] で定義される、End-User 認証時に満たされた Authentication Context Class Reference
• amr: OPTIONAL - [OpenID.Core] で定義される、End-User 認証に用いた認証方式の識別子

JWT header に示される JWT の typ は oauth-id-jag+jwt でなければならない。typed JWT の使用は JSON Web Token Best Current Practices（[RFC8725] の Section 3.11）で推奨されている。

非規範的な JWT 例（header/payload 展開）

{
  "typ": "oauth-id-jag+jwt"
}

{
  "jti": "9e43f81b64a33f20116179",
  "iss": "https://acme.idp.example",
  "sub": "U019488227",
  "aud": "https://acme.chat.example/",
  "client_id": "f53f191f9311af35",
  "exp": 1311281970,
  "iat": 1311280970,
  "resource": "https://acme.chat.example/api",
  "scope": "chat.read chat.history",
  "auth_time": 1311280970,
  "amr": [
    "mfa",
    "phrh",
    "hwk",
    "user"
  ]
}

signature

Identity Assertion JWT Authorization Grant には、grant が Resource App に対する identity assertion として機能するため、ID Token として有効な追加の Authentication、Identity、または Authorization の claims を含めてもよい。

実装上の注記:

• sub は不透明な ID とするのが望ましい（iss+sub が一意となるため）。IdP はここにユーザーの email も含めたい場合があり、その場合は新しい email claim として含めるべきである。これにより、email address を持つアカウントはあるもののまだ SSO を行っていない既存ユーザーの重複排除がアプリで可能になる。

4. Cross-Domain Access

4.1. Overview

例のフローは、企業 acme を対象としており、異なるベンダーのマルチテナント wiki app と chat app を使用し、どちらも OpenID Connect を用いて企業のマルチテナント Identity Provider に統合されている。

Table 1

Role	App URL	Tenant URL	Description
Client	https://wiki.example	https://acme.wiki.example	1 つ以上の resource servers からのコンテンツを埋め込む Wiki app
Resource Authorization Server	https://chat.example	https://acme.chat.example	chat および communication app の Authorization Server
Identity Provider Authorization Server	https://idp.example	https://acme.idp.example	Enterprise Identity Provider
Resource Server	https://api.chat.example	https://api.chat.example	chat および communications app の Public API

Sequence Diagram

+---------+       +---------------+  +---------------+  +----------+
|         |       |      IdP      |  |   Resource    |  | Resource |
| Client  |       | Authorization |  | Authorization |  |  Server  |
|         |       |    Server     |  |    Server     |  |          |
+----+----+       +-------+-------+  +-------+-------+  +-----+----+
     |                    |                  |                 |
     |                    |                  |                 |
     | -----------------> |                  |                 |
     |   1 User SSO       |                  |                 |
     |                    |                  |                 |
     |     ID Token &     |                  |                 |
     | Refresh Token (Opt)|                  |                 |
     | <- - - - - - - - - |                  |                 |
     |                    |                  |                 |
     |                    |                  |                 |
     |                    |                  |                 |
     | 2 Token Exchange   |                  |                 |
     | ---------------->  |                  |                 |
     |                    |                  |                 |
     |   ID-JAG           |                  |                 |
     | <- - - - - - - -   |                  |                 |
     |                    |                  |                 |
     |                    |                  |                 |
     |                    |                  |                 |
     | 3 Present ID-JAG   |                  |                 |
     | -------------------+----------------> |                 |
     |                    |                  |                 |
     |    Access Token    |                  |                 |
     | <- - - - - - - - - - - - - - - - - - -|                 |
     |                    |                  |                 |
     |                    |                  |                 |
     |                    |                  |                 |
     | 4 Resource Request with Access Token  |                 |
     | ------------------------------------------------------> |
     |                    |                  |                 |
     |                    |                  |                 |
     |                    |                  |                 |

1. ユーザーが IdP Authorization Server で認証し、Client はユーザー向けの Identity Assertion（例：OpenID Connect ID Token または SAML 2.0 assertion）を取得し、さらに（OpenID Connect を使用する場合）任意で Refresh Token も取得して、ユーザーをサインインさせる。
2. Client は Identity Assertion を用いて、Resource Authorization Server 向けの Identity Assertion JWT Authorization Grant を IdP Authorization Server に要求する。
3. Client は、Resource Authorization Server の token endpoint において、Identity Assertion JWT Authorization Grant を Access Token と交換する。
4. Client は Access Token を用いて Resource Server に API リクエストを送る。

本仕様は、組織が利用するアプリケーション群の Resource Authorization Servers が、Single Sign-On（SSO）のために同一の IdP Authorization Server を信頼しているデプロイメントに限定される。IdP Authorization Server は、Resource Authorization Servers 群が IdP により発行された ID-JAG を尊重するための、一貫した信頼境界およびユーザーアイデンティティを提供する。Resource Authorization Server はユーザー認証を委任するだけでなく、ID-JAG に指定された scopes および resource に関するユーザーの認可権限についても IdP Authorization Server に委任し、Resource Owner から直接同意を取得する必要はない。

4.2. User Authentication

Client は OpenID Connect または SAML を用いて、IdP に対する認証リクエストを開始する。

以下は OpenID Connect を用いた例である。

302 Redirect
Location: https://acme.idp.example/authorize?response_type=code&scope=openid%20offline_access&client_id=...

ユーザーは IdP で認証し、Client へリダイレクトされる。その際、authorization code が付与され、Client はこれを ID Token と、offline_access scope が [OpenID.Core] に従って要求されている場合は任意で Refresh Token と交換できる。

注: IdP Authorization Server は、Client へのアクセスをユーザーに付与する前に、多要素認証などのセキュリティ制御を強制する場合がある。

Token Endpoint への交換例

POST /token HTTP/1.1
Host: acme.idp.example
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=.....

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id_token": "eyJraWQiOiJzMTZ0cVNtODhwREo4VGZCXzdrSEtQ...",
  "token_type": "Bearer",
  "access_token": "7SliwCQP1brGdjBtsaMnXo",
  "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
  "scope": "openid offline_access"
}

4.3. Token Exchange

Client は、以下の parameters を付けて、IdP の token endpoint へ Token Exchange [RFC8693] リクエストを送る。

• requested_token_type: REQUIRED - 値 urn:ietf:params:oauth:token-type:id-jag は、ID Assertion JWT が要求されていることを示す。
• audience: REQUIRED - [RFC8414] の Section 2 で定義される Resource Authorization Server の Issuer URL。
• resource: OPTIONAL - [RFC8707] の Section 2 で定義される Resource Server の Resource Identifier。
• scope: OPTIONAL - Resource Server で要求されている scopes の空白区切りリスト。
• subject_token: REQUIRED - 対象の End-User のための identity assertion（例：OpenID Connect ID Token または SAML assertion）。
• subject_token_type: REQUIRED - [RFC8693] の Section 3 で記述される識別子で、subject_token parameter に含まれる security token の型を示す。OpenID Connect ID Token の場合は urn:ietf:params:oauth:token-type:id_token、SAML assertion の場合は urn:ietf:params:oauth:token-type:saml2。

[RFC8693] の Section 2.1 で定義される追加 parameters のうち、actor_token と actor_token_type は本仕様では使用しない。

Authorization Server に対する Client 認証は、OAuth 2.0 が提供する標準の仕組みを用いて行う。[RFC6749] の Section 2.3.1 は、Client のパスワードベース認証（client_id と client_secret）を定義するが、Client 認証は拡張可能であり、他の仕組みも可能である。例えば [RFC7523] は、client_assertion および client_assertion_type を用いた bearer JSON Web Tokens による Client 認証を定義している。

以下の例は、Identity Assertion として ID Token を用い、Client 認証方式として JWT Bearer Assertion [RFC7523] を用いている（簡潔さのため token は省略している）。

POST /oauth2/token HTTP/1.1
Host: acme.idp.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=urn:ietf:params:oauth:token-type:id-jag
&audience=https://acme.chat.example/
&resource=https://api.chat.example/
&scope=chat.read+chat.history
&subject_token=eyJraWQiOiJzMTZ0cVNtODhwREo4VGZCXzdrSEtQ...
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6IjIyIn0...

4.3.1. Processing Rules

IdP は subject token を検証しなければならず、また Subject Token の audience（例：ID Token の aud claim）が、リクエストの Client 認証における client_id と一致することを検証しなければならない。

IdP は、token exchange request に対して管理者定義のポリシーを評価し、対象の audience と scopes に対して subject の代理として動作するためのアクセスを、Client に付与すべきかどうかを判断する。

IdP はまた、SSO assertion に記述された認証コンテキストを introspect し、step-up authentication が必要かどうかを判断してもよい。

4.3.2. Response

アクセスが付与される場合、IdP は署名済みの Identity Assertion JWT Authorization Grant（Section 3）を生成し、[RFC8693] の Section 2.2 で定義される token exchange response で返す。

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

{
  "issued_token_type": "urn:ietf:params:oauth:token-type:id-jag",
  "access_token": "eyJhbGciOiJIUzI1NiIsI...",
  "token_type": "N_A",
  "scope": "chat.read chat.history",
  "expires_in": 300
}

• issued_token_type: REQUIRED - urn:ietf:params:oauth:token-type:id-jag
• access_token: REQUIRED - Identity Assertion JWT Authorization Grant\ （注: Token Exchange は歴史的経緯により access_token response parameter を要求するが、これは OAuth の access token ではない。）
• token_type: REQUIRED - N_A（これは OAuth の access token ではないため。）
• scope: 発行された token の scope が、Client が要求した scope と同一であれば OPTIONAL。そうでなければ REQUIRED。IdP の各種ポリシーにより、アプリケーションが要求した scope と異なる scope が発行される場合がある。
• expires_in: RECOMMENDED - authorization grant の有効期間（秒）。
• refresh_token: [RFC8693] の Section 2.2 に従い OPTIONAL。\ ただし本仕様の文脈では、この parameter は使用すべきではない。

4.3.2.1. Issued Identity Assertion JWT Authorization Grant

以下は発行された token の非規範的な例である。

{
  "typ": "oauth-id-jag+jwt"
}

{
  "jti": "9e43f81b64a33f20116179",
  "iss": "https://acme.idp.example/",
  "sub": "U019488227",
  "aud": "https://acme.chat.example/",
  "client_id": "f53f191f9311af35",
  "exp": 1311281970,
  "iat": 1311280970,
  "resource": "https://api.chat.example/",
  "scope": "chat.read chat.history",
  "auth_time": 1311280970,
  "amr": [
    "mfa",
    "phrh",
    "hwk",
    "user"
  ]
}

signature

4.3.2.2. Error Response

エラー条件では、IdP は [RFC6749] の Section 5.2 で定義される OAuth 2.0 Token Error response を返す。例:

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

{
  "error": "invalid_grant",
  "error_description": "Audience validation failed"
}

4.4. Access Token Request

Client は、前段で取得した Identity Assertion JWT Authorization Grant を [RFC7523] に定義される JWT Bearer Assertion として使用し、Resource Authorization Server の token endpoint に access token request を送る。

• grant_type: REQUIRED - grant_type の値は urn:ietf:params:oauth:grant-type:jwt-bearer
• assertion: REQUIRED - 前段の token exchange 手順で取得した Identity Assertion JWT Authorization Grant

Client は、Resource Authorization Server に登録された資格情報で認証する。

例

POST /oauth2/token HTTP/1.1
Host: acme.chat.example
Authorization: Basic yZS1yYW5kb20tc2VjcmV0v3JOkF0XG5Qx2

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=eyJhbGciOiJIUzI1NiIsI...

4.4.1. Processing Rules

[RFC7521] の Section 5.2 全体が適用される。加えて、以下の processing rules が適用される。

• JWT typ が oauth-id-jag+jwt であることを検証する（[RFC8725] の Section 3.11 に従う）。
• aud claim は、JWT の intended audience として Resource Authorization Server の Issuer URL を特定しなければならない。
• client_id claim は、リクエストの Client 認証と同一の Client を特定しなければならない。
• Resource Authorization Server は、scope claim の処理において [RFC6749] の Section 3.3 に従わなければならない。

4.4.2. Response

Resource Authorization Server の token endpoint は、OAuth 2.0 Token Response を返す。例:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "token_type": "Bearer",
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "expires_in": 86400,
  "scope": "chat.read chat.history"
}

4.4.3. Refresh Token

Resource Authorization Server は、Identity Assertion JWT Authorization を Access Token と交換する際に Refresh Token を返すべきではない（[I-D.ietf-oauth-identity-chaining] の Section 5.2 に従う）。

access token の有効期限が切れた場合、Client は元の Identity Assertion JWT Authorization Grant を再提出して、新しい Access Token を取得するのが望ましい。ID-JAG は、Resource Authorization Server に対する Refresh Token の使用を置き換える。

ID-JAG の有効期限が切れている場合、Client は、IdP から取得した元の Identity Assertion（例：ID Token）を用いて、Resource Authorization Sever に提示する前に IdP Authorization Server へ新しい ID-JAG を要求するのが望ましい。

ID Token の有効期限が切れている場合、Client は、SSO 中に IdP から取得した Refresh Token を用いて新しい ID Token を取得し、それを新しい ID-JAG と交換してもよい。Client が Refresh Token により新しい Identity Assertion を取得できない場合、IdP へリダイレクトしてユーザーを再認証するのが望ましい。

5. Cross-Domain Client ID Handling

このフローには、3 つの独立した OAuth/OpenID Connect/SAML 関係が関与する。

• Client と IdP Authorization Server（OpenID Connect または SAML）
• Client と Resource Authorization Server（OAuth）
• Resource Authorization Server と IdP Authorization Server（OpenID Connect または SAML）

各関係は通常、各当事者間の独立した Client 登録によって表現される。例えば、IdP Authorization Server は通常、Client と Resource Authorization Server の双方に対して、Relying Party として OpenID Connect でシングルサインオンを行うための Client ID を発行する。同様に、Resource Authorization Server は通常、Resource Server への API アクセスのために Client が使用する Client ID を発行する。Client は各登録で異なる client credentials を使用してもよい。

このフローでは、IdP Authorization Server は Client からの Token Exchange request を受け付け、Resource Authorization Server により消費される ID-JAG を発行する。これは、IdP Authorization Server が、Resource Authorization Server によって認識される client_id claim を ID-JAG に含められるように、Client と Resource Authorization Server 間の関係を把握しておく必要があることを意味する。

これは、Clients と Resource Authorization Servers の間で使用される各 client_id の記録を IdP Authorization Server が保持することで処理できる。その情報は、帯域外の仕組みで取得する必要がある。Client は、対応付けられた client_id のために ID-JAG を提示する際も、Resource Authorization Server に登録された credential を用いて認証する必要がある。confidential client を要求することは、IdP Authorization Server が Resource Authorization Server 向けの有効な clients のいずれに対してもアクセスを委任してしまうことを防ぐ助けとなる。

注: IdP Authorization Server は、ID-JAG 内で Clients および信頼ドメイン間の subject identifiers を対応付ける責務も負う。同一ユーザーが、Client への SSO のために ID Token で発行された pair-wise subject identifier と、Resource Authorization Server への SSO（Relying Party として）で発行された別の subject identifier を持つ場合がある。Resource Authorization Server は、SSO と API access の両方に対して、アカウント解決のために一貫した subject identifiers を必要とする。IdP Authorization Server は、ID-JAG に発行される subject identifier が、Resource Authorization Server 向けに意図した ID Token に含めていたであろうユーザー識別子と同一であることを保証する必要がある。

代替として、Client が client identifiers として "Client ID Metadata Document" [I-D.ietf-oauth-client-id-metadata-document] を使用する場合、これは Client IDs の共有グローバル名前空間として機能し、IdP Authorization Server が各 client registration の対応付けを保持する必要をなくす。

6. Authorization Server (IdP) Metadata

IdP は、OAuth Authorization Server Metadata [RFC8414] において、本プロファイルのサポートを宣言できる。Identity and Authorization Chaining Across Domains [I-D.ietf-oauth-identity-chaining] は、この目的のために新しい metadata property identity_chaining_requested_token_types_supported を定義している。

Identity Assertion JWT Authorization Grant のサポートを宣言するため、authorization server は identity_chaining_requested_token_types_supported property に次の値を含めるのが望ましい。

• urn:ietf:params:oauth:token-type:id-jag

7. Security Considerations

7.1. Client Authentication

本仕様は、confidential clients に対してのみサポートするのが望ましい。Public clients は、既存の authorization code grant を使用し、ユーザーがアクセス委任に対して対話的に同意できる OAuth 2.0 Authorization Request とともにユーザーを Resource Authorization Server へリダイレクトすべきである。

7.2. Step-Up Authentication

初期の token exchange request において、IdP は、subject の assertion に含まれる認証コンテキストがポリシー要件を満たさない場合、subject に対して step-up authentication を要求してもよい。クライアントへ認証要件を伝えるため、OAuth 2.0 Step-up Authentication Challenge Protocol [RFC9470] と同様に、insufficient_user_authentication の OAuth error response を返してもよい。

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

{
  "error": "insufficient_user_authentication",
  "error_description": "Subject doesn't meet authentication requirements",
  "max_age": 5
}

Client は、要件を満たす新しい assertion を取得するためにユーザーを IdP へリダイレクトし、token exchange を再試行する必要がある。

TBD: step-up を行う際、OpenID Connect を SSO に使用しているなら、追加の token exchange の往復を省くために、認可リクエスト内で Identity Assertion JWT Authorization Grant を要求する方が理にかなっている可能性がある。

7.3. Cross-Domain Use

本仕様は、Client、Resource App、Identity Provider がすべて異なる信頼ドメインにあるクロスドメイン用途を意図している。特に、Identity Provider は、自身が発行した ID-JAG に応答して access tokens を発行してはならない。そうすると、意図せず authorization の scope が拡大するおそれがある。

8. IANA Considerations

8.1. Media Types

本セクションは、oauth-id-jag+jwt を、新しい media type [RFC2046] として "Media Types" registry [IANA.media-types] に、[RFC6838] に記載の手順で登録する。これは、content が Identity Assertion JWT Authorization Grant であることを示すために使用できる。

8.2. OAuth URI Registration

本セクションは、urn:ietf:params:oauth:token-type:id-jag を、"OAuth Parameters" registry [IANA.oauth-parameters] の "OAuth URI" subregistry に登録する。

• URN: urn:ietf:params:oauth:token-type:id-jag
• Common Name: Identity Assertion JWT Authorization Grant のための Token type URI
• Change Controller: IETF
• Specification Document: This document

8.3. JSON Web Token Claims Registration

本セクションは、resource を "JSON Web Token Claims" subregistry（"JSON Web Token (JWT)" registry [IANA.jwt]）に登録する。"JSON Web Token Claims" subregistry は [RFC7519] により設立された。

• Claim Name: resource
• Claim Description: Resource
• Change Controller: IETF
• Specification Document(s): Section 3

9. References

9.1. Normative References

[I-D.ietf-oauth-identity-chaining]
              Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins,
              M. J., and B. Campbell, "OAuth Identity and Authorization
              Chaining Across Domains", Work in Progress, Internet-
              Draft, draft-ietf-oauth-identity-chaining-06, 12 September
              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
              oauth-identity-chaining-06>.

[IANA.jwt] IANA, "JSON Web Token (JWT)",
              <https://www.iana.org/assignments/jwt>.

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

[IANA.oauth-parameters]
              IANA, "OAuth Parameters",
              <https://www.iana.org/assignments/oauth-parameters>.

[OpenID.Core]
              Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
              C. Mortimore, "OpenID Connect Core 1.0 incorporating
              errata set 2", December 2023,
              <https://openid.net/specs/openid-connect-core-1_0.html>.

[OpenID.Enterprise]
              Hardt, D. and K. McGuinness, "OpenID Connect Enterprise
              Extensions 1.0 - draft 01", September 2025,
              <https://openid.net/specs/openid-connect-enterprise-
              extensions-1_0.html>.

[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>.

[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>.

[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>.

[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>.

[RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC7521]  Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
              "Assertion Framework for OAuth 2.0 Client Authentication
              and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521,
              May 2015, <https://www.rfc-editor.org/rfc/rfc7521>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

9.2. Informative References

[I-D.ietf-oauth-client-id-metadata-document]
              Parecki, A. and E. Smith, "OAuth Client ID Metadata
              Document", Work in Progress, Internet-Draft, draft-ietf-
              oauth-client-id-metadata-document-00, 8 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
              client-id-metadata-document-00>.

[RFC9470]  Bertocci, V. and B. Campbell, "OAuth 2.0 Step Up
              Authentication Challenge Protocol", RFC 9470,
              DOI 10.17487/RFC9470, September 2023,
              <https://www.rfc-editor.org/rfc/rfc9470>.

[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>.

Appendix A. Use Cases

A.1. Enterprise Deployment

企業ではしばしば数百の SaaS applications を利用している。SaaS applications には、アプリケーション体験や達成すべき仕事（jobs to be done）にとって重要な、他の SaaS applications との連携があることが多い。SaaS app が、ユーザーの代理としてサードパーティ SaaS integration の API に対する Access Token を要求する必要がある場合、End-User は通常、対話的な委任 OAuth 2.0 フローを完了しなければならない。これは SaaS application がサードパーティ SaaS integration と同一のセキュリティ／ポリシードメインにないためである。

エンタープライズが、自社の SaaS applications のエコシステムを Identity Provider（IdP）に接続し、組織の identity と access management を集約することは業界のベストプラクティスである。End-Users はより良い体験（SSO）を得られ、管理者は多要素認証やゼロトラストなど、より良いセキュリティ成果を得られる。現在の SaaS applications は、管理者がユーザー認証のために IdP との信頼関係を確立できるようにしている。

本仕様は、複数の SaaS applications の SSO 関係を拡張し、それらのアプリケーション間の API access も含められるようにするために使用できる。本仕様は、ポリシーまたは管理上の境界をまたいだ Authorization Servers の federation を可能にする。SSO のためにアプリケーションから信頼されている同一のエンタープライズ IdP を、API へのアクセス仲介へ拡張できる。これにより、エンタープライズは SaaS エコシステム全体でより多くのアクセス判断を集約でき、OAuth 2.0 で複数アプリケーションを接続する必要があるユーザーに対して、より良い End-User 体験を提供できる。

A.1.1. Preconditions

• Client は、IdP Authorization Server に登録済みの OAuth 2.0 Client を持つ。
• Client は、Resource Authorization Server に登録済みの OAuth 2.0 Client を持つ。
• Enterprise は、SSO および Identity Assertion JWT Authorization Grant のために、IdP と Client の間の信頼関係を確立している。
• Enterprise は、SSO および Identity Assertion JWT Authorization Grant のために、IdP と Resource Authorization Server の間の信頼関係を確立している。
• Enterprise は、Resource Authorization Server に対して、特定の scopes の集合について、users の代理として動作する権限を Client に付与している。

A.2. Email and Calendaring Applications

Email clients は任意の email servers とともに使用でき、各 email client と各 email server の間で事前に関係を確立しておくことを要求できない。email client が OAuth を使用して email server のための Access Token を取得する場合、email server の Authorization Server が提供する強力な多要素認証方式を利用できるというセキュリティ上の利点がある一方、ユーザーが web ベースのフローを通って email client にログインする必要がある。しかし、この web ベースのフローは、デスクトップやモバイルの Native App から開始される場合、ユーザー体験を阻害すると見なされることが多く、そのため可能な限り最小化しようとされることが多い。

email client が、サードパーティの calendaring application のような別の API へアクセスする必要がある場合、伝統的には、email client は別の web ベースの OAuth redirect フローを通って、認可を取得し、最終的に Access Token を得る必要がある。

ユーザー体験を簡素化するため、本仕様を用いることで、ユーザーの操作なしに、email client が identity assertion を使用してサードパーティ calendaring application 向けの Access Token を取得できるようにできる。

A.2.1. Preconditions

• Client は、IdP Authorization Server または Resource Authorization Server において、事前登録された OAuth 2.0 client を持たない。
• Client は、IdP Authorization Server から Identity Assertion（例：ID Token）を取得している。
• Resource Authorization Server は、未登録 clients からの Identity Assertion JWT Authorization Grant を許可するよう設定されている。

A.3. LLM Agent using Enterprise Tools

大規模言語モデル（LLM）に基づくものを含む AI agents は、複数ターンの会話にわたって user context、memory、interaction state を管理するよう設計されている。複雑なタスクを実行するため、これらの agents はしばしば SaaS applications、internal services、enterprise data sources などの外部システムと統合される。これらのシステムへアクセスする際、agent は End-User の代理として動作し、その actions は、enterprise により定義されるユーザーの identity、role、permissions によって制約される。これにより、すべての data access と operations が、適切にスコープされ、組織の access controls に準拠することが保証される。

A.3.1. Preconditions

• LLM Agent は、Enterprise IdP（cyberdyne.idp.example）に登録済みの OAuth 2.0 Client（com.example.ai-agent）を持つ。
• LLM Agent は、External Tool Application（saas.example.net）に登録済みの OAuth 2.0 Client（4960880b83dc9）を持つ。
• Enterprise は、SSO のために IdP と LLM Agent の間の信頼関係を確立している。
• Enterprise は、SSO および Identity Assertion JWT Authorization Grant のために、IdP と External Tool Application の間の信頼関係を確立している。
• Enterprise は、特定の scopes の集合について、External Tool Application に対して users の代理として動作する権限を LLM Agent に付与している。

A.3.2. Example Sequence

以下の手順は、LLM agent が Identity Assertion JWT Authorization Grant（Section 3）を使用して Access Token を取得するまでの流れを説明する。

A.3.2.1. LLM Agent establishes a User Identity with Enterprise IdP

LLM Agent は、以前に確立された configured issuer に基づいて、Enterprise IdP の OpenID Connect Provider 設定を検出する。

注: agent が特定ユーザーの認証に使用すべき IdP を検出する IdP discovery は、本仕様の対象外である。

GET /.well-known/openid-configuration
Host: cyberdyne.idp.example
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{
  "issuer": "https://cyberdyne.idp.example/",
  "authorization_endpoint": "https://cyberdyne.idp.example/oauth2/authorize",
  "token_endpoint": "https://cyberdyne.idp.example/oauth2/token",
  "userinfo_endpoint": "https://cyberdyne.idp.example/oauth2/userinfo",
  "jwks_uri": "https://cyberdyne.idp.example/oauth2/keys",
  "registration_endpoint": "https://cyberdyne.idp.example/oauth2/register",
  "scopes_supported": [
    "openid", "email", "profile"
  ],
  "response_types_supported": [
    "code"
  ],
  "grant_types_supported": [
    "authorization_code",
    "refresh_token",
    "urn:ietf:params:oauth:grant-type:token-exchange"
  ],
  "identity_chaining_requested_token_types_supported": [
    "urn:ietf:params:oauth:token-type:id-jag"
  ],
  ...
}

LLM Agent は、認証に必要なすべての endpoints と、Identity Chaining requested token type urn:ietf:params:oauth:token-type:id-jag のサポートを把握した。

A.3.2.2. IdP Authorization Request (with PKCE)

LLM Agent は PKCE の code_verifier と code_challenge（通常は verifier の SHA256 ハッシュを base64url エンコードしたもの）を生成し、authorization request とともに End-User を Enterprise IdP にリダイレクトする。

GET /authorize?
  response_type=code
  &client_id=com.example.ai-agent
  &redirect_uri=https://ai-agent.example.com/oauth2/callback
  &scope=openid+profile+email
  &state=xyzABC123
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256
Host: cyberdyne.idp.example

A.3.2.3. User authenticates and authorizes LLM Agent

Enterprise IdP は End-User を認証し、LLM Agent の登録済み client redirect URI へ、authorization code を付けてリダイレクトする。

https://ai-agent.example.com/oauth2/callback?code=SplxlOBeZQQYbYS6WxSbIA&state=xyzABC123

LLM Agent は、code と PKCE code_verifier を交換して、IdP の UserInfo endpoint 向けの ID Token と Access Token を取得する。

POST /oauth2/token
Host: cyberdyne.idp.example
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https://ai-agent.example.com/oauth2/callback
&client_id=com.example.ai-agent
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id_token": "eyJraWQiOiJzMTZ0cVNtODhwREo4VGZCXzdrSEtQ...",
  "token_type": "Bearer",
  "access_token": "7SliwCQP1brGdjBtsaMnXo",
  "scope": "openid profile email"
}

LLM Agent は、IdP が公開する JWKS を用いて ID Token を検証する。

{
  "iss": "https://cyberdyne.idp.example/",
  "sub": "1997e829-2029-41d4-a716-446655440000",
  "aud": "com.example.ai-agent",
  "exp": 1984444800,
  "iat": 1684441200,
  "auth_time": 1684440000,
  "name": "John Connor",
  "email": "john.connor@cyberdyne.example",
  "email_verified": true
}

LLM Agent は、context のための identity binding を得た。

A.3.2.4. LLM Agent calls Enterprise External Tool

LLM Agent は、有効な Access Token なしに Enterprise SaaS Application（Resource Server）が提供する external tool を呼び出し、Protected Resource Metadata [RFC9728] に従って認証チャレンジを受け取る。

注: agents が利用可能な tools を検出する方法は、本仕様の対象外である。

GET /tools
Host: saas.example.net
Accept: application/json

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata=
  "https://saas.example.net/.well-known/oauth-protected-resource"

LLM Agent は、[RFC9728] に従って external tool resource の OAuth 2.0 Protected Resource Metadata を取得し、リソース向けの Access Token を発行できる authorization server を動的に検出する。

GET /.well-known/oauth-protected-resource
Host: saas.example.net
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{
  "resource": "https://saas.example.net/",
  "authorization_servers": [
    "https://authorization-server.saas.com/"
  ],
  "bearer_methods_supported": [
    "header",
    "body"
  ],
  "scopes_supported": [
    "agent.tools.read",
    "agent.tools.write"
  ],
  "resource_documentation": "https://saas.example.net/tools/resource_documentation.html"
}

LLM Agent は、[RFC8414] に従って Authorization Server 設定を検出する。

GET /.well-known/oauth-authorization-server
Host: authorization-server.saas.com
Accept: application/json

HTTP/1.1 200 Ok
Content-Type: application/json

{
  "issuer": "https://authorization-server.saas.com/",
  "authorization_endpoint": "https://authorization-server.saas.com/oauth2/authorize",
  "token_endpoint": "https://authorization-server.saas.com/oauth2/token",
  "jwks_uri": "https://authorization-server.saas.com/oauth2/keys",
  "registration_endpoint": "authorization-server.saas.com/oauth2/register",
  "scopes_supported": [
    "agent.read",
    "agent.write"
  ],
  "response_types_supported": [
    "code"
  ],
  "grant_types_supported": [
    "authorization_code",
    "refresh_token",
    "urn:ietf:params:oauth:grant-type:jwt-bearer"
  ],
  ...
}

LLM Agent は、external tool のための Access Token を取得するのに必要なすべての endpoints と、サポートされる capabilities を把握した。

urn:ietf:params:oauth:grant-type:jwt-bearer の grant type がサポートされている場合、LLM はまず、Enterprise の IdP から得た Identity Assertion JWT Authorization Grant により、対話なしで Access Token の取得を試みられる。それ以外の場合は、SaaS Application の Authorization Server から標準の authorization_code を対話的に取得する方法へフォールバックできる。

注: この場合、Authorization Server Metadata [RFC8414] に、Identity Assertion JWT Authorization Grant 形態の jwt-bearer を当該 authorization server が受け付けるかどうかを示す property があると有益である。authorization server は、他の用途の jwt-bearer もサポートしている可能性があり、Identity Assertion JWT Authorization Grant がサポートされていることの信頼できる指標とは必ずしもならない。Issue #16 を参照（https://github.com/aaronpk/draft-parecki-oauth-identity- assertion-authz-grant/issues/16）。

A.3.2.5. LLM Agent obtains an Identity Assertion JWT Authorization Grant for Enterprise External Tool from the Enterprise IdP

LLM Agent は、ユーザーの Enterprise IdP に対し、external tool の resource 向けの Identity Assertion JWT Authorization Grant Token Exchange [RFC8693] request を送る。この際、LLM Agent が identity binding context を確立したときに得た ID Token に加え、external tool の OAuth 2.0 Protected Resource Metadata で返された scopes と resource identifier を使用する。

POST /oauth2/token HTTP/1.1
Host: cyberdyne.idp.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=urn:ietf:params:oauth:token-type:id-jag
&audience=https://authorization-server.saas.com/
&resource=https://saas.example.net/
&scope=agent.read+agent.write
&subject_token=eyJraWQiOiJzMTZ0cVNtODhwREo4VGZCXzdrSEtQ...
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6IjIyIn0...

アクセスが付与される場合、Enterprise IdP は署名済みの Identity Assertion JWT Authorization Grant を生成し、[RFC8693] の Section 2.2 で定義される token exchange response で返す。

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

{
  "issued_token_type": "urn:ietf:params:oauth:token-type:id-jag",
  "access_token": "eyJhbGciOiJIUzI1NiIsI...",
  "token_type": "N_A",
  "scope": "agent.read agent.write",
  "expires_in": 300
}

Identity Assertion JWT Authorization Grant claims:

{
  "alg": "ES256",
  "typ": "oauth-id-jag+jwt"
}

{
  "jti": "9e43f81b64a33f20116179",
  "iss": "https://cyberdyne.idp.example",
  "sub": "1llb-b4c0-0000-8000-t800b4ck0000",
  "aud": "https://authorization-server.saas.com",
  "resource": "https://saas.example.net/",
  "client_id": "4960880b83dc9",
  "exp": 1984445160,
  "iat": 1984445100,
  "scope": "agent.read agent.write"
}

signature

A.3.2.6. LLM Agent obtains an Access Token for Enterprise External Tool

LLM Agent は、Enterprise IdP から取得した Identity Assertion JWT Authorization Grant を、[RFC7523] に定義される JWT Assertion として使用し、事前に検出した external tool の Authorization Server token endpoint へ token request を送る。

LLM Agent は、SaaS Authorization Server に登録された client credentials で認証する。

注: LLM Agent が Authorization Server に登録する方法（例：静的または dynamic client registration）や、credentials を持つかどうかは、本仕様の対象外である。

POST /oauth2/token HTTP/1.1
Host: authorization-server.saas.com
Authorization: Basic yZS1yYW5kb20tc2VjcmV0v3JOkF0XG5Qx2

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=eyJhbGciOiJIUzI1NiIsI...

SaaS Authorization Server は、信頼する Enterprise IdP が公開する JWKS を用いて、Identity Assertion JWT Authorization Grant を検証する。

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "token_type": "Bearer",
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "expires_in": 86400,
  "scope": "agent.read agent.write"
}

A.3.2.7. LLM Agent makes an authorized External Tool request

LLM Agent は、有効な Access Token を付けて、Enterprise SaaS Application（Resource Server）が提供する external tool を呼び出す。

GET /tools
Host: saas.example.net
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA"
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{
  ...
}

Acknowledgments

著者らは、本仕様への貢献およびレビューをしてくれた以下の人々に感謝する:\ Kamron Batmanghelich, Sofia Desenberg, Meghna Dubey, George Fletcher, Bingrong He, Pieter Kasselman, Kai Lehmann, Dean H. Saxe, Filip Skokan, Phil Whipps.

Document History

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

-01

• ID-JAG の定義を、Token Exchange 配下のネストではなく、文書のルートへ移動した。
• 提案された OpenID Connect tenant claim を追加した。
• ID Token 由来の認証 claims を追加した。
• Resource App または Resource App の Authorization Server ではなく、標準の OAuth 2.0 role names を採用した。
• sequence diagram を更新した。
• ID-JAG に関する不整合な参照をすべて「Identity Assertion JWT Authorization Grant」に更新した。
• section 参照を、より具体的なリンクに更新した。
• ID-JAG processing rules に scope parameter への参照を追加した。
• client ID の対応付けに関する議論の section と、Client ID Metadata Document への参照を追加した。
• refresh tokens に関する推奨事項を追加した。

-00

• working group draft として採択された初版

Authors' Addresses

Aaron Parecki
Okta
Email: aaron@parecki.com

Karl McGuinness
Independent
Email: public@karlmcguinness.com

Brian Campbell
Ping Identity
Email: bcampbell@pingidentity.com