Identity Assertion JWT Authorization Grant

2.1. Roles

Client

The application that wants to obtain an OAuth 2.0 access token on behalf of a signed-in user to an external/3rd party application's API (Resource Server below). In [I-D.ietf-oauth-identity-chaining], this is the Client in trust domain A. The application has a direct relationship with the IdP Authorization Server for single sign-on as a Relying Party and another independent OAuth 2.0 client relationship with the Resource Authorization Server in trust domain B.¶

IdP Authorization Server (IdP)

An OpenID Connect Provider (OP) [OpenID.Core] or SAML 2.0 Identity Provider that issues Identity Assertions for single sign-on and cross-domain authorization grants Section 3 for a set of trusted applications in an application ecosystem. In this specification, the IdP is the issuer that the Resource Authorization Server already trusts for SSO and subject resolution for the target user accounts. In [I-D.ietf-oauth-identity-chaining], this is the Authorization Server in trust domain A, which is also trusted by the Resource Authorization Server in trust domain B.¶

Resource Authorization Server (AS)

Issues OAuth 2.0 access tokens for protected resources provided by the Resource Server. In [I-D.ietf-oauth-identity-chaining], this is the Authorization Server in trust domain B, and trusts cross-domain authorization grants Section 3 from the IdP Authorization Server.¶

Resource Server (RS)

Hosts protected resources and validates access tokens issued by the Resource Authorization Server. In [I-D.ietf-oauth-identity-chaining], this is the Protected Resource in trust domain B. The Resource Server has no direct trust relationship with the IdP Authorization Server. Instead, it validates access tokens issued by its trusted Resource Authorization Server to determine who should have access to resources.¶

2.2. Terms

The following terms are used in this document:¶

Common OAuth and token processing terms such as client, authorization server, resource server, resource owner, access token, refresh token, token, grant, assertion, subject_token, subject_token_type, actor_token, and actor_token_type are used as defined in OAuth 2.0 [RFC6749], JSON Web Token (JWT) [RFC7519], JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523], OAuth 2.0 Token Exchange [RFC8693], and OAuth 2.0 Authorization Server Metadata [RFC8414], unless otherwise specified by this document.¶

OpenID Connect terms such as end-user, Relying Party, OpenID Provider, ID Token, subject identifier, and pairwise subject identifier are used as defined in OpenID Connect Core 1.0 [OpenID.Core], unless otherwise specified by this document.¶

Identity Assertion

A security token issued by the IdP Authorization Server that conveys claims about the End-User and can be used as the subject_token input to Token Exchange. In this specification, the Identity Assertion is typically an OpenID Connect ID Token or a SAML 2.0 assertion.¶

Trust Domain

A deployment-specific security and administrative boundary within which a set of entities, identifiers, credentials, and policy decisions are mutually trusted according to established trust relationships. In this specification, the IdP Authorization Server operates in trust domain A, while the Resource Authorization Server and Resource Server operate in trust domain B.¶

Cross-Domain

Involving two or more trust domains where an assertion, grant, or authorization decision produced in one trust domain is relied upon in another. In this specification, the IdP Authorization Server operates in trust domain A, while the Resource Authorization Server and Resource Server operate in trust domain B.¶

Cross-App Access (XAA)

The application-ecosystem name for the pattern this specification profiles, in which an application obtains an access token at another application's API by coordinating through the IdP both applications trust for SSO. XAA is realized over OAuth 2.0 by using an Identity Assertion JWT Authorization Grant (Section 3) as a specific instance of cross-domain identity chaining ([I-D.ietf-oauth-identity-chaining]).¶

Subject Resolution

The process by which the Resource Authorization Server determines which local subject represents the End-User identified by the ID-JAG. Subject resolution can use stable identifiers and other trusted claims in the ID-JAG, such as iss, sub, tenant, aud_sub, email, or deployment-specific claims, and can include JIT provisioning when permitted by policy.¶

JIT provisioning

The process by which the Resource Authorization Server or a relying service creates a new local account or subject record, or updates an existing one, using trusted identity claims presented during the transaction rather than requiring separate pre-provisioning. In this specification, JIT provisioning may occur as part of subject resolution when permitted by policy.¶

Tenant

A deployment-specific administrative, organizational, or customer boundary within an issuer or relying service that scopes subjects, clients, policy, and other identifiers. In single-tenant deployments, the issuer may uniquely identify the tenant context; in multi-tenant deployments, the tenant context may need to be conveyed explicitly, for example by the tenant or aud_tenant claim.¶

3.1. ID-JAG Claims

The following claims are used within the Identity Assertion JWT Authorization Grant:¶

iss:

REQUIRED - The issuer identifier of the IdP Authorization Server as defined in [RFC8414].¶

sub:

REQUIRED - Subject Identifier for the End-User, selected by the IdP Authorization Server for the Resource Authorization Server identified by the aud claim as described in Section 5.2. The sub claim identifies the End-User in the subject namespace of the ID-JAG issuer. A public subject identifier MUST be unique when scoped with issuer (iss+sub) for a single-tenant issuer and MUST be unique when scoped with issuer and tenant (iss+tenant+sub) for multi-tenant issuer.¶

When the Resource Authorization Server uses a different subject namespace for SSO, such as a SAML Assertion Subject <NameID> namespace, the ID-JAG MAY include sub_id to carry the SSO subject identifier. When both sub and sub_id are present, they MUST identify the same End-User.¶

sub_id:

OPTIONAL - Subject Identifier as defined in [RFC9493]. The sub_id claim MAY be used to identify the same End-User as the sub claim using a different identifier namespace from the ID-JAG iss and sub. This is useful when the Resource Authorization Server resolves users by a non-JWT subject identifier, such as a SAML Assertion Subject <NameID>, in its SSO trust relationship with the IdP Authorization Server. See Section 3.2.1 for the SAML NameID Subject Identifier Format defined by this specification, and Section 3.2.2 for processing rules.¶

aud:

REQUIRED - The issuer identifier of the Resource Authorization Server as defined in [RFC8414].¶

client_id:

REQUIRED - The client identifier of the OAuth 2.0 [RFC6749] client at the Resource Authorization Server that will act on behalf of the resource owner (sub). This identifier MAY be different from the client identifier of the OAuth 2.0 client requesting an ID-JAG from the IdP Section 4.3 of [RFC8693], as it represents an independent client relationship with another Authorization Server in a different trust domain. See Section 5.1 for additional considerations.¶

jti:

REQUIRED - Unique ID of this JWT as defined in Section 4.1.7 of [RFC7519].¶

exp:

REQUIRED - as defined in Section 4.1.4 of [RFC7519].¶

iat:

REQUIRED - as defined in Section 4.1.6 of [RFC7519].¶

resource:

OPTIONAL - Identifies the protected resource(s) for which access is granted, using resource identifiers as defined in Section 2 of [RFC8707]. The value is a string for a single resource, or a non-empty JSON array of unique strings for multiple resources. Resource identifiers are compared as described in Section 4.3.¶

scope:

OPTIONAL - a JSON string containing a space-separated list of scopes associated with the token, in the format described in Section 3.3 of [RFC6749].¶

authorization_details:

OPTIONAL - A JSON array of authorization detail objects as defined in Section 2 of [RFC9396]. This claim enables Rich Authorization Requests (RAR) support, allowing structured authorization requests beyond simple scope strings.¶

