Token Exchange (RFC 8693)
Learn the OAuth2 Token Exchange extension that lets services swap one token for another to support delegation and impersonation across service boundaries.
Token Exchange (RFC 8693) is a free OAuth2 & OpenID Connect Deep Dive lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the OAuth2 & OpenID Connect Deep Dive learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
What Problem Does It Solve?
In a microservices world, Service A receives a token from a user, then must call Service B on the user's behalf. Forwarding the original token everywhere is risky — it may have the wrong audience or too-broad scopes.
Token Exchange (RFC 8693) lets a service trade an incoming token for a new, narrower or differently-scoped token from the authorization server.
Delegation vs Impersonation
Two distinct patterns:
- Impersonation — the new token looks like it belongs purely to the user; downstream cannot tell a middle service was involved.
- Delegation — the new token records both the user and the acting service via an
actclaim, preserving the chain.
The Grant Type
Token Exchange defines a new grant type sent to the standard token endpoint:
urn:ietf:params:oauth:grant-type:token-exchange
It does not need a browser or user interaction — it is a direct back-channel call.
Key Parameters
The request uses several parameters:
subject_token+subject_token_type— the token to exchange.actor_token— optional, identifies the acting party.audience/resource— the target service.scope— requested scopes for the new token.
Token Type URIs
Token types are identified by URIs, for example:
urn:ietf:params:oauth:token-type:access_tokenurn:ietf:params:oauth:token-type:jwturn:ietf:params:oauth:token-type:id_token
An Exchange Request
Service A exchanges the user's access token for a token scoped to Service B:
POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=eyJhbGciOi...
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&audience=https://serviceB.example.com
&scope=read:ordersThe Exchange Response
The response includes the new token plus an issued_token_type telling the caller what it received.
{
"access_token": "eyJ0eXAiOi...",
"issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
"token_type": "Bearer",
"expires_in": 600,
"scope": "read:orders"
}The act Claim
In delegation mode, the issued JWT contains an act (actor) claim nesting the acting party inside the subject. This lets the resource server audit who acted on whose behalf.
{
"sub": "user-42",
"aud": "https://serviceB.example.com",
"act": { "sub": "service-A" }
}Downscoping
A powerful use is downscoping: a service holding a broad token exchanges it for one with fewer scopes before passing it downstream. This honors least privilege so a compromised downstream service cannot do more than it needs.
When to Use It
Reach for Token Exchange when:
- Crossing trust or audience boundaries between services.
- You need an auditable delegation chain.
- You want to narrow scopes for downstream calls.
Avoid blindly forwarding the original token across services.
Security Notes
The authorization server must authenticate the requesting client and verify it is permitted to exchange the subject token for the requested audience. Always set a correct aud so tokens cannot be replayed against other services.
Quick Check
Check your grasp of Token Exchange.
Recap
Token Exchange (RFC 8693) trades one token for another via grant type token-exchange.
- Supports impersonation and delegation (the
actclaim). - Lets services downscope and re-audience tokens for downstream calls.
- Requires the AS to authenticate the client and validate the target audience.
Frequently asked questions
Is the “Token Exchange (RFC 8693)” lesson free?
Yes — the full text of “Token Exchange (RFC 8693)” is free to read here on the web, and the OAuth2 & OpenID Connect Deep Dive course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the OAuth2 & OpenID Connect Deep Dive course, upgrade to CoddyKit PRO.
What will I learn in “Token Exchange (RFC 8693)”?
Learn the OAuth2 Token Exchange extension that lets services swap one token for another to support delegation and impersonation across service boundaries. You practise OAuth2 & OpenID Connect Deep Dive with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start OAuth2 & OpenID Connect Deep Dive?
No prior experience is required. OAuth2 & OpenID Connect Deep Dive on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Token Exchange (RFC 8693)” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this OAuth2 & OpenID Connect Deep Dive lesson?
Yes. Every OAuth2 & OpenID Connect Deep Dive lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- PKCE for Public Clients
- Refresh Tokens & Scopes
- Resource Owner Password Credentials
- Token Exchange (RFC 8693)