This blog was originally published on Descope.

OAuth Token Exchange is a grant type defined in OAuth 2.0 (RFC 8693) that allows a client to present an existing security token to an authorization server and receive a new token in return, scoped and addressed for the next destination in a request chain. It operates entirely between services and the authorization server, on the basis of a token already in hand. Most OAuth grant types assume a contained interaction in which a client gets authorized, receives a token, and uses it. OAuth Token Exchange addresses the cases this common model doesn't cover, like when a token needs to travel across service boundaries, change its audience, shed unnecessary permissions, or carry an explicit record of who is acting on whose behalf. The growing relevance of token exchange is directly tied to the rise of agentic identity systems, where a single user authorization may need to propagate through an unpredictable sequence of services and tools.

This post explains how OAuth Token Exchange works, the distinction between its two core patterns (impersonation and delegation), when to use it, and what to consider when implementing it.

How OAuth Token Exchange works

A token exchange request is a POST to the authorization server's token endpoint, the same endpoint used by other OAuth grant types. The client presents a subject token, which is the existing credential representing the party on whose behalf the new token is being requested, along with a parameter identifying what type of token it is. The type identifier tells the authorization server how to parse and validate what it receives: registered types cover access tokens, ID tokens, JWTs in a general sense, and SAML assertions, among others.

Several optional parameters shape what comes back from this initial arc of the flow:

The audience parameter specifies who the new token is for (the aud claim in a JWT), like which resource servers or services the token is valid for. Setting the audience claim in the exchange request pins the issued token to a specific target, preventing cross-server reuse. The scope parameter requests the permissions the new token should carry (typically narrower than what the subject token holds).

An actor token can be included when the requesting service needs to identify itself as a party distinct from the subject, which is the mechanism that enables delegation rather than impersonation (more on that in the next section).

A requested token type parameter tells the authorization server what format to issue.

The response follows the standard shape established by OAuth: the issued token is returned in the access token field, a field name reused for historical reasons since the returned credential is not necessarily an OAuth access token in the functional sense. Crucially, presenting a token for exchange does not invalidate it. The subject token remains valid unless separately revoked. One detail worth mentioning is that RFC 8693 leaves client authentication requirements up to each implementation. The spec permits unauthenticated exchanges, but that flexibility is not a recommendation. Allowing any caller to exchange tokens without proving its own identity means anyone who obtains a valid token can potentially trade it for another one.

OAuth Token Exchange impersonation vs. delegation

The most significant design decision in a token exchange implementation is whether the issued token uses impersonation or delegation patterns. The spec defines both for different contexts, and they each have meaningful considerations for audit trail clarity.

Impersonation: When the requesting service takes on the complete identity of the subject. The resource server receiving the token sees only the original user, with no indication that an intermediate service was involved. This is appropriate when the downstream service has no need for that information, and the intermediate service is fully trusted to act within the bounds of the original authorization.

Delegation: When the requesting service retains its own identity while acting on behalf of the subject. The issued token is a composite: it carries both the subject (the original user or entity, or sub) and the actor (the requesting service, or act). The actor claim is a JSON object embedded in the issued JWT containing claims about the acting party. A resource server processing a delegation token can determine both who authorized the action and which service executed it.

The key difference between these patterns comes down to audit trail clarity. Impersonation produces logs that look more or less identical to direct user actions, which is what you want when the intermediate service should be invisible. It's the opposite of what you want when you need to reconstruct what happened across a request chain, however. For multi-agent systems in particular, where an orchestrator agent may dispatch several sub-agents each calling different downstream services, delegation is the appropriate pattern. RFC 8693 also defines an authorized actor claim (may_act) that subject tokens can carry. A token with this claim pre-authorizes specific parties to exchange it, and the authorization server can inspect it when evaluating whether to honor the request. This gives the original token issuer a degree of control over how and by whom the token can be forwarded.

Whether impersonation or delegation applies is determined by the request itself: a subject token alone produces impersonation, since there is no actor identity to include. Adding an actor token enables delegation, and the authorization server can issue a composite token carrying both identities.

