IETF · January 2020

OAuth 2.0 Token Exchange

RFC 8693

M. Jones, A. Nadalin, B. Campbell (ed.), J. Bradley, C. Mortimore

RFCStableAuthorizationFoundationField guide

This, plus RFC 9068 JWT access tokens, is the backbone of 'the agent acts for the user at an API'. Multi-agent call chains that stay in OAuth-land are token exchanges with act, not new protocols.

At a glance

Problem: A service that already has a token needs a different token: new audience, narrower scope, or an actor acting on behalf of a subject. Token Exchange is the standard grant for that conversion.
Identity / authn / authz: Authorization (and identity preservation) across hops. The act claim records who is acting; subject_token names who they act for.

Actors

Client / actor (the agent or service calling exchange)
Authorization server
Subject (user or upstream service)
Downstream resource

In one board · hops

act grows down the chain

Alice

→ Bearer / DPoP pass →

API A

User token at API A

Alice's access token. sub is Alice. No act. The pass names who it is for, not who is holding it.

act: —

subject_tokenact

RFC 8693 does not by itself define cross-domain trust — identity chaining profiles it with RFC 7523. Contrast with WIMSE.

The gap for agents

A service that already has a token needs a different token: new audience, narrower scope, or an actor acting on behalf of a subject. RFC 8693 is the standard grant. Multi-agent call chains that stay in OAuth-land are token exchanges with act, not new protocols.

This, plus RFC 9068 JWT access tokens, is the backbone of 'the agent acts for the user at an API'. RFC 8693 does not by itself define cross-domain trust — identity chaining profiles 8693 + 7523 for that.

Actors and trust boundaries

The AS that performs the exchange must trust the subject_token and optional actor_token issuers. Downstream RSes trust the new token's issuer. Each hop should attenuate, never expand. The actor is a distinct principal; hiding it is how you lose audit and how confused deputies spawn.

Mechanics

POST grant_type=urn:ietf:params:oauth:grant-type:token-exchange with subject_token, subject_token_type, optional actor_token / actor_token_type, requested audience/resource/scope, requested_token_type. Token types are URNs (access token, JWT, ID token, SAML, …). Output often a JWT with nested act. may_act on an input token constrains who may act later.

subject_token / actor_tokenfrom spec: Quoted RFC 8693 inputs. Types are URNs. The subject is who they act for; the actor is who is calling.
actfrom spec: Quoted §4.1: nested actor identity. Agent A delegated to B delegated to C becomes nested act objects.
may_actfrom spec: Quoted: who is allowed to act for this subject in a future exchange. Enforce it.
urn:ietf:params:oauth:grant-type:token-exchangefrom spec: Quoted grant_type.

Step-by-step flows

Flow 1

On-behalf-of attenuation

1
User delegates to Agent A (authorization code). A holds a token with sub=user, client_id=A.
2
A calls token exchange: subject_token=user token, actor_token=A's identity if distinct, resource=downstream API, narrower scope.
3
AS issues a JWT with sub=user, act=A, aud=downstream, reduced scope.
4
A (or Service B) presents that token. Downstream must see both sub and act.

Never expand scope. If crossing domains, do not send this access token to AS B — mint a JWT grant (identity chaining) instead.

Identity vs authentication vs authorization

Authorization (and identity preservation) across hops. act records who is acting; subject_token names who they act for. Client authentication of the exchanger is still required.

How it composes

JWT access tokens
Structured output so the RS sees sub, client_id, act, aud.
Identity chaining
Profiles this grant plus 7523 for AS A → AS B.
Cross-App Access (ID-JAG)
Exchanges an ID Token for an ID-JAG via 8693, then redeems via 7523.
Transaction Tokens
Txn-Tokens are often requested using token-exchange-shaped parameters at a TTS inside one domain.
AAuth
AAuth may nest RFC 8693 act on auth tokens for sub-agents; that is not this grant.

What bites agent implementers

Overbroad act
If hop 2 still has the full user scope, the sub-agent is the user. Attenuate every hop. Log the chain.
Using an ID Token as subject_token carelessly
XAA does this on purpose with IdP policy. Randomly stuffing ID Tokens into 8693 at an API AS is the 'send ID Token to the API' bug in a trench coat.
Cross-domain without chaining
A token minted by AS A is not valid at AS B. Identity chaining exists because people tried anyway.

Stability — what you can ship

RFC 8693, January 2020, M. Jones, A. Nadalin, B. Campbell (ed.), J. Bradley, C. Mortimore. Stable. Ship it. https://www.rfc-editor.org/rfc/rfc8693.html

Catalog claims (short form)

subject_token / actor_token: Input tokens. Types are URNs (access token, JWT, ID token, SAML, …).
act: Nested actor identity. Agent A delegated to B delegated to C becomes nested act objects.
may_act: Who is allowed to act for this subject in a future exchange.

Implementer notes

RFC 8693 does not by itself define cross-domain trust. Identity chaining (almost an RFC in 2026) profiles 8693 + 7523 for that. Attenuate scope at every hop; never expand.

Relationship to others

Primary sources

RFC 8693https://www.rfc-editor.org/rfc/rfc8693.html