How XAA works

Enterprises sign every application into one identity provider with OpenID Connect or SAML. But when one application needs to call another application's API on the user's behalf, OAuth's answer has been a direct app-to-app flow (an authorization code handshake between the two apps) that the IdP never sees (Section 1). The IdP that manages who can reach what sits the delegation out.

Cross-App Access (XAA) moves that decision inside the trust boundary that already exists: the IdP both apps already trust for SSO brokers the delegation. It does so by profiling identity chaining into concrete deliverables (Section 1): the Token Exchange request that obtains an ID-JAG, the ID-JAG itself with its claims, the processing rules the Resource Authorization Server applies when exchanging an ID-JAG for an access token, and the metadata used to advertise support.

The draft's own example: a wiki app wants to read your chat history at a chat app from another vendor. Both are SSO'd into the enterprise IdP. With XAA, the wiki asks the IdP for a grant naming the chat app's authorization server, and trades that grant for an access token (Section 4.1).

Four roles (Section 2.1): the Client (the wiki app), the IdP Authorization Server (the enterprise IdP), the Resource Authorization Server (the chat app's AS), and the Resource Server (the chat API). Three separate registration relationships connect them (Section 5): client-to-IdP for SSO, client-to-Resource-AS for API access, and Resource-AS-to-IdP - the pre-existing SSO trust the whole pattern rides on.

The Client and the IdP AS live in trust domain A; the Resource AS and Resource Server in trust domain B. The ID-JAG is the object that crosses the boundary: signed by the IdP, consumed by the Resource AS. The Resource Server never talks to the IdP at all - it validates access tokens from its own AS only (Section 2.1).

The client authenticates to the IdP - always; a request without client authentication is rejected withinvalid_client (Section 4.3.3) - and presents the Identity Assertion it got from SSO as thesubject_token. The audience parameter is the Resource Authorization Server's issuer identifier, exactly one value; a multi-value request is refused with invalid_request, and an audience the IdP has no trust relationship with gets invalid_target (Sections 4.3, 4.3.3). The IdP validates that the subject token really is what it claims to be - a token the IdP itself issued for SSO, not an access token or a grant being recycled (Section 4.3.3) - applies its policy, and returns the signed ID-JAG (Section 4.3.4).

The ID-JAG is a JWT whose header typ MUST be oauth-id-jag+jwt (Section 3.1). RS256 is mandatory to implement for both authorization servers, and Resource Authorization Servers SHOULD also support ES256 (Section 3, RFC 7523 Section 5). Seven claims are REQUIRED (Section 3.1): iss and aud name the two ends of this specific trust relationship, sub and optionally sub_id identify the user,client_id names the client at the Resource AS that will act for the user, andjti, exp, iat make the grant trackable and perishable.

Two claims deserve the emphasis they get in the draft. aud MUST carry exactly the receiving Resource AS's issuer - a string or a single-element array, enforced to prevent audience injection (Section 4.4.1). And subject resolution is the point of the whole document: it is RECOMMENDED that the grant carry email and/or aud_sub so the Resource AS can resolve the user to a local account, including just-in-time provisioning when the user has never signed in there before (Section 3.1).

The client redeems the ID-JAG at the Resource AS's token endpoint as an ordinary RFC 7523 assertion (Section 4.4). The Resource AS SHOULD require client authentication here too; if the client does not authenticate, the request MUST carry a sender-constrained grant instead (Section 4.4). Then the processing rules run: verify typ, verify the signature against the trusted issuer's keys from itsjwks_uri, check aud, check client_id against the authenticated client, check exp - each failure maps to invalid_grant, while a valid grant for an unentitled user maps to access_denied (Sections 4.4.1, 4.4.3).

The obvious alternative - the IdP issuing resource access tokens directly - is exactly what the draft does not do. Unlike profiles where the IdP issues the access tokens the Resource Server consumes, XAA preserves the Resource Authorization Server as the issuer of access tokens for its own resources (Section 1). The IdP centralizes identity, SSO trust, and the decision to broker access; the Resource AS keeps independent control of its tokens, its scopes, and its local policy (Section 1). The alternative couples every API to a growing list of foreign token issuers, and the draft pins the restraint down: an IdP MUST NOT honor its own ID-JAG by issuing access tokens unless explicitly configured, and then no more generously than a direct issuance would have been (Section 9.4).

The cost of the shape is the mapping work in Section 5: the IdP must know which client_id at the Resource AS corresponds to this client, and which sub value the Resource AS's own SSO registration would carry - both established out of band. Client ID Metadata Documents are called out as a namespace that removes the client mapping (Section 5.1). Metadata advertisement closes the loop: an IdP SHOULD list the id-jag token type in identity_chaining_requested_token_types_supported, a Resource AS SHOULD list the grant profile in authorization_grant_profiles_supported, and that advertisement MUST be coupled to grant_types_supported carryingurn:ietf:params:oauth:grant-type:jwt-bearer (Sections 7.1, 7.2).

And the map has honest blanks the draft says out loud: replay tracking is a MAY, so two compliant Resource ASs can differ (Section 4.4.4); subject-uniqueness rules need Resource-AS-side state a token inspector does not have (Section 3.1); and policy - which user may reach which app - is the IdP's administrator-defined judgment, not a protocol outcome (Section 4.3.3). Where the line sits between "the protocol guarantees" and "the deployment decides" is the difference between validating a grant and trusting a system.