When should token exchange be used instead of passing the original token?

When token exchange is the right choice

Token exchange is the right pattern when the receiving service should not see the caller’s original token, but instead needs a token tailored to its own trust boundary. That usually means a narrower audience, a different subject or actor representation, or a fresh credential that carries only the authority required for the next hop. It is an authorization design choice, not a transport convenience.

Used properly, exchange helps preserve separation between domains and reduces the blast radius of a token that was minted for a broader context. In OAuth terms, that is the difference between forwarding a bearer token intact and issuing a downstream token that is purpose-built for the target resource. The standard reference point is RFC 8693: OAuth 2.0 Token Exchange, which defines the delegation and impersonation patterns that make this possible.

In practice, token exchange is most useful when the original token was acquired for a user, application, or agent with broader authority than the downstream service should inherit. A common example is a call chain where an upstream service authenticates once, then exchanges that token before calling a lower-trust service that should not receive the original audience, scopes, or identity context.

Why passing the original token can be the wrong default

Passing the original token keeps the full upstream authority visible to every downstream service in the chain. That can be acceptable in a tightly controlled path, but it becomes a design flaw when the target only needs partial access, a different trust domain, or a service-specific identity assertion. Token exchange reduces unnecessary exposure by translating the caller’s authority into something the next service can safely evaluate on its own terms.

This matters when the downstream system is operated by a different team, sits behind a different security boundary, or should not be able to replay the upstream token elsewhere. It also matters when the original token may contain claims that are irrelevant to the target service, because fewer transferable claims usually means less opportunity for misuse if the token is logged, forwarded, or intercepted.

For machine-to-machine and delegated access flows, the underlying OAuth design still starts with the correct base grant, often described in RFC 6749: The OAuth 2.0 Authorization Framework. Token exchange then becomes the containment step that reshapes the original authority into a downstream token with a narrower use case.

How to decide whether exchange is actually justified

The practical decision is simple: if the target can safely and accurately authorize the request using the original token as-is, exchange is usually unnecessary. If the target needs a different audience, a reduced scope set, or a token that reflects a more specific trust context, exchange is justified. If the only reason to exchange is to move a token from one component to another, that is usually a sign the architecture has not separated trust boundaries cleanly enough.

That judgment is especially important in service meshes, microservices, federation hubs, and agent-driven workflows where token forwarding can become the path of least resistance. In those environments, the better pattern is often to make the downstream service accept a token that was minted for it, rather than teaching every service to trust the original token from the edge.

For OAuth-based architectures that need audience restriction, sender constraints, or stronger downstream control, adjacent standards can also matter. Resource-scoping with RFC 8707: Resource Indicators for OAuth 2.0 and sender-constrained tokens via RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) are often complementary to exchange when the goal is to keep tokens tightly bound to the intended use.

Risk and Threat Considerations

The main risk in forwarding the original token is overexposure: a downstream system gets more authority than it needs, and any compromise of that service can expose a broader token than intended. Token exchange reduces that blast radius by giving each hop a token that is specific to the next decision point, which also makes abuse easier to contain and reason about.

Failure mechanism: A broad upstream token is forwarded unchanged, then reused outside its intended audience, trust domain, or call chain. If a service logs, caches, or mishandles that token, the attacker inherits the upstream authority instead of a constrained downstream credential.

Impact: Excessive downstream access, lateral movement across services, and harder incident containment because one exposed token may be valid in places it was never meant to reach.

Practitioner Guidance

What to verify: Confirm that the downstream service truly needs the caller’s original token context before you preserve it. If the service only needs to know that a trusted upstream component vouched for the call, exchange is usually the safer choice because it forces the target to authorize against its own audience and scope model.

Decision rule: If the downstream service would reject, over-accept, or misinterpret the original token’s claims, exchange it. If the target is only a relay and does not make its own authorization decision, token forwarding may be sufficient, but that should be an explicit design decision rather than an accident of convenience.

Practitioner takeaway: Use token exchange when it changes the security decision at the next hop, not when it merely changes the plumbing. The value is in containment, audience reduction, and trust separation, not in moving tokens through more components.

Related resources from NHI Mgmt Group

• Guide: OAuth Token Exchange and Delegation Guide
• Why do CIAM implementations need a token exchange pattern instead of passing access tokens directly to backends?
• Why is OAuth token management critical in cloud environments?
• When should organisations use token exchange instead of direct client credentials?
• What breaks when a sanctions program relies only on exchange names instead of tracing successor entities and token flows?