act:

OPTIONAL - Actor claim as defined in Section 4.1 of [RFC8693]. When present, this claim identifies the actor that is acting on behalf of the subject (sub).¶

tenant:

OPTIONAL - JSON string that represents the tenant identifier for a multi-tenant issuer as defined in [OpenID.Enterprise]¶

auth_time:

OPTIONAL - Time when End-User authenticated as defined in [OpenID.Core].¶

acr:

OPTIONAL - Authentication Context Class Reference that was satisfied when authenticating the End-User as defined in [OpenID.Core].¶

amr:

OPTIONAL - Identifiers for authentication methods used when authenticating the End-User as defined in [OpenID.Core].¶

aud_tenant:

OPTIONAL - A JSON string that represents a Resource Authorization Server tenant identifier. This claim is only included when the Resource Authorization Server is multi-tenant and the IdP knows the tenant identifier. When aud_tenant is present, the aud_sub claim represents the identifier the Resource Authorization Server has for the account within the context of that specific Resource Authorization Server tenant. The combination of aud + aud_tenant and aud_sub MUST be unique within the Resource Authorization Server.¶

aud_sub:

OPTIONAL - The Resource Authorization Server's identifier for the End-User as defined in [OpenID.Enterprise].¶

email:

OPTIONAL - End-User's e-mail address as defined in Section 5.1 of [OpenID.Core].¶

The typ of the JWT indicated in the JWT header MUST be oauth-id-jag+jwt. Using typed JWTs is a recommendation of the JSON Web Token Best Current Practices as described in Section 3.11 of [RFC8725].¶

A non-normative example JWT with expanded header and payload claims is below:¶

{
  "typ": "oauth-id-jag+jwt"
}
.
{
  "jti": "9e43f81b64a33f20116179",
  "iss": "https://acme.idp.example/",
  "sub": "U019488227",
  "aud": "https://acme.chat.example/",
  "client_id": "f53f191f9311af35",
  "exp": 1311281270,
  "iat": 1311280970,
  "resource": "https://acme.chat.example/api",
  "scope": "chat.read chat.history",
  "auth_time": 1311280970,
  "amr": [
    "mfa",
    "phrh",
    "hwk",
    "user"
  ]
}
.
signature

The ID-JAG conveys claims about three subjects: the End-User identified by sub (including identity, authentication context, and audience-scoped authorization context such as roles or entitlements at the target application), the OAuth 2.0 client identified by client_id that will act on behalf of the End-User at the Resource Authorization Server, and, when present, the actor identified by act (Section 4.1 of [RFC8693]). The IdP Authorization Server populates these claims for the specific Resource Authorization Server identified by aud, in the same way it would populate audience-scoped claims into an ID Token or SAML Assertion issued to that Resource Authorization Server. Any claim that would be valid in an ID Token [OpenID.Core] may appear in the ID-JAG, since the grant conveys identity claims about the End-User as well as an authorization delegation for the Resource Authorization Server.¶

It is RECOMMENDED that the ID-JAG contain an email [OpenID.Core] and/or aud_sub [OpenID.Enterprise] claim. The Resource Authorization Server MAY use these claims for subject resolution, including JIT provisioning, for example when the user has not yet SSO'd into the Resource Authorization Server. Additional Resource Authorization Server specific identity claims MAY be needed for subject resolution.¶

3.2. SAML NameID Subject Identifier

"sub_id": {
  "format": "saml-nameid",
  "issuer": "https://idp.example.com/exk33qwjcwDda7luK346",
  "nameid": "foo@example.com",
  "nameid_format": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
  "sp_name_qualifier": "https://resource.example.com/saml/sp"
}

4.1. Overview

The example flow is for an enterprise acme, which uses a multi-tenant wiki app and chat app from different vendors, both of which are integrated into the enterprise's multi-tenant Identity Provider using OpenID Connect. Enterprise is a common deployment shape for this profile, but it is not the only one. The same pattern applies anywhere the Resource Authorization Server already trusts the issuing IdP for SSO and subject resolution.¶

Sequence Diagram¶

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

1. User authenticates with the IdP Authorization Server, the Client obtains an Identity Assertion (e.g. OpenID Connect ID Token or SAML 2.0 Assertion) for the user and optionally a Refresh Token (when using OpenID Connect) and signs the user in¶

2. Client uses the Identity Assertion or a previously issued Refresh Token from the IdP to request an Identity Assertion JWT Authorization Grant for the Resource Authorization Server from the IdP Authorization Server¶

3. Client exchanges the Identity Assertion JWT Authorization Grant for an Access Token at the Resource Authorization Server's token endpoint¶

4. Client makes an API request to the Resource Server with the Access Token¶

This specification is constrained to deployments where the Client has a Relying Party relationship with the IdP Authorization Server for SSO, and the Resource Authorization Server independently trusts that same IdP Authorization Server for SSO and subject resolution for the user represented in the ID-JAG. The IdP Authorization Server provides the trusted identity context that allows the Resource Authorization Server to evaluate the ID-JAG. The Resource Authorization Server not only delegates user authentication to that IdP, but also relies on the IdP-issued grant as input to delegated authorization for the scopes, resources, and authorization details conveyed in the ID-JAG. The Resource Authorization Server does not need to obtain user consent directly from the resource owner again at the token exchange step. The Resource Authorization Server still applies local policy to decide whether to honor the grant, whether to narrow or reject the requested access, and what access token to issue. A deployment MAY trust more than one IdP Authorization Server for this purpose, but for each trusted issuer the Resource Authorization Server MUST be configured to recognize that issuer, resolve identities asserted by that issuer to the appropriate local account or principal, and associate the ID-JAG with the correct client relationship.¶

4.2. User Authentication

The Client initiates an authentication request with the IdP Authorization Server using OpenID Connect or SAML.¶

The following is an example using OpenID Connect¶

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

The user authenticates with the IdP, and is redirected back to the Client with an authorization code, which it can then exchange for an ID Token and optionally a Refresh Token when offline_access scope is requested per [OpenID.Core].¶

Note: The IdP Authorization Server may enforce security controls such as multi-factor authentication before granting the user access to the Client.¶

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
Cache-Control: no-store

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

4.3. Token Exchange

The Client makes a Token Exchange [RFC8693] request to the IdP Authorization Server's Token Endpoint with the following parameters:¶

requested_token_type:

REQUIRED - The value urn:ietf:params:oauth:token-type:id-jag indicates that an Identity Assertion JWT Authorization Grant is being requested.¶

audience:

REQUIRED - The identifier of the Resource Authorization Server, typically in another trust domain, as the intended audience for the ID-JAG. Exactly one audience value is allowed.¶

IdP Authorization Servers MUST support the issuer identifier of the Resource Authorization Server as defined in Section 2 of [RFC8414]. IdP Authorization Servers MAY also support implementation-specific audience values, such as URNs, that identify pre-established trust relationships with Resource Authorization Servers. When such a value is used, the IdP Authorization Server resolves it to the corresponding Resource Authorization Server identifier and issues the ID-JAG with that identifier in the aud claim.¶

resource:

RECOMMENDED - The Resource Identifier(s) of the protected resource(s), governed by the Resource Authorization Server identified by audience, for which access is requested, as defined in Section 2 of [RFC8707]. Resource identifiers are compared using Simple String Comparison (Section 6.2.1 of [RFC3986]). A Client that discovered the Resource Authorization Server using Protected Resource Metadata [RFC9728] MUST include the resource value from that metadata unchanged (Section 9.6).¶

scope:

OPTIONAL - The space-separated list of scopes at the Resource Server that is being requested. As in Section 2.1 of [RFC8693], these values have the meaning defined by the Resource Authorization Server where the ID-JAG will be used, not their OpenID Connect meaning, so a value such as profile or email does not request identity claims (Section 5.4 of [OpenID.Core]).¶

authorization_details:

OPTIONAL - A JSON string containing a JSON array of authorization detail objects as defined in Section 2 of [RFC9396]. This parameter enables Rich Authorization Requests (RAR) support, allowing structured authorization requests beyond simple scope strings.¶

subject_token:

REQUIRED - Either the Identity Assertion (e.g. the OpenID Connect ID Token or SAML 2.0 Assertion) for the target resource owner, or a Refresh Token previously issued by the IdP Authorization Server for that resource owner. Implementations of this specification MUST accept Identity Assertions. They MAY additionally accept Refresh Tokens to allow the client to obtain a new ID-JAG without performing a new single sign-on round trip when the Identity Assertion has expired.¶

subject_token_type:

REQUIRED - An identifier, as described in Section 3 of [RFC8693], that indicates the type of the security token in the subject_token parameter. For an OpenID Connect ID Token: urn:ietf:params:oauth:token-type:id_token, for a SAML 2.0 Assertion: urn:ietf:params:oauth:token-type:saml2, and for a Refresh Token (when supported): urn:ietf:params:oauth:token-type:refresh_token.¶

When a Refresh Token is used as the subject token, the client still requests requested_token_type=urn:ietf:params:oauth:token-type:id-jag; this allows the client to refresh an Identity Assertion JWT Authorization Grant without fetching a new Identity Assertion from the user-facing SSO flow.¶

actor_token:

OPTIONAL - A security token that identifies the actor, as described in Section 2.1 of [RFC8693].¶

actor_token_type:

REQUIRED when actor_token is present, as described in Section 2.1 of [RFC8693] - An identifier, as described in Section 3 of [RFC8693], that indicates the type of the security token in the actor_token parameter.¶

This specification does not define normative processing requirements for actor_token or whether an act claim is included in the issued ID-JAG. Future profiles or extensions MAY define how actor_token is validated, how it influences policy evaluation, and whether it results in an act claim in the issued ID-JAG.¶

This specification profiles the audience and resource parameters of OAuth 2.0 Token Exchange [RFC8693] for interoperable use with ID-JAG. In this profile, audience identifies the Resource Authorization Server to which the ID-JAG is issued, and resource identifies the protected resource for which access is requested. This profile uses audience for the Resource Authorization Server rather than defining a new parameter. The ID-JAG is issued by the IdP Authorization Server for processing by the Resource Authorization Server, and the Resource Authorization Server validates the aud claim to determine whether the ID-JAG was issued for it. The resource parameter continues to identify the protected resource, as defined in [RFC8707]. This convention provides a single interoperable interpretation of audience and resource, including deployments in which one Resource Authorization Server governs multiple protected resources or tenant-specific resources.¶

For example, if a SaaS provider operates a Resource Authorization Server at https://authorization-server.saas-tool.example/ and protected resources at https://api.saas-tool.example/files and https://api.saas-tool.example/messages, a client requesting access to the Files API uses:¶

audience=https://authorization-server.saas-tool.example/
resource=https://api.saas-tool.example/files

If a Resource Authorization Server at https://login.saas-tool.example/ governs tenant-specific resources such as https://api.saas-tool.example/acme/ and https://api.saas-tool.example/fabrikam/, the audience value remains the Resource Authorization Server identifier and the resource value distinguishes the protected resource. For example:¶

audience=https://login.saas-tool.example/
resource=https://api.saas-tool.example/acme/

and:¶

audience=https://login.saas-tool.example/
resource=https://api.saas-tool.example/fabrikam/

If the IdP Authorization Server supports an implementation-specific audience value such as urn:example:idp:saas-tool for that same Resource Authorization Server, the client MAY send:¶

audience=urn:example:idp:saas-tool
resource=https://api.saas-tool.example/files

In that case, the IdP Authorization Server resolves the requested audience value to https://authorization-server.saas-tool.example/ and issues the ID-JAG with aud set to https://authorization-server.saas-tool.example/.¶

Client authentication to the Resource Authorization Server is done using the standard mechanisms provided by OAuth 2.0. Section 2.3.1 of [RFC6749] defines password-based authentication of the client (client_id and client_secret), however, client authentication is extensible and other mechanisms are possible. For example, [RFC7523] defines client authentication using bearer JSON Web Tokens using client_assertion and client_assertion_type.¶

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

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=tGzv3JOkF0XG5Qx2TlKWIA
&subject_token_type=urn:ietf:params:oauth:token-type:refresh_token
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6IjIyIn0...

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": "eyJhbGciOiJSUzI1NiIsI...",
  "token_type": "N_A",
  "scope": "chat.read chat.history",
  "expires_in": 300
}

{
  "typ": "oauth-id-jag+jwt"
}
.
{
  "jti": "9e43f81b64a33f20116179",
  "iss": "https://acme.idp.example/",
  "sub": "U019488227",
  "aud": "https://acme.chat.example/",
  "client_id": "f53f191f9311af35",
  "exp": 1311281270,
  "iat": 1311280970,
  "resource": "https://api.chat.example/",
  "scope": "chat.read chat.history",
  "auth_time": 1311280970,
  "amr": [
    "mfa",
    "phrh",
    "hwk",
    "user"
  ]
}
.
signature

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/
&authorization_details=[{"type":"chat_read","actions":["read"],"locations":["https://api.chat.example/channels"]},{"type":"chat_history","actions":["read"],"datatypes":["message"]}]
&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...

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": "eyJhbGciOiJSUzI1NiIsI...",
  "token_type": "N_A",
  "authorization_details": [
    {
      "type": "chat_read",
      "actions": ["read"],
      "locations": ["https://api.chat.example/channels"]
    },
    {
      "type": "chat_history",
      "actions": ["read"],
      "datatypes": ["message"]
    }
  ],
  "expires_in": 300
}

{
  "typ": "oauth-id-jag+jwt"
}
.
{
  "jti": "9e43f81b64a33f20116179",
  "iss": "https://acme.idp.example/",
  "sub": "U019488227",
  "aud": "https://acme.chat.example/",
  "client_id": "f53f191f9311af35",
  "exp": 1311281270,
  "iat": 1311280970,
  "authorization_details": [
    {
      "type": "chat_read",
      "actions": ["read"],
      "locations": ["https://api.chat.example/channels"]
    },
    {
      "type": "chat_history",
      "actions": ["read"],
      "datatypes": ["message"]
    }
  ],
  "auth_time": 1311280970
}
.
signature

