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.
How delegated OAuth access should be designed in multi-service systems
Token exchange is the right fit when one service must take an action on a user’s behalf, but the exchanged token should be narrowly scoped to that task. In practice, the design goal is to preserve delegation without turning it into broad reuse of the original user token. That means audience restriction, short lifetimes, and explicit claims about who the actor is and what was delegated.
For the underlying protocol model, RFC 8693: OAuth 2.0 Token Exchange is the core reference because it defines the token exchange pattern for delegation and impersonation. Use it when your services need on-behalf-of behavior, but avoid treating token exchange as a general-purpose forwarding mechanism across every internal call.
What to preserve when a service acts for a user
The most important design choice is whether the downstream service needs the user’s identity, the service’s own identity, or both. Preserve the subject identity for authorization decisions that depend on the user, but also retain the actor identity so audit trails can show which service performed the request. That distinction matters when multiple services participate in one workflow and each one may have different permissions.
OAuth Token Exchange and Delegation Guide is the most direct internal reference for actor and subject tokens, act claims, may_act, and downscoping. For teams implementing delegated access, the practical lesson is that the exchanged token should describe both the user context and the calling service context so the system can authorize correctly and later explain what happened.
Audience and scope should be treated as hard boundaries, not advisory hints. If a token can be accepted by more than one resource server, or carries permissions that outlive the immediate task, the exchange has become too broad for delegated access. That is where token exchange starts to create avoidable privilege spread between services.
When exchange is safer than forwarding the original token
Multi-service applications often fail when teams forward the original access token deeper into the stack. That pattern makes every downstream service depend on the same broad token, which increases blast radius and makes service-to-service authorization harder to reason about. Token exchange is safer when each hop should receive a token that is specific to its own audience and permission set.
Microservices Security Guide reinforces that the safest pattern in distributed systems is to combine workload identity, service-level authorisation, and logging rather than pass a user token everywhere. In the same vein, OAuth Transaction Tokens Guide is useful when the real need is to preserve context across a call chain without handing every service the same bearer token.
If a downstream service only needs to know that a workflow is legitimate, consider whether a narrower transaction-context mechanism would work better than delegation. Token exchange is best reserved for cases where the downstream service truly needs to act under the user’s authority, not merely observe that the request originated upstream.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | Token exchange design depends on OAuth grant and token handling correctness. |
| Recommendation — Validate delegated flows, audience checks, and token handling against V10 requirements. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Exchanged tokens are credential-like material with lifecycle and reuse limits. |
| AC-6 — Least Privilege | Delegated tokens should carry only the minimum scopes needed for each service action. | |
| AU-2 — Event Logging | Delegated access requires auditability of actor, subject, and action context. | |
| Recommendation — Enforce short-lived token lifecycle and rotation limits for delegated access tokens. Limit exchanged token privileges to the smallest necessary scope for the task. Log actor and subject context for each exchanged token use. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Token exchange is an access-control decision about who can act on behalf of whom. |
| Recommendation — Restrict delegated access paths and review service permissions regularly. | ||
Practitioner Guidance
Decision rule: If the downstream service must make a user-sensitive decision, exchange the token and keep the audience narrow; if it only needs workflow context, do not broaden delegated authority unnecessarily.
What to verify: Check that the exchanged token is short-lived, audience-bound, and scope-limited, and that resource servers reject tokens missing the intended audience or delegation claims. Also verify that logs preserve both the actor and subject so the audit trail distinguishes “who initiated” from “who executed.”
Common mistake: Teams often preserve convenience instead of intent, which leads to token reuse across services and makes later privilege review much harder. A delegated flow is only sound when each service receives the minimum authority needed for its own step.
Practitioner takeaway: Good token exchange design does not just move identity between services, it constrains authority at the point of use so delegation remains explainable, auditable, and bounded.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org