OAuth Token Exchange use cases

Token exchange applies broadly whenever authorization needs to cross a service boundary without re-prompting the user or forwarding a token that wasn't issued for its next destination. The examples below represent the most common patterns (but aren't an exhaustive list).

Microservices and internal service calls: When a request travels through several backend services before reaching its destination, forwarding the original token at each hop creates problems. Most critically, it was issued for a specific client with a specific audience, so downstream services may reject it, and it likely carries more scope than any individual downstream service actually needs. Exchanging tokens lets each service trade the token it holds for one correctly scoped and addressed for the next leg of its journey, while the original user's identity travels through intact.

AI agent delegation: When a user authorizes an agent to act on their behalf, that agent may need to call several downstream APIs or Model Context Protocol (MCP) servers in sequence. Rather than forwarding the original user token or requiring the user to re-authorize at each step, the agent exchanges its delegated token for one scoped specifically to each destination. The delegation chain remains intact: each downstream service can verify who authorized the action and which agent executed it.

Cross-domain federation: When a token is issued by an external identity provider (a SAML assertion from an enterprise identity provider, or a JWT from a third-party service) it cannot be used directly with a resource server that only trusts tokens from its own authorization server. Exchanging tokens bridges the gap: the external token is presented as the subject token, the local authorization server validates it, maps the identity to a local principal (an entity that can be authenticated and granted access, like a user or service), and issues a token in the local trust domain. This is particularly relevant for enterprise federation scenarios where multiple identity providers are in play.

Token exchange in agentic identity

The delegation model maps directly onto how agentic authorization needs to work at scale. When a user grants an agent permission to act on their behalf, that authorization event produces a delegated token identifying both the user and the agent. What happens next is where token exchange becomes the operative mechanism.

Agents rarely call a single service, especially for long-running or complex tasks. An orchestrating agent in a multi-agent system may invoke several tools and sub-agents in sequence, each requiring its own scoped credential. A sub-agent spawned mid-task may need to call a downstream API the user never directly interacted with. In each case, the agent exchanges the delegated token it holds for one scoped and addressed to the immediate destination, rather than forwarding the original credential or requesting a new authorization entirely. The user's identity and the agent's identity both travel through each exchange, satisfying the resource server's need to know who authorized the action and maintaining the full audit trail across every hop.

This also handles the revocation case cleanly. Because each token in the chain is issued with a specific audience and scope, revoking the user's original authorization propagates through the system: the authorization server stops honoring exchanges against a revoked subject token, and downstream services that validate tokens against the issuer's key material will reject any that have expired or been revoked. The chain breaks at the point of revocation rather than requiring per-service cleanup.

Multi-agent systems, where one agent delegates to another (which may delegate yet another sub-agent, and so on), require explicit policy at each hop to prevent scope from persisting unchanged through the chain. The authorized actor claim (may_act) gives each link in that chain a mechanism for pre-authorizing the next actor, but the enforcement logic is an implementation responsibility, not something the spec provides automatically.

Best practices and security considerations

Token exchange introduces a few implementation decisions that affect security posture in ways other grants don't. The considerations below apply across most deployments, though the specific requirements will vary depending on the trust model and pattern (delegation vs. impersonation).