POST /oauth2/token HTTP/1.1
Host: acme.chat.example
Authorization: Basic yZS1yYW5kb20tc2VjcmV0v3JOkF0XG5Qx2
Content-Type: application/x-www-form-urlencoded

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

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,
  "authorization_details": [
    {
      "type": "chat_read",
      "actions": ["read"],
      "locations": ["https://api.chat.example/channels"]
    },
    {
      "type": "chat_history",
      "actions": ["read"],
      "datatypes": ["message"]
    }
  ]
}

4.4. Access Token Request

The Client makes an access token request to the Resource Authorization Server's token endpoint using the previously obtained Identity Assertion JWT Authorization Grant as a JWT Bearer Assertion as defined by [RFC7523].¶

grant_type:

REQUIRED - urn:ietf:params:oauth:grant-type:jwt-bearer, or urn:ietf:params:oauth:grant-type:jwt-dpop ([I-D.parecki-oauth-jwt-dpop-grant]) when the ID-JAG is bound to a DPoP key (Section 9.11.1).¶

assertion:

REQUIRED - The Identity Assertion JWT Authorization Grant obtained in the previous token exchange step¶

The Client authenticates with its credentials as registered with the Resource Authorization Server. The Resource Authorization Server SHOULD require client authentication. It MUST reject a request that has neither client authentication nor a sender-constrained ID-JAG (Section 9.11) with invalid_client (Section 5.2 of [RFC6749]). See Section 9.1 for the trade-off.¶

For example:¶

POST /oauth2/token HTTP/1.1
Host: acme.chat.example
Authorization: Basic yZS1yYW5kb20tc2VjcmV0v3JOkF0XG5Qx2
Content-Type: application/x-www-form-urlencoded

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

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.5. SAML 2.0 Subject Token Interoperability

Clients using SAML 2.0 for SSO with the IdP Authorization Server can obtain an ID-JAG without changing their SSO protocol to OpenID Connect by first exchanging the SAML 2.0 assertion for a Refresh Token using Token Exchange. This enables protocol transition to OAuth and allows the client to later use the Refresh Token as a subject_token to obtain an ID-JAG without prompting the user for a new Identity Assertion.¶

The OpenID Connect scopes openid offline_access SHOULD be requested (additional scopes are allowed) when requesting a Refresh Token from the IdP Authorization Server.¶

The IdP Authorization Server MUST map the SAML Audience to a Client ID and ensure the client's authentication matches that mapping before issuing the Refresh Token.¶

The following non-normative example shows a SAML 2.0 assertion where the Audience value (from AudienceRestriction) corresponds to the Service Provider Entity ID (SPAuthority / SPEntityID) and MUST be mapped to the OAuth Client ID that the IdP Authorization Server associates with that SAML SP registration.¶

<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="_123456789" IssueInstant="2025-03-01T12:34:56Z" Version="2.0">
  <saml2:Issuer>https://idp.example.com/</saml2:Issuer>
  <saml2:Subject>
    <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
      alice@example.com
    </saml2:NameID>
    <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml2:SubjectConfirmationData
          NotOnOrAfter="2025-03-01T12:39:56Z"
          Recipient="https://client.example.com/assertion-consumer"/>
    </saml2:SubjectConfirmation>
  </saml2:Subject>
  <saml2:Conditions NotBefore="2025-03-01T12:34:56Z" NotOnOrAfter="2025-03-01T13:34:56Z">
    <saml2:AudienceRestriction>
      <saml2:Audience>https://client.example.com/sp-entity-id</saml2:Audience>
    </saml2:AudienceRestriction>
  </saml2:Conditions>
  <saml2:AttributeStatement>
    <saml2:Attribute Name="given_name">
      <saml2:AttributeValue>Alice</saml2:AttributeValue>
    </saml2:Attribute>
  </saml2:AttributeStatement>
  <saml2:AuthnStatement AuthnInstant="2025-03-01T12:30:00Z">
    <saml2:AuthnContext>
      <saml2:AuthnContextClassRef>
        urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
      </saml2:AuthnContextClassRef>
    </saml2:AuthnContext>
  </saml2:AuthnStatement>
</saml2:Assertion>

When this assertion is used as the subject_token in Token Exchange, the IdP Authorization Server MUST verify that the Audience / SPEntityID maps to the OAuth Client ID that is authenticated for the token request. This prevents a client from presenting an assertion issued for a different SAML SP.¶

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:refresh_token
&scope=openid+offline_access+email
&subject_token=PHNhbWxwOkFzc2VydGlvbiB4bWxuczp...c2FtbDppc3N1ZXI+PC9zYW1sOkFzc2VydGlvbj4=
&subject_token_type=urn:ietf:params:oauth:token-type:saml2
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6IjIyIn0...

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:refresh_token",
  "access_token": "vF9dft4qmTcXkZ26zL8b6u",
  "token_type": "N_A",
  "scope": "openid offline_access email",
  "expires_in": 1209600
}

5.1. Client ID Mapping

In this flow, the IdP Authorization Server accepts a Token Exchange request from the Client, and issues an ID-JAG that will be consumed by the Resource Authorization Server. This means the IdP Authorization Server needs to know about the relationship between the Client and the Resource Authorization Server, in order to include a client_id claim in the ID-JAG that will be recognized by the Resource Authorization Server.¶

This can be handled by the IdP Authorization Server maintaining a record of each client_id used between Clients and Resource Authorization Servers, which will need to be obtained by out-of-band mechanisms. The Client still needs to authenticate using its registered credential with the Resource Authorization Server when presenting the ID-JAG for the mapped client_id. Requiring a confidential client helps to prevent the IdP Authorization Server from delegating access to any of the valid clients for the Resource Authorization Server.¶

Alternatively, if clients use "Client ID Metadata Document" [I-D.ietf-oauth-client-id-metadata-document] as their client identifiers, this acts as a shared global namespace of Client IDs and removes the need for the IdP Authorization Server to maintain a mapping of each client registration.¶

5.2. Subject Identifier Mapping

The IdP Authorization Server selects the subject identifiers in the ID-JAG for the Resource Authorization Server identified by the aud claim, not for the Client. The same user can have a pairwise subject identifier issued in an ID Token for SSO to the Client and another with SSO to the Resource Authorization Server as a Relying Party, and the Resource Authorization Server needs consistent subject identifiers for subject resolution across both SSO and API access.¶

The IdP Authorization Server MUST include the same sub value for a given End-User in every ID-JAG it issues for the same Resource Authorization Server and, when present, the same aud_tenant, regardless of which Client requested it. When the Resource Authorization Server uses OpenID Connect for SSO with the IdP Authorization Server, that value MUST be the sub the IdP Authorization Server would include in an ID Token issued to the Resource Authorization Server as a Relying Party. This requires the IdP Authorization Server to know which Relying Party registration corresponds to the Resource Authorization Server's issuer identifier, a mapping established out of band like the client_id mapping in Section 5.1. When pairwise subject identifiers are used, the sub claim of the ID-JAG can differ from the sub claim of the Client's ID Token (see Section 9.9).¶

When the Resource Authorization Server uses a different subject namespace for SSO, such as a SAML Assertion Subject <NameID> namespace, see the sub_id claim and Section 3.2.¶

6.1. Issuer and Tenant Relationship

An Authorization Server may operate as either a single-tenant or multi-tenant issuer:¶

