Identity Assertion JWT Authorization Grant

Identity Assertion JWT Authorization Grant Okta

aaron@parecki.com

Independent

public@karlmcguinness.com

Ping Identity

bcampbell@pingidentity.com

Security Web Authorization Protocol cross-domain authorization authz assertion enterprise This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through an identity provider that the downstream Resource Authorization Server already trusts for single sign-on (SSO), using OAuth 2.0 Token Exchange (RFC 8693) and the JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523). This pattern is informally referred to as Cross-App Access (XAA). About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction In many deployments, applications are configured for single sign-on to a common identity provider (IdP) using OpenID Connect or SAML. This enables users to access multiple applications using a single account at the IdP, and enables the operator of that IdP to manage which users can access which applications and enforce policy for access to those applications. Enterprise workforce identity providers are one common example, but the same trust pattern can also arise in customer identity, platform identity, and other federated application ecosystems. When one application wants to access a user's data at another application, it will start an interactive OAuth flow to obtain an access token for the application on behalf of the user. This OAuth flow enables a direct app-to-app connection between the two apps, and is not visible to the IdP used to log in to each app. This specification defines Cross-App Access (XAA): a pattern in which an application's access to another application's API is mediated by the IdP that both applications already trust for SSO and subject resolution. XAA extends the IdP's role from single sign-on to brokering cross-domain API access, using the same trust relationships that already exist for SSO. XAA is built on top of OAuth 2.0 by profiling "Identity Chaining Across Trust Domains" , which combines OAuth 2.0 Token Exchange and the JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants to chain a JWT authorization grant across trust domains. Identity Chaining intentionally leaves many details unspecified in order to support multiple use cases. This specification profiles it for XAA by defining:

the Token Exchange request used to obtain an Identity Assertion JWT Authorization Grant ();
the ID-JAG itself, including its claims and format;
the processing rules applied by the Resource Authorization Server when exchanging an ID-JAG for an Access Token; and
the authorization server and client metadata used to discover support for the profile.

In particular, this profile requires an Identity Assertion (such as an OpenID Connect ID Token or SAML 2.0 assertion) as the Token Exchange subject_token input. Unlike profiles in which the IdP issues access tokens directly to be consumed by the Resource Server (such as the OAuth 2.0 JWT Profile for Access Tokens ), this specification preserves the Resource Authorization Server as the issuer of access tokens for its protected resources. This lets the IdP centralize federated identity, SSO trust, and the decision to broker cross-app access, while the Resource Authorization Server keeps independent control over its own access tokens. The Resource Authorization Server determines whether to honor a given ID-JAG, what scopes or authorization details to grant, and what access token to issue, applying its own local policy.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

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 , 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) or SAML 2.0 Identity Provider that issues Identity Assertions for single sign-on and cross-domain authorization grants 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 , 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 , this is the Authorization Server in trust domain B, and trusts cross-domain authorization grants from the IdP Authorization Server.
Resource Server (RS): Hosts protected resources and validates access tokens issued by the Resource Authorization Server. In , 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.

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 , JSON Web Token (JWT) , JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants , OAuth 2.0 Token Exchange , and OAuth 2.0 Authorization Server Metadata , 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 , 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 () as a specific instance of cross-domain 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.

Identity Assertion JWT Authorization Grant The Identity Assertion JWT Authorization Grant (ID-JAG) is a profile of the JWT Authorization Grant that grants a client delegated access to a resource, typically in another trust domain, on behalf of a user without a direct user-approval step at the authorization server. In addition to traditional OAuth scope-based authorization, this specification can be extended with Rich Authorization Requests (RAR) , allowing clients to request limited authorization using structured authorization details. An ID-JAG is issued and signed by an IdP Authorization Server similar to an ID Token , and contains claims about an End-User. Instead of being issued for a Client (Relying Party in ) as the intended audience for the assertion, it is instead issued with an audience of an Authorization Server, typically in another trust domain (Resource Authorization Server). It replaces the need for the client to obtain an authorization code from the Resource Authorization Server to delegate access to the client, and instead uses the IdP Authorization Server that is trusted by the Resource Authorization Server for SSO and subject resolution to delegate access to the client. The Resource Authorization Server still applies local policy when deciding whether to honor the ID-JAG and what access token to issue. As described in , ID Tokens are only intended to be processed by the Relying Party (indicated by the ID Token audience) or the Issuer (e.g. for revocation), and not by other actors in a different trust domain such as an Authorization Server. Because an ID-JAG is a JWT authorization grant, RS256 is mandatory to implement for both the IdP Authorization Server and the Resource Authorization Server (). Resource Authorization Servers SHOULD also support ES256 .

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 .
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 . 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 . 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 for the SAML NameID Subject Identifier Format defined by this specification, and for processing rules.
aud:: REQUIRED - The issuer identifier of the Resource Authorization Server as defined in .
client_id:: REQUIRED - The client identifier of the OAuth 2.0 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 , as it represents an independent client relationship with another Authorization Server in a different trust domain. See for additional considerations.
jti:: REQUIRED - Unique ID of this JWT as defined in .
exp:: REQUIRED - as defined in .
iat:: REQUIRED - as defined in .
resource:: OPTIONAL - Identifies the protected resource(s) for which access is granted, using resource identifiers as defined in . 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 .
scope:: OPTIONAL - a JSON string containing a space-separated list of scopes associated with the token, in the format described in .
authorization_details:: OPTIONAL - A JSON array of authorization detail objects as defined in . This claim enables Rich Authorization Requests (RAR) support, allowing structured authorization requests beyond simple scope strings.
act:: OPTIONAL - Actor claim as defined in . 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
auth_time:: OPTIONAL - Time when End-User authenticated as defined in .
acr:: OPTIONAL - Authentication Context Class Reference that was satisfied when authenticating the End-User as defined in .
amr:: OPTIONAL - Identifiers for authentication methods used when authenticating the End-User as defined in .
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 .
email:: OPTIONAL - End-User's e-mail address as defined in Section 5.1 of .

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 . A non-normative example JWT with expanded header and payload claims is below: 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 (). 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 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 and/or aud_sub 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.

SAML NameID Subject Identifier

Subject Identifier Format This specification defines the SAML NameID Subject Identifier Format for use in the sub_id claim . The SAML NameID Subject Identifier Format is identified by the name saml-nameid and identifies a subject using a SAML 2.0 Assertion Subject <NameID> value within the context of a SAML issuer . This format is intended for deployments where the Resource Authorization Server resolves users using a SAML <NameID> from its SSO trust relationship with the IdP Authorization Server, rather than the ID-JAG issuer's iss and sub values. A Subject Identifier in this format MUST contain:

format:: A JSON string containing the value saml-nameid identifying this Subject Identifier Format, as defined in .
issuer:: A JSON string containing the SAML issuer entity identifier for the assertion or configured mapping containing the SAML Assertion Subject <NameID>, as defined by Section 8.3.6 of . SAML <Issuer> attributes are not represented by this format.
nameid:: A JSON string containing the SAML Assertion Subject <NameID> value as defined in .

A Subject Identifier in this format MAY contain:

nameid_format:: A JSON string containing the value of the Format attribute on the SAML Assertion Subject <NameID> as defined in .
name_qualifier:: A JSON string containing the value of the NameQualifier attribute on the SAML Assertion Subject <NameID> as defined in .
sp_name_qualifier:: A JSON string containing the value of the SPNameQualifier attribute on the SAML Assertion Subject <NameID> as defined in .
sp_provided_id:: A JSON string containing the value of the SPProvidedID attribute on the SAML Assertion Subject <NameID> as defined in .

The following is a non-normative example of a sub_id claim using the SAML NameID Subject Identifier Format:

Subject Identifier Processing When the Resource Authorization Server resolves users by SAML Assertion Subject <NameID>, the IdP Authorization Server MAY include a sub_id claim using the SAML NameID Subject Identifier Format (). The sub_id claim identifies the same subject as the ID-JAG sub claim, but in the SAML subject namespace used by the Resource Authorization Server for SSO. When constructing a SAML NameID Subject Identifier, the IdP Authorization Server MUST derive its members from the SAML Assertion Subject <NameID> value it would use for SSO to the target Resource Authorization Server, or from an equivalent configured mapping that records the SAML <NameID> value and attributes the IdP Authorization Server would issue for that subject and Resource Authorization Server. Each optional field MUST be included exactly when the corresponding attribute is present on that <NameID> or in the configured mapping. The SAML NameID sub_id MUST identify the same subject as the ID-JAG sub claim. The SAML NameID Subject Identifier is intended to function as a stable, cross-trust-domain identifier for the End-User. The following requirements apply to the SAML <NameID> value conveyed in this format:

Stability. The nameid value MUST be a SAML <NameID> that the Resource Authorization Server treats as stable for SSO subject resolution. Transient NameID Formats (such as urn:oasis:names:tc:SAML:2.0:nameid-format:transient, defined in Section 8.3.8 of ) MUST NOT be used, because their values change across sessions and cannot serve as a cross-trust-domain identifier. Other Formats (including emailAddress and persistent) MAY be used. The SAML NameID Subject Identifier inherits the lifecycle and subject-resolution properties of the underlying Format. For example, when emailAddress is used, the same considerations that apply to SAML SSO with mutable email identifiers (changes propagating to the relying party, reassignment risks) apply to the SAML NameID Subject Identifier.
Identifier scope. A SAML <NameID> is unique within the context of the SAML issuer (issuer) and the Service Provider (as scoped by sp_name_qualifier when present), not globally unique within the issuer. NameIDs may be public (a single value for an End-User across all Service Providers) or pairwise (different values per Service Provider). When the IdP Authorization Server issues pairwise NameIDs, the nameid value placed in the SAML NameID Subject Identifier MUST be the value the IdP would issue to the SAML Service Provider corresponding to the target Resource Authorization Server. The IdP Authorization Server MUST maintain the mapping between the OAuth client_id of the Resource Authorization Server and the SAML Service Provider entity ID used for SSO with the corresponding application, so pairwise NameIDs resolve under the correct Service Provider scope. The IdP Authorization Server MUST NOT assume the nameid value identifies the same End-User across different Service Providers without the qualifying scope members.
Non-NameID subject resolution. Some SAML deployments resolve users by a SAML attribute outside the <Subject> element (for example, an attribute in the <AttributeStatement> such as the http://schemas.microsoft.com/identity/claims/objectidentifier attribute used by Microsoft Entra ID). In those deployments, the SAML NameID Subject Identifier is not the correct vehicle. The IdP Authorization Server SHOULD convey the relevant attribute value as an additional claim in the ID-JAG so the Resource Authorization Server can perform subject resolution. The choice of attribute and identifier type is deployment-specific: a SAML Service Provider and Resource Authorization Server may use either pairwise (different values per Service Provider) or public (a single value across Service Providers) identifiers, depending on local needs. Immutable identifiers are preferred. Mutable identifiers (such as emailAddress) MAY be used for subject resolution, subject to the considerations described in the Stability requirement above. When the attribute is pairwise per Service Provider, the IdP Authorization Server MUST use the value scoped to the SAML Service Provider corresponding to the target Resource Authorization Server.

The Resource Authorization Server MAY use sub_id for subject resolution when it supports the indicated Subject Identifier Format. The Resource Authorization Server MUST compare every member of the SAML NameID Subject Identifier that is part of the set of identifier fields it uses for subject resolution for that SAML issuer. The Resource Authorization Server MUST NOT resolve the subject using only the nameid value unless local policy explicitly defines nameid alone as the subject identifier for that SAML issuer. In particular, when the SAML Assertion Subject <NameID> is scoped to a Service Provider, the sp_name_qualifier value is part of the subject namespace. If the Resource Authorization Server requires a SAML NameID Subject Identifier for subject resolution, it MUST reject the token request with an invalid_grant error as defined in if any of the following is true:

the ID-JAG does not contain a sub_id claim using the SAML NameID Subject Identifier Format;
the sub_id claim is malformed or uses a Subject Identifier Format that the Resource Authorization Server does not support;
the sub_id claim is not authorized by local policy for the validated ID-JAG issuer.

See and for security considerations on the sub_id claim.

Cross-Domain Access

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.

Role	App URL	Tenant URL	Description
Client	`https://wiki.example`	`https://acme.wiki.example`	Wiki app that embeds content from one or more resource servers
Resource Authorization Server	`https://chat.example`	`https://acme.chat.example`	Authorization Server for a chat and communication app
Identity Provider Authorization Server	`https://idp.example`	`https://acme.idp.example`	Enterprise Identity Provider
Resource Server	`https://api.chat.example`	`https://api.chat.example`	Public API for the chat and communications app

Sequence Diagram | | | | 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 | | | ------------------------------------------------------> | | | | | | | | | | | | | ]]>

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
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
Client exchanges the Identity Assertion JWT Authorization Grant for an Access Token at the Resource Authorization Server's token endpoint
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.

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 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 . Note: The IdP Authorization Server may enforce security controls such as multi-factor authentication before granting the user access to the Client.

Token Exchange The Client makes a Token Exchange 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 . 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 . Resource identifiers are compared using Simple String Comparison (). A Client that discovered the Resource Authorization Server using Protected Resource Metadata MUST include the resource value from that metadata unchanged ().
scope:: OPTIONAL - The space-separated list of scopes at the Resource Server that is being requested. As in , 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 ).
authorization_details:: OPTIONAL - A JSON string containing a JSON array of authorization detail objects as defined in . 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 , 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 .
actor_token_type:: REQUIRED when actor_token is present, as described in - An identifier, as described in , 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 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 . 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: 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: and: 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: 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. defines password-based authentication of the client (client_id and client_secret), however, client authentication is extensible and other mechanisms are possible. For example, defines client authentication using bearer JSON Web Tokens using client_assertion and client_assertion_type.

Example: Token Exchange using ID Token This example uses an ID Token as the subject_token and a JWT Bearer Assertion for client authentication (tokens truncated for brevity):

Example: Token Exchange using Refresh Token This non-normative example shows using a Refresh Token as the subject_token (when supported by the IdP Authorization Server) to obtain an ID-JAG without acquiring a new Identity Assertion:

Processing Rules The IdP MUST authenticate the Client, and MUST reject a request without client authentication with invalid_client (). The IdP MUST validate the subject token:

The IdP MUST determine that the subject_token is in fact a token of the type indicated by subject_token_type, and that the IdP issued it for that purpose. A token that the IdP issued for a different purpose, such as an access token, an ID-JAG, or a client assertion, MUST NOT be accepted as an Identity Assertion.
If the subject token is an Identity Assertion, the IdP MUST validate the assertion and MUST validate that the audience of the assertion (e.g. the aud claim of the ID Token or SAML Audience) matches the client_id of the client authentication of the request.
If the subject token is a Refresh Token, the IdP MUST validate it the same way it would for a standard refresh_token grant at the token endpoint: the token is issued by the IdP, bound to the authenticated client, unexpired, not revoked, and not restricted by the IdP from the requested audience, resources, or scopes. The scope comparison in applies only when audience identifies the IdP Authorization Server itself (). For any other Authorization Server, the requested scope and authorization_details have that server's meaning (), not the IdP's, so the IdP evaluates them by policy as for any other Token Exchange request.
If the subject token is a Refresh Token, the IdP Authorization Server SHOULD retrieve or assemble the subject's claims needed for the ID-JAG in the same way it would when issuing a new Identity Assertion during a token request, so that the resulting ID-JAG reflects current subject attributes and policy.

Determining that a JWT is an ID Token requires care, because OpenID Connect Core does not define an explicit typ header value for ID Tokens, so an ID Token cannot be positively identified from its header alone. The IdP MUST reject the request if the subject_token carries a typ header that identifies a different type of token, such as the access token type defined in or the ID-JAG type defined in . Because the IdP issued the subject_token itself, this determination is made entirely within the IdP's own trust domain and does not depend on interoperable agreement with any other party, so the IdP MAY use deployment-specific means to positively identify the token as an ID Token, such as a claim that the IdP includes in the ID Tokens it issues, a signing key or key set reserved for ID Tokens, or an internal record of the type of each token it issued. Explicit typing of JWTs, as recommended in , avoids this ambiguity where an explicit type is defined. For a SAML 2.0 Assertion, the IdP MUST likewise confirm that the assertion is one it issued as an authentication assertion for the subject, and not a SAML assertion or protocol message it issued for a different purpose. If an actor_token is present, any processing of it is outside the scope of this specification. Future profiles or extensions MAY define validation requirements, policy evaluation rules, and issued token content related to actor_token. The IdP Authorization Server evaluates administrator-defined policy for the token exchange request and determines if the client should be granted access to act on behalf of the subject for the target audience, resources, scopes, and authorization details. If the request contains more than one audience value, the IdP MUST respond with invalid_request. If audience does not identify a Resource Authorization Server with which the IdP has a trust relationship, the IdP MUST respond with invalid_target (). When processing the request:

If resource is present, the IdP MUST process it as defined in and MAY grant a subset of the requested resources based on policy. The IdP SHOULD respond with invalid_target () if any requested resource is not governed by the Resource Authorization Server identified by audience, and MUST respond with invalid_target if it grants none of them.
If resource is absent, the IdP MAY select one or more default resources governed by the Resource Authorization Server identified by audience, based on policy, client configuration, or other request context. The IdP MAY require the client to include resource; if the parameter is required and absent, the IdP MUST respond with invalid_target as defined in . If no default is selected, the issued ID-JAG is not restricted to a specific protected resource, though it remains restricted to the Resource Authorization Server identified by audience.
If scope is present, the IdP MUST process it according to and evaluate policy to determine the granted scopes. The granted scopes MAY be a subset of the requested scopes based on policy.
If authorization_details is present, the IdP MUST parse it as a JSON array and process each authorization detail object according to . The IdP evaluates policy for each authorization detail and determines which authorization details to include in the issued ID-JAG. The IdP MAY modify, filter, or omit authorization details based on policy.
If both resource and authorization_details are present, the IdP MUST process both. The IdP SHOULD ensure consistency between the resource identifiers and authorization details, as they may represent overlapping authorization requests. The IdP MAY derive resource identifiers from authorization details or vice versa, or process them independently based on policy.
If both scope and authorization_details are present, the IdP MUST process both. The IdP SHOULD ensure consistency between the scopes and authorization details, as they may represent overlapping authorization requests. The IdP MAY derive scopes from authorization details or vice versa, or process them independently based on policy.
The IdP MUST include the granted values, if any, in the resource, scope, and authorization_details claims of the issued ID-JAG, even when they differ from the requested values. Each requested resource identifier that the IdP grants MUST appear in the resource claim exactly as the Client sent it.

How the IdP learns which protected resources each Resource Authorization Server governs is out of scope for this specification. The IdP may also introspect the authentication context described in the SSO assertion to determine if step-up authentication is required.

Response If access is granted, the IdP creates a signed Identity Assertion JWT Authorization Grant () and returns it in the token exchange response defined in :

issued_token_type:: REQUIRED - urn:ietf:params:oauth:token-type:id-jag
access_token:: REQUIRED - The Identity Assertion JWT Authorization Grant. (Note: Token Exchange requires the access_token response parameter for historical reasons, even though this is not an OAuth access token.)
token_type:: REQUIRED - N_A (because this is not an OAuth access token.)
scope:: OPTIONAL if the scope of the issued token is identical to the scope requested by the client; otherwise, it is REQUIRED. Various policies in the IdP may result in different scopes being issued from the scopes the application requested.
authorization_details:: OPTIONAL - A JSON array of authorization detail objects as defined in . This parameter MUST be included if the client requested authorization details and the IdP granted authorization details that differ from what was requested, or if the IdP modified the authorization details.
expires_in:: RECOMMENDED - The lifetime in seconds of the authorization grant.
refresh_token:: OPTIONAL according to . In the context of this specification, this parameter SHOULD NOT be used.

Issued Identity Assertion JWT Authorization Grant The following is a non-normative example of the issued token

Example with Rich Authorization Requests (RAR) The following is a non-normative example demonstrating the use of Rich Authorization Requests (RAR) with ID-JAG: Token Exchange Request with authorization_details: Token Exchange Response: Issued Identity Assertion JWT Authorization Grant with authorization_details: Access Token Request: Access Token Response:

Error Response On error, the IdP Authorization Server returns an OAuth 2.0 Token Error response as defined in . Any OAuth error code MAY be returned; this specification profiles the following codes for interoperability:

invalid_request: the subject token failed validation (for example expired, malformed, audience mismatch, or a Refresh Token is expired or revoked), as required by . A Client that receives invalid_request for a request that previously succeeded can obtain a new subject token and retry.
access_denied: the subject token is valid but the Client or End-User is not authorized to obtain an ID-JAG for the target Resource Authorization Server. A re-issued subject token will not resolve the error. Remediation is defined by the IdP Authorization Server operator's app assignment, access-request, or entitlement process, such as an Identity Governance and Administration (IGA) workflow. This profile uses access_denied here rather than invalid_target (), so that the Client can tell a target it is not allowed to use from one the IdP Authorization Server does not recognize.
invalid_target: the audience does not identify a Resource Authorization Server with which the IdP Authorization Server has a trust relationship, or a requested resource is not governed by that Resource Authorization Server (). A re-issued subject token will not resolve the error; the Client needs to change the request.

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 .