Scope only to what is needed: Exchanged tokens should carry equal or narrower scope than the subject token (and most authorization servers wouldn't allow scope elevation via token exchange by default). Each exchange is an opportunity to narrow scopes to what the next service actually needs.

Authenticate the requesting client: A confidential client performing a token exchange should authenticate at the token endpoint just as it would for the OAuth Client Credentials Flow. Anonymous token exchange means anyone in possession of a valid token (including an attacker who obtained it through other means) can potentially trade it for a new one.

Design explicit policy for multi-hop delegation: The authorized actor claim enables pre-authorization of which actors may exchange a given token, but does not automatically enforce scope reduction across hops. If Agent A delegates to Agent B, which delegates to Agent C, explicit policy at each step is required to prevent the original scope from persisting unchanged through the entire chain.

Revoke input tokens deliberately: A token exchange does not revoke the subject token automatically. After exchange, audit whether the subject token needs to continue being valid. If it doesn't, revoke it. Leaving it live creates a window where two tokens with overlapping authority are both valid.

Prefer delegation over impersonation in agentic contexts: When intermediate services are part of an observable, auditable workflow, delegation produces tokens that accurately reflect what happened: which user authorized the action and which agent executed it.

Implementation example of OAuth Token Exchange

We'll use Descope's integration with Skyflow for MCP servers in the following example. In this scenario, Descope's authorization server exposes a token exchange endpoint as part of its OAuth 2.1 infrastructure. When the MCP server is configured in Descope, the .well-known OpenID configuration includes the authorization, token exchange, JWKS, and Dynamic Client Registration (DCR) endpoints. A Descope access token issued after user authentication and consent is exchanged for a Skyflow bearer token at runtime. That Skyflow token carries contextual information about the user's role and drives row-level security and privacy policy enforcement before any data is returned to the agent. The user identity travels through the exchange; the downstream service makes authorization decisions based on who the user is, not which service is calling.

More broadly, Descope's Agentic Identity Hub features capabilities using the delegation model that token exchange enables. When a user authorizes an AI agent through Descope's consent flow, the agent receives scoped credentials tied back to that user. When the agent calls a downstream service, those credentials include the chain of custody (who authorized the action, which agent executed it, etc.). That traceability is what makes agent access auditable and revocable after the fact.

The value of OAuth Token Exchange in modern identity

OAuth Token Exchange fills a crucial gap that other grant types don't: what happens when authorization has been established and a request needs to move through multiple services before it reaches its destination? By providing a clear answer to and standard for that question, OAuth Token Exchange makes it possible to preserve identity context, enforce least privilege at each hop, and maintain an audit trail across complex request chains without re-prompting the user.

Its relevance has grown exponentially with the rise of agentic identity. The delegation patterns defined in this spec, specifically the actor and authorized actor claims, give agentic systems a principled way to represent the relationship between a user's authorization and the agent acting on their behalf, at every leg of a multi-service (or multi-agent) workflow.

Descope's Agentic Identity Hub is designed to put these patterns into practice, providing the delegation infrastructure, consent flows, and audit streaming integration that makes agent access governable and revocable. To get started securing your agentic project, sign up for a Free Forever Descope Account, join the AuthTown dev community, and reach out to our auth experts to learn more.

FAQs about OAuth Token Exchange

What is OAuth Token Exchange?

OAuth Token Exchange is a grant type defined in RFC 8693 that allows a service to present an existing security token to an authorization server and receive a new one in return. The new token may have a different audience, narrower scope, different format, or carry delegation semantic identifying which service is acting on whose behalf. It operates entirely between services with no user-facing redirect or re-authorization, and is increasingly used in agentic systems where a single user authorization needs to propagate through multiple downstream services.

Is OAuth Token Exchange the same as refreshing a token?

No. Token refresh is for receiving a new access token for the same client, audience, and authorization context. Token exchange is a different mechanism: it takes an existing token and issues a new token that may have a different audience, scope, or format, or carry delegation patterns identifying a separate acting party. Refresh is about extending a session, while token exchange is about crossing a service boundary.

Does token exchange work with non-JWT token formats?

Yes. The spec defines type identifiers for several token formats, including opaque tokens and SAML assertions, in addition to JWTs. The type identifier parameter tells the authorization server what format it's receiving so it knows how to validate the subject token. What format comes back depends on what the authorization server supports and what the client requests via the requested token type parameter.

Can token exchange be used to elevate permissions?

The spec doesn't prohibit it, but it isn't an intended use and most authorization servers won't allow it by default. Token exchange is designed to narrow authorization scope at each hop, not expand it. A deployment that permits scope elevation via exchange would need to be explicitly configured that way, and doing so would undermine the least-privilege intent of the mechanism.

What happens to the original token after exchange?

It stays valid. Performing a token exchange does not revoke the subject token. If the original token shouldn't remain usable after the exchange, it needs to be revoked separately through whatever revocation mechanism the authorization server provides.