• Single-tenant issuer: The issuer identifier (iss) uniquely identifies both the Authorization Server and the tenant. All clients and users belong to a single tenant context. The issuer identifier alone is sufficient to identify the tenant.¶

• Multi-tenant issuer: The issuer identifier (iss) identifies the Authorization Server, but multiple tenants may be hosted by the same issuer. In this case, the tenant identifier (tenant) claim is used in conjunction with the issuer identifier to uniquely identify the tenant context. The combination of iss + tenant uniquely identifies the tenant.¶

When an IdP Authorization Server issues an ID-JAG, it MUST include the tenant claim if the issuer is multi-tenant. The tenant value identifies the End-User's tenant at the issuer.¶

6.2. Client ID and Tenant Relationship

The relationship between client_id and tenant depends on the deployment model:¶

• Tenant-scoped client identifiers: In some deployments, the client_id is unique only within a tenant context. The same client_id value may exist in different tenants, and the combination of the Resource Authorization Server tenant and client_id uniquely identifies the client registration.¶

• Global client identifiers: In other deployments, the client_id is globally unique across all tenants. The client_id alone uniquely identifies the client, regardless of tenant context.¶

The IdP Authorization Server MUST understand the client identifier model used by the Resource Authorization Server when including the client_id claim in an ID-JAG. For tenant-scoped client identifiers, the IdP MUST ensure that the client_id included in the ID-JAG is valid within the Resource Authorization Server tenant for which the ID-JAG is issued (identified by aud_tenant, when present).¶

6.3. Subject Identifier Uniqueness with Tenants

As specified in Section 3, subject identifiers (sub) have different uniqueness requirements based on tenant configuration:¶

• For single-tenant issuers: The subject identifier MUST be unique when scoped with issuer (iss + sub).¶

• For multi-tenant issuers: The subject identifier MUST be unique when scoped with issuer and tenant (iss + tenant + sub).¶

The IdP Authorization Server MUST ensure that the sub claim in the ID-JAG follows the appropriate uniqueness rules for the target Resource Authorization Server.¶

6.4. Tenant Context in Token Exchange

When a Client requests an ID-JAG via Token Exchange, the IdP Authorization Server determines the value of each tenant claim it includes:¶

• tenant: the issuer tenant, which is the End-User's tenant, from the subject token. The subject token was issued to the authenticated Client in that tenant.¶

• aud_tenant: the Resource Authorization Server tenant, from the requested audience and resource and the issuer tenant's configuration for that Resource Authorization Server. The IdP Authorization Server selects client_id (Section 6.2), sub (Section 5.2), and aud_sub for that tenant.¶

7.1. IdP Authorization Server Metadata

An IdP Authorization Server can advertise the identity chaining token types it can issue in its OAuth Authorization Server Metadata [RFC8414]. Identity and Authorization Chaining Across Domains [I-D.ietf-oauth-identity-chaining] defines the identity_chaining_requested_token_types_supported metadata parameter for this purpose.¶

To advertise support for issuing an Identity Assertion JWT Authorization Grant via Token Exchange, the IdP Authorization Server SHOULD include the following value in identity_chaining_requested_token_types_supported:¶

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

The IdP Authorization Server SHOULD sign ID-JAGs with a key published at the jwks_uri in its metadata, located from its issuer identifier as described in Section 3 of [RFC8414]. A Resource Authorization Server that cannot retrieve metadata from that location MAY fall back to Section 4 of [OpenID.Discovery], as described in Section 5 of [RFC8414].¶

The IdP Authorization Server can also advertise the algorithms it uses to sign ID-JAGs:¶

id_jag_signing_alg_values_supported:

OPTIONAL. JSON array containing a list of the JWS signing algorithms (alg values) supported by the IdP Authorization Server for signing ID-JAGs. If present, the list MUST include RS256. id_token_signing_alg_values_supported [OpenID.Discovery] does not describe ID-JAGs, which the IdP Authorization Server can sign differently from ID Tokens.¶

7.2. Resource Authorization Server Metadata

A Resource Authorization Server can advertise support for authorization grant profiles in its OAuth Authorization Server Metadata [RFC8414] using the authorization_grant_profiles_supported metadata parameter.¶

The value of authorization_grant_profiles_supported MUST be a JSON array of strings. Each string MUST identify a supported authorization grant profile.¶

Inclusion of a profile identifier in authorization_grant_profiles_supported indicates only that the Resource Authorization Server implements the processing rules for that profile. It does not indicate that any particular issuer, tenant, client, subject, audience, or authorization request will be accepted.¶

To advertise support for the Identity Assertion JWT Authorization Grant profile, the Resource Authorization Server SHOULD include the following value in the authorization_grant_profiles_supported property:¶

urn:ietf:params:oauth:grant-profile:id-jag¶

A Resource Authorization Server that includes urn:ietf:params:oauth:grant-profile:id-jag in authorization_grant_profiles_supported for this specification MUST also include urn:ietf:params:oauth:grant-type:jwt-bearer in grant_types_supported.¶

9.1. Client Authentication

The IdP Authorization Server always authenticates the Client (Section 4.3). The Resource Authorization Server usually does too, but it can instead accept a sender-constrained ID-JAG from a Client that does not authenticate (Section 4.4). It then relies on the IdP Authorization Server: the client_id claim identifies the Client that the IdP Authorization Server authenticated, and proof of possession shows that the presenter holds the key the IdP Authorization Server bound to the ID-JAG for that Client. Without the key binding, anyone holding a copy of the ID-JAG could present it. Clients that cannot authenticate to the IdP Authorization Server SHOULD use the existing authorization code grant and redirect the user to the Resource Authorization Server with an OAuth 2.0 Authorization Request where the user can interactively consent to the access delegation.¶

9.2. Storage of Subject Tokens

The subject tokens used with this specification, whether an OpenID Connect ID Token, a SAML 2.0 Assertion, or a Refresh Token issued by the IdP Authorization Server, are high-value artifacts. A client that holds one of these can obtain an ID-JAG for any Resource Authorization Server the IdP policy permits, and can then redeem each ID-JAG for an access token at the corresponding Resource Authorization Server. A compromised subject token therefore exposes not only the IdP, but potentially every downstream resource reachable through it, and does so without further interaction with the user.¶

Exploiting a stolen subject token also requires the attacker to authenticate to the IdP Authorization Server's token endpoint as the client, since the Token Exchange request requires client authentication. This means the client's credentials are the only remaining barrier, and both the subject token and the client credentials are typically held by the same deployment. An attacker who obtains access to the client's storage, backup, logs, or process memory is likely to obtain both. Deployments SHOULD NOT rely on client authentication alone to mitigate the theft of subject tokens.¶

Clients that retain subject tokens beyond the immediate Token Exchange request:¶

• SHOULD protect them at rest with at least the same protections applied to the client's own credentials, and SHOULD store them in a separate protection domain from the client credentials, for example by keeping client authentication keys in a hardware security module or key management service so that both cannot be exfiltrated together.¶

• SHOULD NOT write them to application logs, error reports, telemetry, traces, or crash dumps, and SHOULD NOT include them in HTTP request URIs where they may be recorded by intermediaries.¶

• SHOULD scope stored subject tokens to the individual user session or task they were obtained for, rather than pooling them in a shared cache that any part of the client can read.¶