grant_type:: REQUIRED - urn:ietf:params:oauth:grant-type:jwt-bearer, or urn:ietf:params:oauth:grant-type:jwt-dpop () when the ID-JAG is bound to a DPoP key ().
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 () with invalid_client (). See for the trade-off. For example:

Processing Rules All of applies, in addition to the following processing rules:

Validate the JWT typ is oauth-id-jag+jwt (per )
The Resource Authorization Server MUST reject the ID-JAG with an invalid_grant error if the iss claim does not identify an IdP Authorization Server it trusts. It SHOULD obtain that issuer's keys from the jwks_uri in the issuer's metadata (). It validates the signature as required by , accepting only the algorithms it allows for that issuer ().
If the issuer is multi-tenant, the Resource Authorization Server MUST reject the ID-JAG with an invalid_grant error unless the tenant claim is present and the Resource Authorization Server trusts iss and tenant together for the recipient tenant. The recipient tenant is identified by aud, by aud_tenant when present, or by the Resource Authorization Server's trust relationship with the issuer. If the Resource Authorization Server cannot determine the recipient tenant unambiguously, it MUST reject the ID-JAG with an invalid_grant error. It MUST resolve the subject only within the recipient tenant.
The Resource Authorization Server MUST validate the aud (audience) claim of the ID-JAG. The aud claim MUST contain the issuer identifier of the Resource Authorization Server as defined in . The aud claim MAY be a string containing a single issuer identifier, or an array containing a single issuer identifier. If the aud claim is an array, it MUST contain exactly one element, and that element MUST be the issuer identifier of the Resource Authorization Server. If the aud claim does not match the Resource Authorization Server's issuer identifier, the Resource Authorization Server MUST reject the JWT with an invalid_grant error as defined in . This validation prevents audience injection attacks and ensures the ID-JAG was intended for this specific Resource Authorization Server.
If the Client authenticates, the Resource Authorization Server MUST reject the request with an invalid_grant error unless the client_id claim identifies the authenticated client. If the Client does not authenticate, proof of possession of the key in the cnf claim () takes the place of this check, and the client_id claim identifies the Client. This client continuity check preserves the OAuth client binding across the exchange, but does not by itself identify or authenticate any actor represented in an act claim.
If the ID-JAG contains a cnf claim, the Resource Authorization Server verifies proof of possession as described in .
If the Resource Authorization Server uses the sub_id claim for subject resolution, it MUST process the claim according to the indicated Subject Identifier Format. For SAML NameID subject identifiers, the Resource Authorization Server MUST apply the processing rules in .

When processing authorization information from the ID-JAG:

If the resource claim is present, each identifier MUST be a protected resource governed by this Resource Authorization Server for the tenant identified by aud_tenant when present, otherwise for the tenant it associates with the issuing IdP (), compared as described in . If any identifier is not, the Resource Authorization Server MUST reject the request with invalid_grant as defined in , because the ID-JAG was not issued for resources it governs. The access token MUST be restricted to resources in the resource claim, and SHOULD be audience-restricted to them (). The Resource Authorization Server MAY restrict it to a subset based on local policy, and MUST reject the request with access_denied () if none of the resources are acceptable.
If the resource claim is absent, the Resource Authorization Server MAY select one or more default resources based on policy, client configuration, or other request context. It MAY require the ID-JAG to contain a resource claim; if the claim is required and absent, it MUST reject the request with invalid_grant as defined in .
If the scope claim is present, the Resource Authorization Server MUST process it according to . The Resource Authorization Server evaluates the scopes and determines which scopes to grant in the access token based on policy. The granted scopes MAY be a subset of the scopes in the ID-JAG issued by the IdP Authorization Server.
If the authorization_details claim is present, the Resource Authorization Server MUST parse it as a JSON array and process each authorization detail object according to . The Resource Authorization Server evaluates policy for each authorization detail and determines which authorization details to grant. The Resource Authorization Server MAY modify, filter, or omit authorization details based on policy.
If both resource and authorization_details claims are present, the Resource Authorization Server MUST process both. The Resource Authorization Server SHOULD ensure consistency between the resource identifiers and authorization details when issuing the access token. The Resource Authorization Server MAY derive resource identifiers from authorization details or vice versa, or process them independently based on policy. Any resource identifiers it derives MUST be among those in the resource claim.
If both scope and authorization_details claims are present, the Resource Authorization Server MUST process both. The Resource Authorization Server SHOULD ensure consistency between the scopes and authorization details when issuing the access token. The Resource Authorization Server MAY derive scopes from authorization details or vice versa, or process them independently based on policy.
The Resource Authorization Server MUST include the granted scope (if any) and authorization_details (if any) in the access token response. The response format follows for scope and for authorization_details.

Response The Resource Authorization Server's token endpoint responds with an OAuth 2.0 Token Response, e.g.:

Error Response On error, the Resource Authorization Server returns an OAuth 2.0 Token Error response as defined in . Any OAuth error code MAY be returned; this specification profiles the following two codes for interoperability:

invalid_grant: the ID-JAG failed a validation rule in (for example signature, aud, client_id, exp, typ, decryption, or cnf binding). A re-issued ID-JAG may resolve the error.
access_denied: the ID-JAG is valid but the End-User or Client is not authorized at the Resource Authorization Server (for example the End-User lacks a license, entitlement, or provisioning record, or is denied by the Resource Authorization Server's policy or role/permission assignments). A re-issued ID-JAG will not resolve the error. Remediation is defined by the Resource Authorization Server operator's access-request, entitlement, or provisioning process, such as an Identity Governance and Administration (IGA) workflow.

Refresh Token The Resource Authorization Server SHOULD NOT return a Refresh Token when an Identity Assertion JWT Authorization Grant is exchanged for an Access Token per . When the access token has expired, clients MAY re-submit the original Identity Assertion JWT Authorization Grant to obtain a new Access Token. The ID-JAG replaces the use of Refresh Token for the Resource Authorization Server. However, the Resource Authorization Server can reject an ID-JAG with an exp longer than its policy allows, or accept each ID-JAG only once by tracking its jti (). If the ID-JAG has expired, or the Resource Authorization Server rejects a re-submitted ID-JAG with an invalid_grant error, the Client SHOULD request a new ID-JAG from the IdP Authorization Server using the original Identity Assertion from the IdP (e.g ID Token) before presenting it to the Resource Authorization Server. If the Resource Authorization Server also rejects the new ID-JAG, requesting another will not resolve the error. If the ID Token is expired, the Client MAY use the Refresh Token obtained from the IdP during SSO to obtain a new ID Token which it can exchange for a new ID-JAG. If the Client is unable to obtain a new Identity Assertion with a Refresh Token then it SHOULD re-authenticate the user by redirecting to the IdP. If the IdP Authorization Server supports Refresh Tokens as a subject_token in Token Exchange, the client can skip renewing the Identity Assertion and directly request a new ID-JAG by presenting the Refresh Token (see ).

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. https://idp.example.com/ alice@example.com https://client.example.com/sp-entity-id Alice urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport ]]> 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.

Cross-Domain Client and Subject Identifier Handling There are three separate OAuth/OpenID Connect/SAML relationships involved in this flow:

Client to IdP Authorization Server (OpenID Connect or SAML)
Client to Resource Authorization Server (OAuth)
Resource Authorization Server to IdP Authorization Server (OpenID Connect or SAML)

Each relationship is typically represented by independent client registrations between each party. For example, the IdP Authorization Server typically issues a Client ID for both the Client and Resource Authorization Server to use for single sign-on with OpenID Connect as a Relying Party. Similarly, the Resource Authorization Server typically issues a Client ID for the Client to use for API access to the Resource Server. The Client may choose to use different client credentials with each registration.

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

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

Tenant Relationships with Issuer and Client ID In multi-tenant deployments, the relationship between tenants, issuers, and client identifiers is critical for proper identity and authorization management. This section explains how these components relate to each other in the context of Identity Assertion JWT Authorization Grants.

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.

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

Subject Identifier Uniqueness with Tenants As specified in , 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.

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 (), sub (), and aud_sub for that tenant.

Authorization Server Metadata There are two complementary metadata parameters that can be used by the two different authorization servers. identity_chaining_requested_token_types_supported indicates which token types an IdP Authorization Server can issue for identity chaining, while authorization_grant_profiles_supported indicates which authorization grant profiles a Resource Authorization Server can process.

IdP Authorization Server Metadata An IdP Authorization Server can advertise the identity chaining token types it can issue in its OAuth Authorization Server Metadata . Identity and Authorization Chaining Across Domains 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 . A Resource Authorization Server that cannot retrieve metadata from that location MAY fall back to Section 4 of , as described in . 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 does not describe ID-JAGs, which the IdP Authorization Server can sign differently from ID Tokens.

Resource Authorization Server Metadata A Resource Authorization Server can advertise support for authorization grant profiles in its OAuth Authorization Server Metadata 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.

Client Metadata A client can advertise support for authorization grant profiles in its client metadata using the authorization_grant_profiles_supported parameter. This parameter MAY be registered via OAuth 2.0 Dynamic Client Registration or published in a Client ID Metadata Document . The value of authorization_grant_profiles_supported MUST be a JSON array of strings. Each string MUST identify an authorization grant profile that the client implements. Inclusion of a profile identifier in authorization_grant_profiles_supported indicates only that the client implements the processing rules for that profile. It does not indicate that any particular IdP Authorization Server, Resource Authorization Server, audience, resource, or scope will be requested. To advertise support for the Identity Assertion JWT Authorization Grant profile, the client SHOULD include the following value in the authorization_grant_profiles_supported property: urn:ietf:params:oauth:grant-profile:id-jag A client that includes urn:ietf:params:oauth:grant-profile:id-jag in authorization_grant_profiles_supported for this specification MUST also include both urn:ietf:params:oauth:grant-type:token-exchange and urn:ietf:params:oauth:grant-type:jwt-bearer in its grant_types, since the client uses Token Exchange to obtain the ID-JAG from the IdP Authorization Server and the JWT Bearer Token grant to redeem it at the Resource Authorization Server.

Security Considerations

Client Authentication The IdP Authorization Server always authenticates the Client (). The Resource Authorization Server usually does too, but it can instead accept a sender-constrained ID-JAG from a Client that does not authenticate (). 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.

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

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

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.

Authorization Server Metadata Validation Clients that discover an Authorization Server's metadata using OAuth 2.0 Authorization Server Metadata 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 . 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 is the primary defense. When the client has validated the attacker's Protected Resource Metadata () and includes its resource value (), 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 (). An IdP that checks which resources that Resource Authorization Server governs () rejects the Token Exchange request instead, so the ID-JAG never reaches the attacker. A sender-constrained ID-JAG () also defeats the relay, because the attacker cannot prove possession of the client's key.

Protected Resource Metadata Validation Clients that discover the Resource Authorization Server for a protected resource via Protected Resource Metadata MUST validate that metadata as required by , 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 , this validation binds discovery to the resource the client intended to access, and including the validated resource value in the Token Exchange request () binds the grant to it.

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.

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.

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

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.

Sender Constraining Tokens Identity Assertion JWT Authorization Grant may support key binding to enable sender-constrained tokens as described in and . 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 (): binding via a DPoP proof JWT as defined by . The cnf claim carries a jkt property with the JWK SHA-256 Thumbprint of the bound key.
mTLS Certificate Binding (): binding via a mutually authenticated TLS session using an X.509 client certificate as defined by . 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 , 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).

DPoP Key Binding DPoP key binding is demonstrated by the client presenting a DPoP proof JWT (as defined in ) in a DPoP HTTP header. The DPoP proof demonstrates that the client possesses the private key corresponding to a public key. This public key can be bound to tokens, ensuring that only the holder of the private key can use those tokens. When an ID-JAG contains a cnf claim with a jkt property as defined in , it indicates that the ID-JAG is bound to that specific key (identified by its JWK SHA-256 Thumbprint), and proof of possession of the corresponding private key MUST be demonstrated when using the ID-JAG.

DPoP Key Binding During Token Exchange When a client requests an ID-JAG from the IdP Authorization Server via Token Exchange, the client MAY include a DPoP proof in the request. This demonstrates possession of a key that can be bound to the ID-JAG. The client generates a key pair and includes a DPoP proof JWT in the DPoP header of the Token Exchange request: The IdP Authorization Server processes the request as follows:

If a DPoP proof is present, the IdP MUST validate it according to . The htm claim MUST be POST, and the htu claim MUST match the token endpoint URL.
If the DPoP proof is valid, the IdP MUST include a cnf claim in the issued ID-JAG containing a jkt property with the JWK SHA-256 Thumbprint computed from the DPoP proof's jwk header parameter as defined in , unless it binds the ID-JAG to the client's X.509 certificate instead (). This enables the Resource Authorization Server to validate the key binding for the ID-JAG using simple string comparison of the JWK SHA-256 Thumbprint.

The cnf claim format follows :

The token exchange response does not explicitly indicate whether key binding was successfully performed by the IdP. The token_type response parameter for an ID-JAG is always N_A per . The client SHOULD inspect the ID-JAG to determine if a cnf claim is present and whether it represents the same key as the DPoP proof. This enables the client to detect if the IdP successfully processed the DPoP proof in the token exchange request and bound the issued ID-JAG, preventing the IdP from silently ignoring the DPoP proof and mitigating downgrade attacks.
If no DPoP proof is presented, the IdP issues an ID-JAG without a cnf claim.

DPoP Key Binding During ID-JAG Exchange When a client exchanges an ID-JAG for an access token at the Resource Authorization Server, the processing rules depend on whether the ID-JAG contains a cnf claim and whether the client presents a DPoP proof.

ID-JAG Contains cnf Claim and DPoP Proof is Presented If the ID-JAG contains a cnf claim and the client presents a DPoP proof, the Resource Authorization Server MUST:

Validate the DPoP proof according to .
Extract the JWK SHA-256 Thumbprint from the DPoP proof by computing the thumbprint of the jwk header parameter in the DPoP proof according to .
Extract the JWK SHA-256 Thumbprint from the jkt property of the cnf claim in the ID-JAG.
Compare the two thumbprints. They MUST match exactly. If they do not match, the request MUST fail with an invalid_grant error.
If the thumbprints match, the Resource Authorization Server MAY issue a sender-constrained access token (e.g., a DPoP-bound token) per the Resource Server configuration. The issued access token SHOULD be bound to the same key.

Example request: Example successful response with DPoP-bound token:

ID-JAG Contains cnf Claim but DPoP Proof is Not Presented If the ID-JAG contains a cnf claim but the client does not present a DPoP proof, the Resource Authorization Server MUST reject the request with an invalid_grant error, as the ID-JAG requires proof of possession. Example error response:

ID-JAG Does Not Contain cnf Claim and DPoP Proof is Presented If the ID-JAG does not contain a cnf claim but the client presents a DPoP proof, the Resource Authorization Server:

MUST validate the DPoP proof according to .
MAY issue a sender-constrained access token (e.g., a DPoP-bound token) per the Resource Server configuration at the Authorization Server, binding the access token to the key demonstrated in the DPoP proof.
The access token response will indicate the token type (e.g., DPoP for DPoP-bound tokens, or Bearer for unconstrained tokens).

ID-JAG Does Not Contain cnf Claim and DPoP Proof is Not Presented If the ID-JAG does not contain a cnf claim and the client does not present a DPoP proof:

The Resource Authorization Server MAY issue an unconstrained Bearer token.
However, if the Resource Server configuration at the Authorization Server requires constrained tokens for that Resource Server, the request MUST fail with an invalid_grant error.

Example error response when constrained tokens are required:

mTLS Certificate Binding An IdP MAY bind an ID-JAG to a client's X.509 certificate per . When bound, the cnf claim carries an x5t#S256 property containing the SHA-256 thumbprint of the DER encoding of the certificate, as defined by . The certificate used for binding is the certificate the client presents during the mutually authenticated TLS handshake, validated per . Because TLS exposes a single client certificate per connection, the binding certificate and the client-authentication certificate are the same certificate.

mTLS Certificate Binding During Token Exchange When the client presents an X.509 client certificate on the mTLS session to the IdP token endpoint and local policy permits certificate-bound issuance, the IdP validates the certificate per and includes an x5t#S256 cnf claim in the issued ID-JAG per : The token_type response parameter for an ID-JAG is always N_A per . The client SHOULD verify that the returned ID-JAG contains an x5t#S256 cnf claim matching the certificate it presented, to detect a silent downgrade. If no client certificate is presented (or is not accepted for binding), the IdP issues an ID-JAG without an x5t#S256 cnf claim.

mTLS Certificate Binding During ID-JAG Exchange When the client exchanges the ID-JAG at the Resource Authorization Server, processing depends on whether the ID-JAG contains an x5t#S256 cnf claim and whether the client establishes an mTLS session:

cnf.x5t#S256 present and mTLS certificate presented: The Resource Authorization Server MUST validate the certificate per , compute its SHA-256 thumbprint per , and compare against cnf.x5t#S256. Mismatch MUST fail with invalid_grant. On match, the Resource Authorization Server MAY issue a certificate-bound access token per .
cnf.x5t#S256 present, no mTLS certificate: MUST fail with invalid_grant.
No cnf.x5t#S256, mTLS certificate presented: The Resource Authorization Server MAY validate the certificate per and issue a certificate-bound access token per .
No cnf.x5t#S256, no mTLS certificate: The Resource Authorization Server MAY issue an unconstrained Bearer token; if Resource Server configuration requires sender-constrained tokens, MUST fail with invalid_grant.

Example request (mTLS session established at the TLS layer) and successful response with a certificate-bound access token:

Privacy Considerations The privacy considerations of , , and also apply to this specification. Disclosure of subject identifiers to the Client is covered in , and disclosure of trust relationships in metadata in . The IdP Authorization Server learns which Clients access which Resource Authorization Servers for which End-Users, and when, including access that happens without the End-User present. It should keep the records described in only as long as security and audit require, and should let End-Users or administrators see and revoke cross-app access. The Client can read the ID-JAG, including claims it would not receive in its own ID Token, such as a pairwise sub or aud_sub, and can link them across Resource Authorization Servers. The IdP Authorization Server SHOULD include only the claims the Resource Authorization Server needs. A Resource Authorization Server that provisions accounts from ID-JAGs () can create accounts for End-Users who never used it directly, and should retain only the attributes it needs. Error descriptions SHOULD NOT disclose more about the End-User than the error code conveys, such as whether the End-User holds a license for the application.

IANA Considerations

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

OAuth URI Registration This section registers urn:ietf:params:oauth:token-type:id-jag in the "OAuth URI" subregistry of the "OAuth Parameters" registry .

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 .

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

OAuth Authorization Server Metadata Registration This section registers the following in the "OAuth Authorization Server Metadata" registry of the "OAuth Parameters" registry .

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

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 , established by .

Metadata Name: authorization_grant_profiles_supported
Metadata Description: JSON array of authorization grant profile identifiers supported by the client
Change Controller: IETF
Specification Document:

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 . The "JSON Web Token Claims" subregistry was established by .

Claim Name: resource
Claim Description: Resource
Change Controller: IETF
Specification Document(s):
Claim Name: aud_tenant
Claim Description: Resource Authorization Server tenant identifier
Change Controller: IETF
Specification Document(s):

Security Event Identifier Format Registration This section registers the saml-nameid Subject Identifier Format in the "Security Event Identifier Formats" registry established by .

Format Name: saml-nameid
Format Description: SAML NameID Subject Identifier Format
Change Controller: IETF
Reference:

References Normative References The OAuth 2.0 Authorization Framework The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] JSON Web Token (JWT) JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. JSON Web Algorithms (JWA) This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. OAuth 2.0 Token Exchange This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. Resource Indicators for OAuth 2.0 This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. JSON Web Token Best Current Practices JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. JSON Web Key (JWK) Thumbprint This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. OAuth 2.0 Demonstrating Proof of Possession (DPoP) This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. OAuth 2.0 Rich Authorization Requests This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. Subject Identifiers for Security Event Tokens Security events communicated within Security Event Tokens may support a variety of identifiers to identify subjects related to the event. This specification formalizes the notion of Subject Identifiers as structured information that describes a subject and named formats that define the syntax and semantics for encoding Subject Identifiers as JSON objects. It also establishes a registry for defining and allocating names for such formats as well as the JSON Web Token (JWT) "sub_id" Claim. OAuth 2.0 Dynamic Client Registration Protocol This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. OAuth Identity and Authorization Chaining Across Domains Defakto Security Defakto Security MITRE NSA-CCSS Ping Identity Okta This specification describes a mechanism for preserving identity and authorization information across trust domains that use the OAuth 2.0 Framework. A JSON Web Token (JWT) authorization grant, obtained through an intra-domain OAuth 2.0 Token Exchange, facilitates the cross-domain acquisition of an access token. The relevant identity and authorization information is chained throughout the flow by being conveyed in the respective artifacts exchanged at each step of the process. Chaining across multiple domains is achieved by using the same protocol every time a trust domain boundary is crossed. Media Types IANA OAuth Parameters IANA JSON Web Token (JWT) IANA Media Type Specifications and Registration Procedures This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK] OAuth 2.0 Authorization Server Metadata This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. Uniform Resource Identifier (URI): Generic Syntax A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] OAuth 2.0 Protected Resource Metadata This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. OAuth 2.0 JWT Authorization Grant with DPoP Binding Okta This specification defines a new OAuth 2.0 authorization grant type for exchanging a JSON Web Token (JWT) assertion that is bound to a key for an access token. To use the assertion, the client must prove possession of that key using the Demonstrating Proof of Possession (DPoP) mechanism. Unlike the JWT bearer grant, a stolen assertion cannot be used by a party that does not hold the private key. OpenID Connect Core 1.0 incorporating errata set 2 OpenID Connect Discovery 1.0 incorporating errata set 2 OpenID Connect Enterprise Extensions 1.0 - draft 01 Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0 Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. OAuth 2.0 Step Up Authentication Challenge Protocol It is not uncommon for resource servers to require different authentication strengths or recentness according to the characteristics of a request. This document introduces a mechanism that resource servers can use to signal to a client that the authentication event associated with the access token of the current request does not meet its authentication requirements and, further, how to meet them. This document also codifies a mechanism for a client to request that an authorization server achieve a specific authentication strength or recentness when processing an authorization request. OAuth Client ID Metadata Document Okta This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata, enabling the authorization server to fetch the metadata about the client as needed.

Use Cases The following use cases are illustrative and not exhaustive. Enterprise workforce identity is a common deployment context, but this profile can also apply where the IdP Authorization Server trusted by the Resource Authorization Server for SSO and subject resolution is a CIAM layer, platform identity system, or other application-domain identity provider.

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.

Preconditions

The Client has a registered OAuth 2.0 Client with the IdP Authorization Server
The Client has a registered OAuth 2.0 Client with the Resource Authorization Server
Enterprise has established a trust relationship between their IdP and the Client for SSO and Identity Assertion JWT Authorization Grant
Enterprise has established a trust relationship between their IdP and the Resource Authorization Server for SSO and Identity Assertion JWT Authorization Grant
Enterprise has granted the Client permission to act on behalf of users for the Resource Authorization Server with a set of scopes

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.

Preconditions

Deployment and Client Preconditions

The first-party application has a registered OAuth 2.0 Client with the CIAM IdP Authorization Server
The first-party application has a registered OAuth 2.0 Client with the Resource Authorization Server for the developer SaaS component
The Resource Authorization Server is able to map the customer identity conveyed by the CIAM platform to the corresponding account, tenant, or subject established through JIT provisioning at the developer SaaS component

Trust Relationship Preconditions

The organization operating the customer application has established a trust relationship between its CIAM platform and the first-party application for customer sign-in and issuance of identity assertions
The organization operating the customer application and the developer SaaS provider have established a trust relationship between the CIAM platform and the Resource Authorization Server for Identity Assertion JWT Authorization Grant
The organization operating the customer application has granted the first-party application permission to act on behalf of signed-in customers for the developer SaaS component with a defined set of scopes

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.

Preconditions

The Client does not have a pre-registered OAuth 2.0 client at the IdP Authorization Server or the Resource Authorization Server
The Client identifies itself at both with a Client ID Metadata Document that publishes its public keys, and authenticates in the Token Exchange request with the corresponding private key (), for example using private_key_jwt
The Client has obtained an Identity Assertion (e.g. ID Token) from the IdP Authorization Server
The Resource Authorization Server accepts clients identified by a Client ID Metadata Document, and either authenticates the Client the same way or accepts a sender-constrained ID-JAG ()

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.

Preconditions

Deployment and Client Preconditions

