Category: OAuth & OIDC

Token Exchange

Also known as: OAuth 2.0 Token Exchange, RFC 8693 Token Exchange

Simply put

Token exchange is a standardized way for a system to trade one security token for another. For example, an application can present a token it already holds and receive a new token that has a narrower set of permissions or is valid in a different trust context. This lets services pass identity and authorization information along a chain of calls without reusing the same credential everywhere.

Formal definition

Token Exchange is an OAuth 2.0 extension defined in RFC 8693 that specifies a request and response protocol for exchanging one security token for another. A client submits a subject token (the token to be exchanged) to the authorization server's token endpoint, optionally along with an actor token to represent delegation or impersonation scenarios, and receives a newly issued token that may carry different scopes, audiences, or trust characteristics. The mechanism supports use cases such as delegation, impersonation, and converting between token types or formats; token type identifiers in the specification indicate the kinds of tokens involved (for example access tokens or other supported types). Being an authorization-layer construct, token exchange governs what token a party may obtain and use, and it is distinct from authenticating an end user; the exact supported token types, scopes, and delegation semantics depend on the authorization server implementation and its configured profile.

Why it matters

In modern architectures, a single user request often traverses many services, and passing the original token unchanged through every hop is risky: it over-shares privileges, widens the blast radius if any downstream service is compromised, and makes it hard to reason about which party is acting on whose behalf. Token exchange, standardized in RFC 8693 as an OAuth 2.0 extension, gives teams a standards-based way to trade a broadly scoped token for one that is narrower in scope, targeted at a specific audience, or valid in a different trust context. This supports the principle of least privilege across a call chain without reusing the same credential everywhere.

The mechanism also provides a defined structure for delegation and impersonation scenarios through its subject-token and optional actor-token model, which matters when auditors and security teams need to distinguish an application acting on its own behalf from one acting on behalf of a user or another service. Because these semantics are expressed through a documented protocol rather than ad hoc token-passing conventions, they are easier to reason about, configure, and review.

It is important to keep the scope of token exchange clear: it is an authorization-layer construct that governs which token a party may obtain and use, and it is distinct from authenticating an end user. The exact supported token types, scopes, and delegation semantics depend on the authorization server implementation and its configured profile, so security value comes from correct configuration rather than from the mechanism alone.

Who it's relevant to

Security Architects

Architects designing service-to-service and multi-hop call chains use token exchange to enforce least privilege across trust boundaries, replacing reuse of a single broadly scoped token with narrower, audience-specific tokens obtained at each stage. They must decide where delegation versus impersonation semantics apply and confirm that the chosen authorization server supports the required token types and profile.

IAM and Platform Engineers

Engineers implementing token exchange configure the authorization server's token endpoint to accept subject and optional actor tokens and to issue tokens with the intended scopes and audiences. Because supported token types and delegation semantics depend on the specific implementation, they must validate behavior against their vendor's documentation rather than assuming uniform support across products.

Compliance and Audit Teams

Auditors reviewing delegated access benefit from the explicit subject-token and actor-token distinction, which helps document whether a service acted on its own behalf or on behalf of another party. Verifying that exchanged tokens carry appropriately narrowed scopes and audiences supports evidence of least-privilege enforcement across a call chain.

Inside Token Exchange

Subject token

The token representing the identity or authorization on whose behalf the exchange is requested. In OAuth 2.0 Token Exchange (RFC 8693), this is supplied via the subject_token parameter, with its format indicated by subject_token_type (for example, an access token, JWT, or ID token).

Actor token

An optional token identifying the acting party in delegation scenarios, supplied via actor_token and actor_token_type. It enables the requested token to convey that one party is acting on behalf of another, distinct from pure impersonation.

Requested token type

The requested_token_type parameter specifying the format the client wants back (for example, an access token or JWT). The authorization server may return a different type depending on configuration, indicated in the issued_token_type response field.

Impersonation versus delegation

Two distinct semantics supported by the exchange. Impersonation produces a token that appears to act as the subject with no trace of the caller, whereas delegation typically preserves both subject and actor context (commonly via an act claim) so downstream services can see the chain.

Authorization server as issuer

The exchange is performed by the authorization server (its token endpoint with the token-exchange grant type), which validates the presented token(s) and, depending on policy, issues a new token scoped for a downstream audience or resource.

Audience and scope narrowing

Parameters such as audience, resource, and scope let the requester constrain the resulting token to a specific downstream service and reduced set of permissions, supporting least-privilege propagation across services.

Common questions