• SHOULD discard them as soon as they are no longer needed, and SHOULD NOT cache an Identity Assertion beyond its expiration.¶

• SHOULD prefer requesting a new ID-JAG when needed over caching issued ID-JAGs and access tokens, since the ID-JAG and any resulting access tokens are themselves credentials subject to the same handling requirements.¶

IdP Authorization Servers SHOULD limit exposure from a compromised subject token by issuing Identity Assertions with short lifetimes, and, when Refresh Tokens are accepted as subject tokens, by sender-constraining those Refresh Tokens as described in Section 9.11, rotating them on use, and binding them to the client that they were issued to. IdP Authorization Servers SHOULD also provide a mechanism to revoke Refresh Tokens and to invalidate outstanding sessions for a subject, so that a detected compromise can be contained before the affected subject tokens expire.¶

Because a single subject token can be exchanged for ID-JAGs targeting many different Resource Authorization Servers, IdP Authorization Servers SHOULD record the audience, resource, scope, and authenticated client of each Token Exchange request, which allows unusual patterns, such as a client requesting ID-JAGs for audiences it does not normally access, to be detected.¶

9.3. Step-Up Authentication

In the initial token exchange request, the IdP may require step-up authentication for the subject if the authentication context in the subject's assertion does not meet policy requirements. An insufficient_user_authentication OAuth error response may be returned to convey the authentication requirements back to the client similar to OAuth 2.0 Step-up Authentication Challenge Protocol [RFC9470].¶

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
}

The Client would need to redirect the user back to the IdP to obtain a new assertion that meets the requirements and retry the token exchange.¶

TBD: It may make more sense to request the Identity Assertion JWT Authorization Grant in the authorization request if using OpenID Connect for SSO when performing a step-up to skip the need for additional token exchange round-trip.¶

9.4. Cross-Domain Use

This specification is intended for cross-domain uses where the Client, Resource Authorization Server, and IdP are in different trust domains. In particular, the IdP MUST NOT issue access tokens in response to an ID-JAG it issued itself unless explicitly configured to do so, since this could lead to unintentional broadening of the scope of authorization. When so configured, the IdP MUST NOT grant the client more access than it would when issuing an access token for the same subject and resource directly, and evaluates any consent and authentication requirements when issuing the ID-JAG, since the access token request does not involve the user. This does not preclude a single piece of software from being both an IdP issuing ID-JAGs as well as a Resource Authorization Server consuming ID-JAGs, as long as the ID-JAG crosses a trust domain such as a tenant or customer boundary.¶

An ID-JAG is specific to the trust relationship between the issuing IdP Authorization Server and the Resource Authorization Server identified by the aud claim. When a deployment involves additional downstream hops, the same ID-JAG MUST NOT be reused as the authorization grant for a different downstream Resource Authorization Server. For each subsequent hop, a new ID-JAG MAY be issued by the IdP Authorization Server trusted by that downstream Resource Authorization Server for SSO and subject resolution, or other mechanisms MAY be used.¶

9.5. Authorization Server Metadata Validation

Clients that discover an Authorization Server's metadata using OAuth 2.0 Authorization Server Metadata [RFC8414] MUST validate that the issuer value in the metadata document is identical to the Authorization Server issuer identifier used to construct the metadata retrieval URL, as required by Section 3.3 of [RFC8414]. If the values are not identical, the client MUST NOT use the metadata. This validation is particularly important for this specification because more steps happen without user interaction than in an interactive OAuth flow, and a mismatch can enable an attacker who controls an Authorization Server metadata document to redirect ID-JAG issuance toward an Authorization Server the client did not intend to use.¶

For example, an attacker's protected resource references an attacker-controlled Authorization Server whose metadata declares an issuer value matching a legitimate Resource Authorization Server the user's IdP already trusts. A client that skips the issuer check treats the malicious metadata as authoritative for the legitimate Authorization Server and requests an ID-JAG with audience set to that server. The client then presents the ID-JAG and its client authentication to the attacker's token endpoint. The attacker relays both to the legitimate Resource Authorization Server, authenticating as the client with the client_secret it received or with a client assertion whose aud is the legitimate issuer, and obtains an access token for the End-User.¶

The client-side issuer check required by Section 3.3 of [RFC8414] is the primary defense. When the client has validated the attacker's Protected Resource Metadata (Section 9.6) and includes its resource value (Section 4.3), the ID-JAG names the attacker's resource, so the legitimate Resource Authorization Server rejects the relayed ID-JAG because it does not govern that resource (Section 4.4). An IdP that checks which resources that Resource Authorization Server governs (Section 4.3) rejects the Token Exchange request instead, so the ID-JAG never reaches the attacker. A sender-constrained ID-JAG (Section 9.11) also defeats the relay, because the attacker cannot prove possession of the client's key.¶

9.6. Protected Resource Metadata Validation

Clients that discover the Resource Authorization Server for a protected resource via Protected Resource Metadata [RFC9728] MUST validate that metadata as required by Section 3.3 of [RFC9728], including verifying that the resource value is identical to the resource identifier used to construct the metadata URL or, when the metadata URL came from a WWW-Authenticate response, to the URL of the request that received that response. Without this check, an attacker who publishes metadata at their own resource can misrepresent the resource identifier and redirect the client toward an Authorization Server unrelated to the intended resource.¶

Together with the Authorization Server metadata issuer check in Section 9.5, this validation binds discovery to the resource the client intended to access, and including the validated resource value in the Token Exchange request (Section 4.3) binds the grant to it.¶

9.7. Metadata Disclosure

Advertising issuer-specific trust relationships in publicly accessible metadata can disclose federation topology, business relationships, tenant configuration, or other deployment-sensitive information.¶

Resource Authorization Servers MUST NOT use authorization_grant_profiles_supported to disclose issuer allow lists or other profile-specific trust relationships.¶

Resource Authorization Servers MAY provide a protected discovery mechanism by which an authenticated client can determine whether an Identity Assertion JWT Authorization Grant from a particular issuer would be accepted for that client. If such a mechanism is provided, the Resource Authorization Server MUST require client authentication before disclosing issuer-specific acceptance information. The response MUST be specific to the authenticated client and MAY also be scoped by tenant, resource, or other local policy context.¶

9.8. Subject Identifier Trust

When the ID-JAG includes a sub_id claim, the Resource Authorization Server MUST NOT use the sub_id.issuer value to establish trust in the ID-JAG issuer. The ID-JAG MUST first be validated using the iss claim, signature, audience, expiration, and client binding according to this specification.¶

The Resource Authorization Server MUST use a SAML NameID sub_id only when the validated ID-JAG issuer is explicitly associated with the SAML issuer identified by sub_id.issuer through local configuration or trusted federation metadata.¶

A Resource Authorization Server that resolves the subject using email or aud_sub relies on the administrators of the issuer tenant for those values. It SHOULD do so only when it trusts that issuer tenant as authoritative for them, for example for email addresses in domains the tenant has verified, because administrators of another tenant at the same issuer can set any value.¶

9.9. Subject Identifier Disclosure

