Security teams should use token exchange only when a service must act for a user in a bounded task. Issue short-lived tokens, limit scopes to the minimum required, and make the audience explicit so the exchanged token can be used only by the intended resource server. Where delegation matters, preserve the actor identity in claims and log it for auditability.
OAuth token exchange should be treated as a delegation control, not a general token forwarding mechanism. In multi-service applications, the exchanged token should represent a bounded on-behalf-of action, with short lifetime, narrow scope, and an explicit audience so downstream services can verify exactly which resource server is being addressed. The design should preserve actor context for audit and abuse detection.
When token exchange is the right delegation pattern
Token exchange fits cases where one service must complete a user-scoped task across another service boundary without inheriting the user’s original token unchanged. That matters in multi-service architectures because each hop changes the trust boundary: the receiving service should trust the exchanged token for a specific action, not for broad reuse across the estate.
The practical rule is to prefer exchange when delegation is necessary, but not when a service can call another service with its own workload credential or a more direct service-to-service flow. That keeps the user delegation separate from machine authentication and reduces the chance that a user token becomes an all-purpose integration credential.
For standards grounding, OAuth token exchange is defined in RFC 8693: OAuth 2.0 Token Exchange, while the broader authorization framework is covered by RFC 6749: The OAuth 2.0 Authorization Framework.
What a safe exchanged token should contain
A well-formed exchanged token should be intentionally narrower than the token it replaces. Short-lived expiry limits replay value, reduced scopes prevent privilege inflation, and an explicit audience claim prevents a token minted for one resource server from being accepted elsewhere. Those properties are essential because delegation failures usually happen when a token remains valid after the task has ended or can be reused by an unintended service.
Preserving actor identity in claims is equally important. The downstream service needs to know both who initiated the action and which service is acting as the delegate, so logs and authorization decisions can distinguish user intent from service execution. Without that separation, audit trails become ambiguous and incident response loses the ability to reconstruct who approved or triggered the action.
Where stronger sender binding is required, teams should pair token exchange with sender-constrained protections such as mutual TLS or proof of possession. That does not replace token exchange, but it makes the delegated token harder to replay if intercepted.
Useful specification anchors for these design choices include RFC 8707: Resource Indicators for OAuth 2.0 for audience restriction, and RFC 9700: Best Current Practice for OAuth 2.0 Security for modern OAuth hardening guidance.
How to implement delegated access across services
The cleanest implementation pattern is to define a clear policy for which service may exchange which token, for what downstream audience, and under what user or workflow condition. That policy should be enforced centrally, not left to ad hoc service code, because the biggest operational failure is inconsistent token handling across teams or environments.
- Exchange only when the downstream operation is actually user-bound.
- Constrain the exchanged token to one resource server and one task class.
- Retain the original actor and the acting service in logs.
- Reject token passthrough if a local service credential is sufficient.
- Review token lifetime, scope, and audience as part of service change control.
For teams implementing modern API and identity boundaries, RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) and RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens are the most relevant complements when replay resistance is a design requirement.
Risk and Threat Considerations
Token exchange reduces blast radius only when delegation is tightly bounded. If teams let exchanged tokens become long-lived, over-scoped, or reusable across multiple services, the mechanism turns a single user action into broad downstream access. That is especially dangerous in service meshes and SaaS integration chains, where one stolen or overbroad delegated token can expose many resources.
Failure mechanism: The attacker or misconfigured service reuses an exchanged token beyond the intended audience, or steals a token that remains valid long enough to be replayed in another context.
Impact: Unauthorized cross-service access, poor attribution of who initiated the action, and a larger incident scope because the delegated token may carry user-derived authority into multiple systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Token exchange depends on correct token issuance and validation across services. |
| API5 — Broken Function Level Authorization | Delegated access must still limit which functions the exchanged token can invoke. | |
| Recommendation — Validate exchanged tokens rigorously and reject tokens that fail audience or integrity checks. Enforce function-level authorization on every exchanged token before execution. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Multi-service token exchange is service-to-service authentication with delegated authority. |
| AC-6 — Least Privilege | Delegated tokens should carry only the minimum authority needed for the task. | |
| AU-2 — Event Logging | Actor preservation in claims supports auditability for delegated actions. | |
| Recommendation — Use service-to-service authentication controls to bind tokens to the intended relying service. Restrict exchanged tokens to the minimum privileges required for the delegated action. Log the original actor, delegated service, and target audience for each exchanged token. | ||
Practitioner Guidance
What to verify: Confirm that every token exchange path enforces audience restriction, short expiry, and least-privilege scopes, and that the downstream service rejects tokens not minted for it.
Decision rule: If a service does not truly need to act on behalf of a user, do not use token exchange, use a service-owned credentialed flow instead. If it does need delegation, require actor-preserving claims and log correlation before go-live.
Practitioner takeaway: The control objective is not “move tokens between services”; it is “convey only the minimum delegated authority needed for one bounded action, while keeping attribution and replay resistance intact.”
Related resources from NHI Mgmt Group
- How should security teams implement delegated authorization for on-behalf-of access in applications and identity flows?
- How should security teams validate OAuth token trust across multiple issuers in multi-tenant applications?
- How should security teams implement RBAC in multi-tenant MongoDB applications without hardcoding access rules into queries?
- How should security teams implement Client ID Metadata Documents?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
