Token Exchange lets a service exchange one access token for another with a narrower scope or different audience, without requiring the user to re-authenticate.
Overview
When a service needs to call another service on behalf of a user, it should not forward its own broad token. Token Exchange (RFC 8693) solves this by defining a standard POST /oauth/token request that swaps an existing subject_token for a new token scoped to the downstream service.
IDaaS implements Token Exchange as an OAuth 2.0 extension. The new token preserves the original user's identity while restricting audience and permissions to only what the downstream service requires.
What you can do with Token Exchange
Restrict scope — Exchange a token for one with fewer permissions. If the downstream token is compromised, the blast radius is limited to the narrow scope.
Convert token types — Convert between formats such as JWT and SAML for cross-system interoperability.
Propagate identity — Pass the user's identity to downstream services without exposing credentials or requiring re-authentication.
Establish cross-domain trust — Enable secure integration between services in separate trust domains.
How it works
A typical token exchange flow involves four steps:
User authenticates. The frontend authenticates the user through SSO and obtains an access token for Service A.
Service A requests a new token. Service A sends a token exchange request to the IDaaS authorization server. The request includes the original access token as the
subject_tokenand specifies the target audience (Service B).IDaaS validates and issues. The authorization server validates the
subject_token, checks Service A is authorized for the requested audience and scope, and issues a new access token.Service A calls Service B. Service A uses the new token to call Service B. Service B sees the original user's identity in the token, not Service A's identity.
Impersonation semantics
IDaaS uses impersonation semantics for token exchange. The new token fully represents the original user — the requesting service's identity is not included. Audit logs attribute the operation to the original user.
This model applies when a service acts transparently on behalf of the user. For example, an email service sends messages as the user; recipients see the user, not the service, as the sender.
IDaaS supports impersonation semantics only. Delegation semantics (where both the user's and the calling service's identities appear in the token) is not supported.
Use cases
Agent-to-service identity propagation
Consider an enterprise that runs an AI travel-planning agent backed by an HR data service. When an employee asks the agent to plan a trip, the agent needs the employee's job level and travel budget from the HR service.
Without Token Exchange, the agent would call the HR service using its own service account (M2M credentials). The HR service cannot tell which employee is making the request and cannot enforce per-user access policies.
With Token Exchange, the flow works as follows:
The employee authenticates to the travel system and gets an access token scoped to the agent.
The agent exchanges that token for a new one scoped to the HR service, preserving the employee's identity.
The HR service validates the token, confirms the employee's identity, and returns only that employee's data.
The exchanged token (AT_obo) retains the full authorization chain: travel system → agent → HR service. This provides end-to-end traceability for audit.
Limitations
IDaaS-issued tokens only. The authorization server accepts only tokens that it issued. Third-party tokens cannot be exchanged.
Access token to access token only. Other token types (such as refresh tokens or ID tokens) are not supported as input or output.
Client must be authorized. The requesting service must have permission for the target audience and scope.
Token must be valid. The
subject_tokenmust not be expired or revoked.Exchange depth is limited. Tokens can be exchanged only a limited number of times to prevent circular authorization chains.