The IdP Authorization Server SHOULD include sub_id only when needed by the target Resource Authorization Server for subject resolution. Because the ID-JAG is visible to the Client that presents it, sub_id can disclose additional user identifiers, such as email-address NameIDs or stable enterprise account identifiers, that the Client might not otherwise receive. For the same reason, a pairwise sub selected for the Resource Authorization Server (Section 5.2) is disclosed to the Client, which can link it to the sub in its own ID Token. The IdP Authorization Server SHOULD minimize the subject identifiers included in the ID-JAG to those required by the Resource Authorization Server.¶

9.10. Actor Delegation Extensions

This specification allows Token Exchange requests for ID-JAG to carry actor_token, but it does not define normative processing requirements for it. Future profiles or extensions can define how actor_token is validated, authorized, and reflected in the issued ID-JAG, including whether an act claim is included.¶

Profiles or extensions that define use of actor_token need to consider delegation risks. In particular, a client could attempt to combine a valid subject_token with an unrelated or less-trusted actor_token to obtain an ID-JAG that overstates the actor's authority.¶

Such profiles or extensions should define how actor_token is validated, how the relationship between the authenticated client, subject, and actor is authorized, how any resulting act claim is derived, and how unnecessary disclosure of actor identity or attributes is minimized across trust domains.¶

When such profiles or extensions use an act claim, they should preserve the distinction between the actor identified by act and the resource owner identified by sub. The authenticated client identity is also not a substitute for actor identity.¶

9.11. Sender Constraining Tokens

Identity Assertion JWT Authorization Grant may support key binding to enable sender-constrained tokens as described in Section 5.2 of [I-D.ietf-oauth-identity-chaining] and [I-D.parecki-oauth-jwt-dpop-grant]. This provides additional security by binding tokens to a specific cryptographic key or certificate, preventing reuse by parties that do not have access to the corresponding private key.¶

This specification defines two sender-constraining mechanisms for the ID-JAG:¶

• DPoP Key Binding (Section 9.11.1): binding via a DPoP proof JWT as defined by [RFC9449]. The cnf claim carries a jkt property with the JWK SHA-256 Thumbprint of the bound key.¶

• mTLS Certificate Binding (Section 9.11.2): binding via a mutually authenticated TLS session using an X.509 client certificate as defined by Section 3 of [RFC8705]. The cnf claim carries an x5t#S256 property with the SHA-256 thumbprint of the DER encoding of the bound X.509 certificate.¶

An IdP SHOULD NOT bind the same ID-JAG to both a DPoP key and an X.509 certificate. If both a DPoP proof and a certificate suitable for binding are presented on the same Token Exchange request, the IdP selects a single binding mechanism according to local policy for the target Resource Authorization Server.¶

The cnf (confirmation) claim, as defined in [RFC7800], is used to bind a key or certificate to a JWT. When an ID-JAG contains a cnf claim, proof of possession of the corresponding private key or X.509 certificate MUST be demonstrated when using the ID-JAG at the Resource Authorization Server. A Resource Authorization Server that does not support the confirmation method in the cnf claim MUST reject the request with an invalid_grant error.¶

The following sections describe the processing rules for each mechanism at two stages: during the Token Exchange (when requesting an ID-JAG from the IdP) and during the ID-JAG exchange (when exchanging the ID-JAG for an access token at the Resource Authorization Server).¶

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

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

{
  "jti": "9e43f81b64a33f20116179",
  "iss": "https://acme.idp.example/",
  "sub": "U019488227",
  "aud": "https://acme.chat.example/",
  "client_id": "f53f191f9311af35",
  "exp": 1311281270,
  "iat": 1311280970,
  "resource": "https://api.chat.example/",
  "scope": "chat.read chat.history",
  "cnf": {
    "jkt":"0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"
  }
}

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

grant_type=urn:ietf:params:oauth:grant-type:jwt-dpop
&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6Im9hdXRoLWlkLWphZytqd3QifQ...

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

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

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

{
  "error": "invalid_grant",
  "error_description": "Proof of possession required for this authorization grant"
}

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

{
  "error": "invalid_grant",
  "error_description": "Sender-constrained tokens required for this resource server"
}

"cnf": {
  "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
}

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

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6Im9hdXRoLWlkLWphZytqd3QifQ...
&client_id=f53f191f9311af35


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

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

11.1. Media Types

This section registers oauth-id-jag+jwt, a new media type [RFC2046] in the "Media Types" registry [IANA.media-types] in the manner described in [RFC6838]. It can be used to indicate that the content is an Identity Assertion JWT Authorization Grant.¶

11.2. OAuth URI Registration

This section registers urn:ietf:params:oauth:token-type:id-jag in the "OAuth URI" subregistry of the "OAuth Parameters" registry [IANA.oauth-parameters].¶

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

• Common Name: Token type URI for an Identity Assertion JWT Authorization Grant¶

• Change Controller: IETF¶

• Specification Document: This document¶

This section registers urn:ietf:params:oauth:grant-profile:id-jag in the "OAuth URI" subregistry of the "OAuth Parameters" registry [IANA.oauth-parameters].¶

• URN: urn:ietf:params:oauth:grant-profile:id-jag¶

• Common Name: Authorization grant profile identifier for an Identity Assertion JWT Authorization Grant¶

• Change Controller: IETF¶

• Specification Document: This document¶

11.3. OAuth Authorization Server Metadata Registration

This section registers the following in the "OAuth Authorization Server Metadata" registry of the "OAuth Parameters" registry [IANA.oauth-parameters].¶

• Metadata Name: authorization_grant_profiles_supported¶

• Metadata Description: JSON array of supported authorization grant profile identifiers¶

• Change Controller: IETF¶

• Specification Document: This document¶

• Metadata Name: id_jag_signing_alg_values_supported¶

• Metadata Description: JSON array of the JWS signing algorithms supported for signing Identity Assertion JWT Authorization Grants¶

• Change Controller: IETF¶

• Specification Document: This document¶

11.4. OAuth Dynamic Client Registration Metadata Registration

This section registers authorization_grant_profiles_supported in the "OAuth Dynamic Client Registration Metadata" registry of the "OAuth Parameters" registry [IANA.oauth-parameters], established by [RFC7591].¶

• Metadata Name: authorization_grant_profiles_supported¶

• Metadata Description: JSON array of authorization grant profile identifiers supported by the client¶

• Change Controller: IETF¶

• Specification Document: Section 8¶

11.5. JSON Web Token Claims Registration

This section registers the following claims in the "JSON Web Token Claims" subregistry of the "JSON Web Token (JWT)" registry [IANA.jwt]. The "JSON Web Token Claims" subregistry was established by [RFC7519].¶

• Claim Name: resource¶

• Claim Description: Resource¶

• Change Controller: IETF¶

• Specification Document(s): Section 3¶

• Claim Name: aud_tenant¶

• Claim Description: Resource Authorization Server tenant identifier¶

• Change Controller: IETF¶

• Specification Document(s): Section 3¶

11.6. Security Event Identifier Format Registration

This section registers the saml-nameid Subject Identifier Format in the "Security Event Identifier Formats" registry established by [RFC9493].¶

• Format Name: saml-nameid¶

• Format Description: SAML NameID Subject Identifier Format¶

• Change Controller: IETF¶

• Reference: Section 3.2.1¶

12.1. Normative References

[I-D.ietf-oauth-identity-chaining]

Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins, M. J., Campbell, B., and A. Parecki, "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-chaining-17, 19 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-chaining-17>.