Answers to the questions practitioners most commonly ask about Token Exchange.

Is token exchange a way to authenticate a user?

No. Token exchange is a delegated authorization mechanism defined as an OAuth 2.0 extension (RFC 8693). It lets a client or service trade one security token for another, typically to obtain a token with a different audience, scope, or subject for a downstream call. Authentication, verifying who a principal is, happens earlier through a separate flow; if you need proof of a user's authentication event, that comes from an OpenID Connect ID token, not from the exchange itself. Depending on configuration, a token exchange may propagate an already-authenticated subject, but the exchange does not perform authentication.

Does token exchange only support impersonation, where the new token looks like it was issued directly to the user?

No. RFC 8693 defines two distinct semantics: impersonation and delegation. In impersonation, the resulting token generally presents the subject as acting as itself, with no explicit record of the intermediary. In delegation, the token typically carries an act (actor) claim that names the party acting on the subject's behalf, preserving the delegation chain. Which semantic applies depends on the request parameters (such as the actor_token) and on server configuration, so the two should not be treated as the same behavior.

How do I request a token exchange, and what tokens do I supply?

A token exchange is typically requested at the authorization server's token endpoint using the grant_type value defined by RFC 8693 for token exchange. You supply a subject_token (the token representing the party on whose behalf the request is made) and its subject_token_type. For delegation, you may also include an actor_token and actor_token_type identifying the acting party. Requested parameters such as audience, scope, and resource let you constrain the returned token. Exact parameter support and required values vary by authorization server, so consult the specific product's profile.

What token types can be used as input and output in an exchange?

RFC 8693 defines token type identifiers for access tokens, refresh tokens, ID tokens, SAML 1.1, SAML 2.0, and JWTs, and it allows other types. The subject_token and actor_token can be any type the authorization server accepts, and the returned issued_token_type indicates what was actually produced. In most deployments the output is an access token scoped for a downstream service, but support for specific input and output types depends on the authorization server's configuration and profile.

How is the actor identified when using delegation semantics?

Under delegation, the issued token typically includes an act claim describing the acting party, and act claims can be nested to represent a chain of delegation across multiple hops. The subject remains the party on whose behalf the action is taken, while the act claim records who is acting. A relying service can inspect these claims during token validation to make authorization decisions. The precise claim contents and whether nesting is supported depend on the authorization server.

How should a downstream service validate an exchanged token before authorizing the request?

The receiving service should validate the exchanged token the same way it validates any token of that type: for a self-contained JWT, verify the signature against the issuer's keys, check the issuer, audience, and expiration, and confirm the scopes are appropriate for the requested operation. Note that a signed token is not necessarily an encrypted one, so sensitive claims may be readable in transit unless encryption is also applied. For delegation, the service can additionally examine the act claim to enforce policy on the acting party. Authorization remains a separate step from validating the token.

Common misconceptions

Token exchange is an authentication mechanism that verifies who the user is.

Token exchange is part of OAuth 2.0, a delegated authorization framework, and it operates on already-issued tokens to obtain new ones. It does not itself perform user authentication; establishing who the principal is happens earlier, and any identity assertion in the input token was produced by a separate process (for example an OpenID Connect flow).

Impersonation and delegation are the same thing in token exchange.

They are distinct semantics. Impersonation yields a token indistinguishable from one issued directly to the subject, while delegation typically retains actor context (often an act claim) so the acting party remains visible. The behavior depends on the actor_token usage and the authorization server's configuration.

A token returned by the exchange is protected because it is signed.

Signing provides integrity and authenticity, not confidentiality. Unless the token is also encrypted, its claims may be readable by any party that obtains it. Whether the issued token is opaque, signed, or encrypted depends on the deployment and profile.

Best practices

Constrain issued tokens to the intended downstream service by supplying audience or resource and narrowing scope, so exchanged tokens follow least privilege rather than carrying broad authorization.

Choose delegation semantics (preserving actor and subject context) over impersonation where auditability of the acting party matters, and document which semantics each exchange configuration produces.

Validate the subject and actor tokens fully before exchange, including signature, issuer, audience, and expiry, and confirm their declared token types match what your policy expects.

Do not treat a signed exchanged token as confidential; apply encryption or transport protections when sensitive claims must not be exposed to intermediaries.

Define authorization-server policy that limits which clients may perform exchanges, for which subjects, and toward which target audiences, rather than permitting unrestricted token minting.

Confirm the returned issued_token_type against what your resource servers accept, since the authorization server may issue a different type than requested depending on configuration.