OAuth 2.0 Token Exchange

Expanded Definition

OAuth 2.0 token exchange is most useful when a caller must present a valid credential but the receiving system should not trust that credential in its original form. Rather than forwarding the same token across services, an authorisation server issues a new token with different audience, issuer, scope, or lifetime constraints. That makes it a practical control for cross-domain delegation, service chaining, and brokered access in NHI workflows.

In NHI security, the concept is narrower than generic token forwarding. A token exchange flow should express intent, constrain privilege, and preserve traceability across trust boundaries. It is also distinct from simple refresh-token use, because the purpose is not only to renew access but to translate context. The formal model is described in the IETF’s RFC 8693, though implementation details vary across vendors and platforms.

The most common misapplication is treating token exchange as a convenient way to move broad credentials between systems, which occurs when teams exchange tokens without narrowing scope or validating the downstream audience.

Examples and Use Cases

Implementing OAuth 2.0 Token Exchange rigorously often introduces extra policy complexity, requiring organisations to balance delegation flexibility against tighter issuer and audience controls.

• A gateway receives a user-facing token and exchanges it for a service token that can call only one internal API, reducing blast radius if the downstream token is exposed.
• An AI agent receives short-lived access to a mailbox, then exchanges that access for a narrower token that can read only a specific folder or message class.
• A partner integration uses a federated token from an external IdP, then converts it into a locally issued token whose claims match internal RBAC and audit requirements.
• A platform broker translates identity across cloud or tenant boundaries without sharing the original bearer token, supporting clearer trust separation.
• When investigating token misuse, analysts often compare token exchange behaviour against incidents such as the Salesloft OAuth token breach, where access tokens became a direct path into third-party SaaS data.

For organisations that want a broader control lens, NIST’s NIST Cybersecurity Framework 2.0 is useful for mapping exchange flows to access governance and monitoring expectations.

Why It Matters in NHI Security

Token exchange matters because NHI incidents rarely fail at the point of first authentication. They fail when a valid credential is reused too broadly, retained too long, or accepted in a trust context it was never meant for. In practice, token exchange can reduce that risk only if the resulting token is materially more constrained than the original. If the exchange process is weak, it becomes another abstraction layer that hides privilege sprawl rather than containing it.

This is especially important for third-party SaaS and delegated app ecosystems. NHIMG research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which means exchanged tokens can become hard to inventory, monitor, and revoke. That visibility gap is one reason the State of Non-Human Identity Security highlights OAuth-connected risk as a persistent control failure.

Token exchange also fits the broader pattern seen in secret exposure and lifecycle failures described in the Guide to the Secret Sprawl Challenge, where credentials spread faster than teams can govern them. Organisations typically encounter the need for token exchange only after a token is stolen, over-scoped, or traced into an unauthorised SaaS pathway, at which point the control becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between OAuth and token exchange for AI agent access?
• OAuth Connected App
• Why is OAuth token management critical in cloud environments?
• How should organizations respond to OAuth token abuse incidents?