[I-D.parecki-oauth-jwt-dpop-grant]

Parecki, A., "OAuth 2.0 JWT Authorization Grant with DPoP Binding", Work in Progress, Internet-Draft, draft-parecki-oauth-jwt-dpop-grant-02, 30 October 2026, <https://datatracker.ietf.org/doc/html/draft-parecki-oauth-jwt-dpop-grant-02>.

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

[OASIS.saml-core-2.0-os]

Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, March 2005, <https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.

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

Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 2", December 2023, <https://openid.net/specs/openid-connect-discovery-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>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

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

[RFC7518]

Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/rfc/rfc7518>.

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

[RFC7591]

Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, <https://www.rfc-editor.org/rfc/rfc7591>.

[RFC7638]

Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/rfc/rfc7638>.

[RFC7800]

Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, <https://www.rfc-editor.org/rfc/rfc7800>.

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

[RFC8705]

Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, <https://www.rfc-editor.org/rfc/rfc8705>.

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

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

[RFC9493]

Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject Identifiers for Security Event Tokens", RFC 9493, DOI 10.17487/RFC9493, December 2023, <https://www.rfc-editor.org/rfc/rfc9493>.

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

12.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-02, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-02>.

[RFC9068]

Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, <https://www.rfc-editor.org/rfc/rfc9068>.

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

A.1. Enterprise Deployment

Enterprises often have hundreds of SaaS applications. SaaS applications often have integrations to other SaaS applications that are critical to the application experience and jobs to be done. When a SaaS app needs to request an access token on behalf of a user to a 3rd party SaaS integration's API, the end-user typically needs to complete an interactive delegated OAuth 2.0 flow, as the SaaS application is not in the same security or policy domain as the 3rd party SaaS integration.¶

It is industry best practice for an enterprise to connect their ecosystem of SaaS applications to their Identity Provider (IdP) to centralize identity and access management capabilities for the organization. End-users get a better experience (SSO) and administrators get better security outcomes such as multi-factor authentication and zero-trust. SaaS applications today enable the administrator to establish trust with an IdP for user authentication.¶

This specification can be used to extend the SSO relationship of multiple SaaS applications to include API access between these applications as well. This specification enables federation for Authorization Servers across policy or administrative boundaries. The same enterprise IdP that is trusted by applications for SSO can be extended to broker access to APIs. This enables the enterprise to centralize more access decisions across their SaaS ecosystem and provides better end-user experience for users that need to connect multiple applications via OAuth 2.0.¶

A.2. Customer Identity for Developer SaaS Components

In deployments where the shared identity layer serves customer-facing applications, the IdP is a Customer Identity and Access Management (CIAM) platform that signs end-users into a customer-facing application or suite of first-party applications rather than a workforce IdP used to sign employees into internal or SaaS productivity tools.¶

These customer applications often embed or depend on third-party developer SaaS components such as communications, analytics, fraud detection, document processing, support tooling, or logging and observability services. A first-party application may need to request an access token on behalf of the signed-in customer so that these components can be invoked seamlessly as part of the product experience, without interrupting the customer with separate delegated OAuth authorization prompts for each downstream service.¶

This specification can be used in these deployments when the CIAM platform serves as the common identity layer trusted by the first-party applications and by the authorization servers for the third-party developer SaaS components. In that model, the CIAM platform can broker an Identity Assertion JWT Authorization Grant that allows the component provider to issue an access token scoped to the customer and to the specific component APIs needed by the first-party application.¶

A.3. Email and Calendaring Applications

Email clients can be used with arbitrary email servers, and cannot require pre-established relationships between each email client and each email server. When an email client uses OAuth to obtain an access token to an email server, this provides the security benefit of being able to use strong multi-factor authentication methods provided by the email server's authorization server, but does require that the user go through a web-based flow to log in to the email client. However, this web-based flow is often seen as disruptive to the user experience when initiated from a desktop or mobile native application, and so is often attempted to be minimized as much as possible.¶

When the email client needs access to a separate API, such as a third-party calendaring application, traditionally this would require that the email client go through another web-based OAuth redirect flow to obtain authorization and ultimately an access token.¶

To streamline the user experience, this specification can be used to enable the email client to use the Identity Assertion to obtain an access token for the third-party calendaring application without any user interaction.¶

A.4. AI Agent using External Tools

AI agents are designed to perform complex tasks on behalf of users, often requiring integration with external tools provided by SaaS applications, internal services, or enterprise data sources. When accessing these systems, the agent often operates on behalf of the end user, and its actions are constrained by the user's identity, role, and permissions. In agentic systems, the relevant IdP for a given ID-JAG hop is the IdP Authorization Server the downstream Resource Authorization Server already trusts for SSO and subject resolution at that boundary. That may be an enterprise workforce IdP, a CIAM or product identity layer, or an internal platform IdP depending on the deployment.¶

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

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

{
  "issuer": "https://idp.cyberdyne-corp.example/",
  "authorization_endpoint": "https://idp.cyberdyne-corp.example/oauth2/authorize",
  "token_endpoint": "https://idp.cyberdyne-corp.example/oauth2/token",
  "userinfo_endpoint": "https://idp.cyberdyne-corp.example/oauth2/userinfo",
  "jwks_uri": "https://idp.cyberdyne-corp.example/oauth2/keys",
  "registration_endpoint": "https://idp.cyberdyne-corp.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"],
  ...
}

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

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

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

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

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

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

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

GET /
Host: api.saas-tool.example
Accept: application/json

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

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

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

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

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

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

{
  "issuer": "https://authorization-server.saas-tool.example/",
  "authorization_endpoint": "https://authorization-server.saas-tool.example/oauth2/authorize",
  "token_endpoint": "https://authorization-server.saas-tool.example/oauth2/token",
  "jwks_uri": "https://authorization-server.saas-tool.example/oauth2/keys",
  "registration_endpoint": "https://authorization-server.saas-tool.example/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"
  ],
  "authorization_grant_profiles_supported": ["urn:ietf:params:oauth:grant-profile:id-jag"],
  ...
}

POST /oauth2/token HTTP/1.1
Host: idp.cyberdyne-corp.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-tool.example/
&resource=https://api.saas-tool.example/
&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...

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": "eyJhbGciOiJSUzI1NiIsI...",
  "token_type": "N_A",
  "scope": "agent.read agent.write",
  "expires_in": 300
}

{
  "alg": "ES256",
  "typ": "oauth-id-jag+jwt"
}
.
{
  "jti": "9e43f81b64a33f20116179",
  "iss": "https://idp.cyberdyne-corp.example/",
  "sub": "1997e829-2029-41d4-a716-446655440000",
  "aud": "https://authorization-server.saas-tool.example/",
  "resource": "https://api.saas-tool.example/",
  "client_id": "https://ai-agent-app.example/",
  "exp": 1984445400,
  "iat": 1984445100,
  "scope": "agent.read agent.write"
}
.
signature

POST /oauth2/token HTTP/1.1
Host: authorization-server.saas-tool.example
Authorization: Basic yZS1yYW5kb20tc2VjcmV0v3JOkF0XG5Qx2
Content-Type: application/x-www-form-urlencoded

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

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"
}

GET /tools
Host: api.saas-tool.example
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA
Accept: application/json

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

{
  ...
}