]> 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 a common enterprise identity provider using Token Exchange and JWT Profile for OAuth 2.0 Authorization Grants . 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 typical enterprise scenarios, applications are configured for single sign-on to the enterprise identity provider (IdP) using OpenID Connect or SAML. This enables users to access all the necessary enterprise applications using a single account at the IdP, and enables the enterprise to manage which users can access which applications. 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 enables this kind of "Cross App Access" to be managed by the enterprise IdP, similar to how the IdP manages single sign-on to individual applications. The draft specification Identity Chaining Across Trust Domains defines how to request a JWT authorization grant from an Authorization Server and exchange it for an Access Token at another Authorization Server in a different trust domain. The specification combines OAuth 2.0 Token Exchange and JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants . The draft supports multiple different use cases by leaving many details of the token exchange request and JWT authorization grant unspecified. This specification defines the additional details necessary to support interoperable implementations in enterprise scenarios when two applications are configured for single sign-on to the same enterprise identity provider. In particular, this specification uses identity assertions as the input to the token exchange request. This way, the same enterprise identity provider that is trusted by applications for single sign-on can be extended to broker access to APIs.

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. This is also sometimes referred to as the "Requesting Application".

Resource Application

The application that provides an OAuth 2.0 Protected Resource. In , this is the Protected Resource in trust domain B. The Resource Application is made up of both an Authorization Server and a Resource Server as defined in .

Authorization Server (IdP)

The Identity Provider that is trusted by a set of applications in an organization's app ecosystem. In , this is the Authorization Server in trust domain A, which is also trusted by the Authorization Server of the Protected Resource in trust domain B.

Overview The example flow is for an enterprise acme, which uses a wiki app and chat app from different vendors, both of which are integrated into the enterprise's Identity Provider using OpenID Connect.

Role	App URL	Tenant URL	Description
Client	https://wiki.example	https://acme.wiki.example	Wiki app that embeds content from one or more resource applications
Resource Application	https://chat.example	https://acme.chat.example	Chat and communication app
Identity Provider	https://idp.example	https://acme.idp.example	Identity Provider

Sequence Diagram | | | | 1 User SSO | | | | | | | | ID Token | | | | <- - - - - - - - | | | | | | | | | | | | | | | | 2 Token Exchange | | | | ----------------> | | | | | | | | ID-JAG | | | | <- - - - - - - - | | | | | | | | | | | | | | | | 3 Present ID-JAG | | | | ------------------+----------------> | | | | | | | Access Token | | | | <- - - - - - - - - - - - - - - - - - | | | | | | | | | | | | | | | 4 Resource Request with Access Token| | | -----------------------------------------------------> | | | | | | | | | | | | | ]]>

1. User logs in to the Client, the Client obtains the Identity Assertion (e.g. OpenID Connect ID Token or SAML assertion)
2. Client uses the Identity Assertion to request an Identity Assertion Authorization Grant for the Resource Application from the IdP
3. Client exchanges the Identity Assertion Authorization Grant JWT for an Access Token at the Resource Application's token endpoint
4. Client makes an API request with the Access Token

This specification is constrained to deployments where all Resource Application Resource Servers are leveraging the same IdP Authorization Server for Single-Sign-On (SSO) and session management services. The IdP provides a consistent trust boundary enabling the set of Resource Application Authorization Servers to honor the JWT Authorization Grant (ID-JAG) issued by the IdP. This specification also assumes that the Resource Server Authorization Servers delegate user authorization authority to the IdP (e.g. the IdP is trusted to ensure the scopes identified in the ID-JAG have been correctly authorized before issuing the ID-JAG token).

User Authentication The Client initiates an authentication request with the IdP 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. Note: The Enterprise IdP 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's Token Endpoint with the following parameters:

requested_token_type:

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

audience:

REQUIRED - The Issuer URL of the Resource Application's authorization server as defined in .

resource:

OPTIONAL - The Resource Identifier of the Resource Application's resource server as defined in .

scope:

OPTIONAL - The space-separated list of scopes at the Resource Application that is being requested.

subject_token:

REQUIRED - The identity assertion (e.g. the OpenID Connect ID Token or SAML assertion) for the target end-user.

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, or for a SAML assertion: urn:ietf:params:oauth:token-type:saml2.

The additional parameters defined in actor_token and actor_token_type are not used in this specification. Client authentication to the 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. The example below uses an ID Token as the Identity Assertion, and uses a JWT Bearer Assertion () as the client authentication method, (tokens truncated for brevity):

Processing Rules The IdP MUST validate the subject token, and MUST validate that the audience of the Subject Token (e.g. the aud claim of the ID Token) matches the client_id of the client authentication of the request. The IdP 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 and scopes. 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 Authorization Grant JWT and returns it in the token exchange response defined in Section 2.2 of :

issued_token_type:

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

access_token:

REQUIRED - The Identity Assertion Authorization Grant JWT. (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.

expires_in:

RECOMMENDED - The lifetime in seconds of the authorization grant.

refresh_token:

OPTIONAL according to Section 2.2 of . In the context of this specification, this parameter SHOULD NOT be used.

Error Response On an error condition, the IdP returns an OAuth 2.0 Token Error response as defined in Section 5.2 of , e.g:

Identity Assertion Authorization Grant JWT The Identity Assertion Authorization Grant JWT is issued and signed by the IdP, and describes the intended audience of the authorization grant as well as the client to which it was issued and the subject identifier of the resource owner, using the following claims:

iss:

REQUIRED - The IdP issuer URL as defined in Section 4.1.1 of

sub:

REQUIRED - The subject identifier (e.g. user ID) of the resource owner at the Resource Application as defined in

aud:

REQUIRED - The Issuer URL () of the Resource Application's authorization server as defined in

resource:

OPTIONAL - The Resource Identifier () of the Resource Application's resource server (either a single URI or an array of URIs)

client_id:

REQUIRED - An identifier of the client that this JWT was issued to, which MUST be recognized by the Resource Application's authorization server. For interoperability, the client identifier SHOULD be a client_id as defined in .

jti:

REQUIRED - Unique ID of this JWT as defined in

exp:

REQUIRED - as defined in

iat:

REQUIRED - as defined in

scope:

OPTIONAL - a JSON string containing a space-separated list of scopes associated with the token, in the format described in

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 . An example JWT shown with expanded header and payload claims is below: The authorization server MAY add additional claims as necessary. Implementation notes:

• If the IdP is multi-tenant and uses the same issuer for all tenants, the Resource Application will already have IdP-specific logic to determine the tenant from the OpenID Connect ID Token (e.g. a custom hd claim in Google) or SAML assertion, and will need to use that if the IdP also has only one client registration for the Resource Application.
• sub should be an opaque ID, as iss+sub is unique. The IdP might want to also include the user's email here, which it should do as a new email claim. This would let the app dedupe existing users who may have an account with an email address but have not done SSO yet.

Access Token Request The Client makes an access token request to the Resource Application's token endpoint using the previously obtained Identity Assertion Authorization Grant as a JWT Assertion as defined by .

grant_type:

REQUIRED - The value of grant_type is urn:ietf:params:oauth:grant-type:jwt-bearer

assertion:

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

The Client authenticates with its credentials as registered with the Resource Application's authorization server. For example:

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

• Validate the JWT typ is oauth-id-jag+jwt (per )
• The aud claim MUST identify the Issuer URL of the Resource Application's authorization server as the intended audience of the JWT.
• The client_id claim MUST identify the same client as the client authentication in the request.

Response The Resource Application token endpoint responds with an OAuth 2.0 Token Response, e.g.:

Authorization Server (IdP) Metadata An IdP can advertise its support for this profile in its OAuth Authorization Server Metadata . Identity and Authorization Chaining Across Domains defines a new metadata property identity_chaining_requested_token_types_supported for this purpose. To advertise support for the Identity Assertion Authorization Grant, the authorization server SHOULD include the following value in the identity_chaining_requested_token_types_supported property: urn:ietf:params:oauth:token-type:id-jag

Security Considerations

Client Authentication This specification SHOULD only be supported for confidential clients. Public clients SHOULD redirect the user with an OAuth 2.0 Authorization Request.

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 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 App, and Identity Provider are all in different trust domains. In particular, the Identity Provider MUST NOT issue access tokens in response to an ID-JAG it issued itself. Doing so could lead to unintentional broadening of the scope of authorization.

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 a Identity Assertion Authorization Grant JWT.

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 a Identity Assertion JWT Authorization Grant
• Change Controller: IESG
• Specification Document: This document

JSON Web Token Claims Registration This section registers resource 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: IESG
• Specification Document(s):

References Normative References 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) 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. 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. 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. 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. 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 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. SPIRL SPIRL MITRE NSA-CCSS Ping Identity This specification defines a mechanism to preserve identity and authorization information across trust domains that use the OAuth 2.0 Framework. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-identity-chaining. IANA 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. This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK] 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. 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 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. 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. 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.

Use Cases

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 capabilites for the organization. End-users get a better experience (SSO) and administrators get better security outcomes such 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 Application
• Enterprise has established a trust relationship between their IdP and the Client for SSO and Identity Assertion Authorization Grant
• Enterprise has established a trust relationship between their IdP and the Resource Application for SSO and Identity Assertion Authorization Grant
• Enterprise has granted the Client permission to act on behalf of users for the Resource Application with a 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 distruptive 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 Application
• The Client has obtained an Identity Assertion (e.g. ID Token) from the IdP Authorization Server
• The Resource Application is configured to allow the Identity Assertion Authorization Grant from unregistered clients

