Token Exchange and Assertion Grants

A client obtains an access token scoped to the first service it calls — call it service A. Service A now needs to call service B to satisfy the request. Three bad options present themselves immediately:

RFC 8693 and the assertion grants are the two purpose-built mechanisms that avoid all three: a service presents a token it already holds — as proof of what it wants to assert — to an authorization server, and receives back a new, correctly audienced token that still carries the original user’s identity, explicitly and verifiably.

RFC 8693 defines a new grant type, urn:ietf:params:oauth:grant-type:token-exchange, that trades one or two security tokens for another. It is deliberately token-format-agnostic — the tokens involved may be JWTs, SAML assertions, or opaque strings — which is what makes it usable as the connective tissue between internally-issued OAuth tokens, externally-issued OIDC ID tokens, and legacy SAML assertions in the same architecture.

Token exchange trades a token the authorization server itself understands as an OAuth artefact. The assertion framework solves an adjacent but different problem: a client already holds a pre-existing security assertion issued by some other party — a SAML assertion from an enterprise identity provider, or a JWT signed by a trusted issuer — and wants to trade it directly for an OAuth access token, or use it as a client-authentication credential, without a browser round-trip.

RFC 7521 defines the generic framework: an assertion can be used either as a grant (the assertion parameter at the token endpoint, requesting an access token) or as a client authentication method (a client_assertion parameter, proving the client’s identity instead of a shared secret). Two profiles instantiate the framework for the two assertion formats in wide use:

Everything above assumes a single authorization server, or a small number of authorization servers that directly trust each other’s tokens. Real organisations increasingly span multiple trust domains — a subsidiary’s authorization server, a partner’s authorization server, a SaaS vendor’s authorization server — and need a user’s identity to cross those boundaries verifiably, not just internally.

draft-ietf-oauth-identity-chaining (in the RFC Editor queue at the time of writing) standardises this: it defines how an authorization server in domain B can accept a token exchange request whose subject_token was issued by a different authorization server in domain A, verify that trust relationship, and issue its own token that still carries the originating identity forward — effectively RFC 8693’s act chaining, but across an organisational trust boundary instead of within one authorization server’s own token issuance. It builds directly on RFC 8693’s wire format rather than introducing a new grant type, which is why it is documented here alongside token exchange rather than as a separate flow.

The diagram below follows a single user request from an API gateway, through service A and service B, down to service C, with a delegated token exchange narrowing audience and accumulating act at every hop.

Each exchange narrows the audience to exactly the next hop and adds one more level of act nesting, so service C can see — and log — the entire path the user’s identity travelled to reach it, not just the fact that someone eventually called it with a token naming user-42.