The Enterprise IdP at idp.cyberdyne-corp.example authenticates the enterprise's users, issues identity assertions, and is the IdP Authorization Server trusted by the External Tool Resource Authorization Server for SSO and subject resolution for this hop
The External Tool API (resource server) at api.saas-tool.example and its authorization server at authorization-server.saas-tool.example are operated by a SaaS tool vendor, in a different trust domain from the enterprise IdP
The AI Agent is an OAuth 2.0 client with client ID https://ai-agent-app.example/
The Enterprise IdP (idp.cyberdyne-corp.example) recognizes the AI Agent (https://ai-agent-app.example/) as a trusted client, either through static registration or dynamic discovery via
The External Tool Resource Authorization Server (authorization-server.saas-tool.example) recognizes the AI Agent (https://ai-agent-app.example/) as a trusted client, either through static registration or dynamic discovery via

Note: This example uses a URL as the client ID, following the Client Identity Metadata Document pattern to allow servers to dynamically discover client metadata. Alternatively, clients may be statically registered at the IdP and authorization server and given static opaque client IDs, with metadata configured directly in the IdP and Authorization Server.

Trust Relationship Preconditions

The enterprise has established a trust relationship between their IdP (idp.cyberdyne-corp.example) and the AI Agent for SSO
The enterprise has established a trust relationship between their IdP (idp.cyberdyne-corp.example) and the External Tool Resource Authorization Server (authorization-server.saas-tool.example) for SSO and Identity Assertion JWT Authorization Grant
The enterprise has granted the AI Agent permission to act on behalf of users for the External Tool Resource Authorization Server with a specific set of scopes

Example Sequence The steps below describe the sequence of the AI Agent obtaining an access token using an Identity Assertion JWT Authorization Grant ().

AI Agent establishes a User Identity with Enterprise IdP AI Agent (https://ai-agent-app.example/) discovers the Enterprise IdP's (idp.cyberdyne-corp.example) OpenID Connect Provider configuration based on a configured issuer that was previously established.

Note: IdP discovery where an agent discovers which IdP the agent should use to authenticate a given user is out of scope of this specification.

AI Agent discovers all necessary endpoints for authentication as well as support for the identity chaining requested token type urn:ietf:params:oauth:token-type:id-jag

IdP Authorization Request (with PKCE) AI Agent (https://ai-agent-app.example/) generates a PKCE code_verifier and a code_challenge (usually a SHA256 hash of the verifier, base64url-encoded) and redirects the end-user to the Enterprise IdP (idp.cyberdyne-corp.example) with an authorization request

User authenticates and authorizes AI Agent Enterprise IdP (idp.cyberdyne-corp.example) authenticates the end-user and redirects back to the AI Agent's registered redirect URI with an authorization code: AI Agent (https://ai-agent-app.example/) exchanges the code and PKCE code_verifier to obtain an ID Token and Access Token for the IdP's UserInfo endpoint AI Agent validates the ID Token using the published JWKS for the Enterprise IdP (idp.cyberdyne-corp.example) AI Agent now has an identity binding for context

AI Agent calls External Tool AI Agent (https://ai-agent-app.example/) calls the External Tool API (Resource Server) at api.saas-tool.example without a valid access token and is issued an authentication challenge per Protected Resource Metadata .

Note: How agents discover available external tools is out of scope of this specification

AI Agent fetches the External Tool API's OAuth 2.0 Protected Resource Metadata per to dynamically discover an authorization server that can issue an access token for the resource. AI Agent discovers the External Tool Resource Authorization Server (authorization-server.saas-tool.example) configuration per AI Agent has learned all necessary endpoints and supported capabilities to obtain an access token for the external tool. If the urn:ietf:params:oauth:grant-profile:id-jag authorization grant profile is supported, the AI Agent can first attempt to silently obtain an access token using an Identity Assertion JWT Authorization Grant from the IdP Authorization Server trusted by the External Tool Resource Authorization Server for SSO, otherwise it can fallback to interactively obtaining a standard authorization_code from the External Tool Resource Authorization Server.

AI Agent obtains an Identity Assertion JWT Authorization Grant for External Tool from the Enterprise IdP AI Agent (https://ai-agent-app.example/) makes an Identity Assertion JWT Authorization Grant Token Exchange request to the Enterprise IdP (idp.cyberdyne-corp.example) using the ID Token obtained when establishing an identity binding context, along with scopes and the resource identifier for the External Tool API (api.saas-tool.example) that was returned in the external tool's OAuth 2.0 Protected Resource Metadata If access is granted, the Enterprise IdP (idp.cyberdyne-corp.example) creates a signed Identity Assertion JWT Authorization Grant and returns it in the token exchange response defined in : Identity Assertion JWT Authorization Grant claims:

AI Agent obtains an Access Token for External Tool AI Agent (https://ai-agent-app.example/) makes a token request to the External Tool Resource Authorization Server (authorization-server.saas-tool.example) token endpoint using the Identity Assertion JWT Authorization Grant obtained from the Enterprise IdP (idp.cyberdyne-corp.example) as a JWT Assertion as defined by .

Note: How the AI Agent registers with the External Tool Resource Authorization Server (e.g static or dynamic client registration), and whether or not it has credentials, is out-of-scope of this specification

External Tool Resource Authorization Server (authorization-server.saas-tool.example) validates the Identity Assertion JWT Authorization Grant using the published JWKS for the trusted Enterprise IdP (idp.cyberdyne-corp.example)

AI Agent makes an authorized External Tool request AI Agent (https://ai-agent-app.example/) calls the External Tool API (Resource Server) at api.saas-tool.example with a valid access token

Acknowledgments The authors would like to thank the following people for their contributions and reviews of this specification: Kamron Batmanghelich, Paul Carleton, Sofia Desenberg, Meghna Dubey, George Fletcher, Bingrong He, Pieter Kasselman, Aaron Jeongwoo Kim, Kai Lehmann, David Lozano, Kaixuan Luo, Ken McCracken, Anuj Mistry, Dean H. Saxe, Kenneth Sinder, Filip Skokan, Phil Whipps.

Document History [[ To be removed from the final specification ]] -06

Changed the IdP Authorization Server error for a subject token that fails validation from invalid_grant to invalid_request, as required by Section 2.2.2 of RFC 8693
Explained why access_denied is used rather than invalid_target when the Client or End-User is not authorized for the target

-05

Added invalid_target handling and resource governance checks for the resource parameter and claim
Added security considerations on Authorization Server and Protected Resource Metadata validation
Added mTLS certificate binding as an alternative sender-constraining mechanism for the ID-JAG, alongside DPoP
Added security considerations on storage and caching of subject tokens (ID Token, SAML Assertion, Refresh Token)
Added requirement that the IdP confirm the subject token is actually a token of the indicated type
Allowed an IdP to accept ID-JAGs it issued itself when explicitly configured
Profiled access_denied alongside invalid_grant for authorization failures at the IdP and Resource Authorization Server
Clarified SAML NameID stability and scope assumptions, and resolution of users by attributes other than NameID
Clarified the subjects whose claims the ID-JAG conveys (End-User, client, and actor)
Clarified that sub is selected for the Resource Authorization Server, and added a Subject Identifier Mapping section
Clarified that Token Exchange scope values are not OpenID Connect scopes
Specified how the Resource Authorization Server finds and validates ID-JAG signing keys
Added id_jag_signing_alg_values_supported IdP metadata parameter
Specified that IdP metadata is located per RFC 8414
Clarified ID-JAG reuse limits and when the Client should request a new ID-JAG
Required the IdP to authenticate the Client in the Token Exchange request
Limited the Token Exchange request to a single audience value, and profiled invalid_target for an unrecognized audience or a resource not governed by it
Defined resource identifier comparison, made the IdP resource governance check a SHOULD, and required the access token to be restricted to the resources in the ID-JAG resource claim
Moved RFC 9728 to normative references
Clarified how the IdP validates a Refresh Token used as the subject token, and when the RFC 6749 scope comparison applies
Required the jwt-dpop grant type for DPoP-bound ID-JAGs, and required the Resource Authorization Server to reject an ID-JAG with an unsupported cnf confirmation method
Allowed a key-bound ID-JAG to be used in place of client authentication at the Resource Authorization Server
Fixed the tenant claims used in the client ID and subject identifier uniqueness rules
Added a tenant context check at the Resource Authorization Server
Added Privacy Considerations
Updated the email and calendaring use case to use a Client ID Metadata Document
Fixed examples (RS256 signatures, Cache-Control headers, mTLS client_id, consistent iss and exp values)
Corrected cited section numbers, removed citations from the abstract, and removed an unused reference
Editorial clarifications and typo fixes

-04

Clarified XAA vs ID-JAG terminology in abstract and intro
Added compatibility via new sub_id claim for Resource Apps configured with SAML SSO, and tightened definition of sub
Added client metadata property for DCR and CIMD
Clarified cross-domain use restriction

-03

Added a section defining terms used in the document
Updated language to be less specific to "enterprise" and more about the relationships between the IdP and Resource Authorization Server
Clarified the use of the resource and audience parameters in the token exchange request
Removed language discouraging the use of the actor_token in the token exchange request
Added a new AS metadata parameter authorization_grant_profiles_supported to enable a Resource Authorization Server to publish support for this profile

-02

Added reference and examples of a RAR authorization_details object in the Token Exchange and ID-JAG
Added refresh token as an optional subject token input to the Token Exchange for SAML interop
Described how to use DPoP with the ID-JAG exchange
Added aud_tenant and aud_sub claims to ID-JAG to support multi-tenant systems

-01

Moved ID-JAG definition to document root instead of nested under Token Exchange
Added proposed OpenID Connect tenant claim
Added authentication claims from ID Token
Adopted standard OAuth 2.0 role names instead of Resource App or Resource App's Authorization Server
Updated sequence diagram
Updated all inconsistent references of ID-JAG to "Identity Assertion JWT Authorization Grant"
Updated section references with more specific links
Added reference to scope parameter in ID-JAG processing rules
Added a section discussing client ID mapping and reference to Client ID Metadata Document
Added recommendations for refresh tokens

-00

Initial revision as adopted working group draft