LLM Agent using Enterprise Tools AI agents, including those based on large language models (LLMs), are designed to manage user context, memory, and interaction state across multi-turn conversations. To perform complex tasks, these agents often integrate with external systems such as SaaS applications, internal services, or enterprise data sources. When accessing these systems, the agent operates on behalf of the end user, and its actions are constrained by the user’s identity, role, and permissions as defined by the enterprise. This ensures that all data access and operations are properly scoped and compliant with organizational access controls.

Preconditions

• The LLM Agent has a registered OAuth 2.0 Client (com.example.ai-agent) with the Enterprise IdP (cyberdyne.idp.example)
• The LLM Agent has a registered OAuth 2.0 Client (4960880b83dc9) with the External Tool Application (saas.example.net)
• Enterprise has established a trust relationship between their IdP and the LLM Agent for SSO
• Enterprise has established a trust relationship between their IdP and the External Tool Application for SSO and Identity Assertion Authorization Grant
• Enterprise has granted the LLM Agent permission to act on behalf of users for the External Tool Application with a specific set of scopes

LLM Agent establishes a User Identity with Enterprise IdP LLM Agent discovers the Enterprise IdP's OpenID Connect Provider configuration based on a configured issuer that was previously establshed.

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

LLM 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) LLM Agent 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 with an authorization request

User authenticates and authorizes LLM Agent Enterprise IdP authenticates the end-user and redirects back to the LLM Agent's registered client redirect URI with an authorization code: LLM Agent exchanges the code and PKCE code_verifier to obtain an ID Token and Access Token for the IdP's UserInfo endpoint LLM Agent validates the ID Token using the published JWKS for the IdP LLM Agent now has an identity binding for context

LLM Agent calls Enterprise External Tool LLM Agent tool calls an external tool provided by an Enterprise SaaS Application (Resource Server) without a valid access token and is issued an authentication challenge per Protected Resource Metadata .

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

LLM Agent fetches the external tool resource's OAuth 2.0 Protected Resource Metadata per to dynamically discover an authorization server that can issue an access token for the resource. LLM Agent discovers the Authorization Server configuration per LLM Agent has learned all necessary endpoints and supported capabilites to obtain an access token for the external tool. If the urn:ietf:params:oauth:grant-type:jwt-bearer grant type is supported the LLM can first attempt to silently obtain an access token using an Identity Assertion Authorization Grant from the Enterprise's IdP otherwise it can fallback to interactively obtaining a standard authorization_code from the SaaS Application's Authorization Server

• Note: This would benefit from an Authorization Server Metadata property to indicate whether the Identity Assertion Authorization Grant form of jwt-bearer would be accepted by this authorization server. There are other uses of jwt-bearer that may be supported by the authorization server as well, and is not necessarily a reliable indication that the Identity Assertion Authorization Grant would be supported. See issue #16.

LLM Agent obtains an Identity Assertion Grant for Enterprise External Tool from the Enterprise IdP LLM Agent makes an Identity Assertion Grant Token Exchange request for the external tool's resource from the user's Enterprise IdP using the ID Token the LLM Agent obtained when establishing an identity binding context along with scopes and the resource identifier for the external tool that was returned in the tool's OAuth 2.0 Protected Resource Metadata If access is granted, the Enterprise IdP creates a signed Identity Assertion Authorization Grant JWT and returns it in the token exchange response defined in Section 2.2 of : Identity Assertion Authorization Grant JWT claims:

LLM Agent obtains an Access Token for Enterprise External Tool LLM Agent makes a token request to the previously discovered external tool's Authorization Server token endpoint using the Identity Assertion Authorization Grant obtained from the Enterprise IdP as a JWT Assertion as defined by . The LLM Agent authenticates with its client credentials that were registered with the SaaS Authorization Server

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

SaaS Authorization Server validates the Identity Assertion Authorization Grant using the published JWKS for the trusted Enterprise IdP

LLM Agent makes an authorized External Tool request LLM Agent tool calls an external tool provided by the Enterprise SaaS Application (Resource Server) 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, Sofia Desenberg, Meghna Dubey, George Fletcher, Pieter Kasselman, Kai Lehmann, Dean H. Saxe, Filip Skokan.

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

• Use audience instead of resource to reference the authorization server issuer
• Add optional resource to indicate the resource server identifier
• Added a section on how to advertise support in the IdP metadata

-04

• Improved section references to other specs
• Editorial clarifications
• Updated references to RFC9728
• Rewrote intro
• Added Brian Campbell as co-author
• Changed "SHOULD NOT" to "MUST NOT" issue access tokens in response to an ID-JAG it issued itself

-03

• Added example for AI Agent

-02

• Changed the aud property to the Issuer URL instead of the token endpoint

-01

• Corrected the scope property in the JWT to match token exchange and JWT access token profile
• Formatting and editorial fixes

-00

• Initial revision