Protocols and how-tos
OAuth token exchange (RFC 8693) for delegation and impersonation
When to use token exchange, the difference between delegation and impersonation, the act claim, and how to keep exchanged tokens narrower than the original.
The short answer
OAuth 2.0 Token Exchange (RFC 8693) lets a client trade one token for another at the authorization server — typically a narrower token for a downstream service, or a token that records that service A is acting on behalf of user B. It replaces the common anti-pattern of forwarding the user's original access token through every service in a call chain.
Sources last reviewed .
The problem it solves
In a microservice or agent system, the front service receives the user's token and must call further services. Forwarding the same token means every downstream service receives a credential valid for every other service in its audience, and a compromise anywhere exposes everything. Token exchange lets each hop request a token scoped to the next audience only.
The request
A POST to the token endpoint with grant_type=urn:ietf:params:oauth:grant-type:token-exchange, a subject_token and subject_token_type describing whom the new token is about, and optionally an actor_token describing who is acting. The audience or resource parameter (RFC 8707) names the target, and scope narrows permissions.
Delegation versus impersonation
With impersonation, the issued token is indistinguishable from one issued to the subject directly. With delegation, the token carries an act claim naming the actor, so the resource server and the audit log can see that service A acted for user B. RFC 8693 section 1.1 discusses both. For agents and automated systems, delegation is almost always the right choice, because an audit trail that cannot distinguish a person from a program acting for them is not much of a trail.
Rules worth enforcing
- An exchanged token should never be broader than the subject token in scope or lifetime.
- Restrict which clients may exchange, and for which audiences — exchange is a powerful grant.
- Sender-constrain exchanged tokens where possible (DPoP), so a token minted for one service cannot be replayed by another.
- Log both subject and actor on every exchange.
In Authreads
How this applies to Authreads
Token Exchange (RFC 8693) is Available in Authreads for machine and agent identity, and is also how a relying party selects a workspace after sign-in when a user belongs to more than one.
Authreads is a multi-tenant identity platform in beta. Capability status is maintained on /roadmap as Available, In progress or Planned.
Keep reading
Use cases
Identity for AI agents: delegation, scoping and sender-constrained tokens
Protocols and how-tos
DPoP implementation guide: sender-constrained tokens without mTLS
Multi-tenant architecture
Organization switching: letting one user belong to many tenants
Glossary: Token exchange · Machine identity · Access token
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.