Overview
Token Exchange is an authentication and authorization mechanism based on the RFC 8693 standard protocol. It allows a client to use an existing security token (subject_token) to obtain a new security token from the authorization server. This feature applies to use cases that require identity propagation, delegated authorization, and least-privilege access.
Technical definition
Token Exchange is an extension specification of the OAuth 2.0 protocol (RFC 8693). It defines a standard HTTP POST endpoint (typically /oauth/token) that allows a subject (Subject/Client) to submit an existing security token (subject_token) to the authorization server (Authorization Server, AS) in exchange for a new security token (access_token or another type).
The token exchange mechanism enables a client to obtain a new token with a different audience, scope, or token type while preserving the identity information of the original subject.
Core capabilities
Capability | Description | Security benefit |
Scope restriction | Obtain a new token with a narrower scope to enforce the principle of least privilege | Limits the impact of a token leak |
Token type conversion | Convert between different token formats (such as JWT to SAML) | Enables interoperability between different systems |
Identity delegation | Perform operations on behalf of different identities, with support for identity chain propagation | Enables fine-grained identity management and audit traceability |
Cross-domain trust | Establish secure collaboration between different trust domains | Enables secure integration between independent systems |
Core concepts
Terms
Term | Description |
Authorization server | The trust center in the OAuth 2.0 protocol that is responsible for authentication, authorization grants, and token issuance. In this topic, it refers to IDaaS. |
Client | The application or service that initiates a token exchange request |
Subject | The independent identity entity on whose behalf business operations are actually performed. In this topic, it refers to an account. |
Subject token | A security token that represents the identity of a subject and is used to prove the identity to the authorization server |
Audience | The value of the aud (audience) field in the payload of a JWT token. It identifies the intended recipient or service of the token. |
Scope | A permission control mechanism used to define the range of accessible resources and the access boundary |
Token exchange | A request that uses a subject token to obtain a security token with a new audience and scope, based on the RFC 8693 standard protocol |
Token exchange semantics
Token Exchange supports two semantic modes:
Semantic type | Technical definition | Audit characteristics |
Impersonation semantics | The newly generated token fully represents the identity of the original token owner. The identity of the initiator is not retained. | Audit logs show that the original token owner performed the operation directly |
Delegation semantics | The newly generated token contains the identity information of both the original token owner and the initiator, forming an identity invocation chain | Audit logs record the identities of both the actual operator and the authorizer |
IDaaS currently supports token exchange based on impersonation semantics only.
Scenarios for impersonation semantics: A backend service performs operations on behalf of a user, and the identity of the service itself does not need to be retained. For example, a mail server sends email on behalf of a user, and the recipient can see only the user as the sender.
Scenarios for delegation semantics: Multi-layer service invocation in a microservices architecture. For example, Service A calls Service B, and Service B then calls Service C. Service C needs to know the identities of both the initial requesting user and the intermediate service for purposes such as throttling and auditing.
How it works
Workflow
Workflow description
Phase | Steps | Description |
Phase 1: Obtain the initial token | 1-3 | The frontend service logs on through SSO to obtain an access token for Resource Server A, and uses the token to request protected resources |
Phase 2: Initiate a token exchange request | 4 | Resource Server A acts as a client and sends a token exchange request to the authorization server |
Phase 3: Authorization server processing | 5-7 | The authorization server verifies the validity of the subject token, checks the access policy, and determines whether to issue a new token |
Phase 4: Use the new token | 8-10 | Use the newly issued token to access Resource Server B and obtain protected resources |
Use cases
Agent identity security scenario
In enterprise Agent service integration scenarios, Token Exchange enables secure identity propagation and delegated authorization.
Scenario description
An enterprise has deployed a travel planning assistant Agent and an HR MCP service. When an employee accesses the Agent through the travel system to plan a trip, the travel planning assistant needs to access the HR MCP service to obtain data such as the employee's job level and travel budget.
Service node mapping
Token exchange workflow | Agent identity security scenario |
Frontend service (Front Service) | Travel system |
Resource Server A | Travel planning assistant Agent |
Resource Server B | HR MCP service |
Authorization server | IDaaS authorization server |
Differences from M2M access
Token Exchange securely propagates authorization to downstream services, such as the HR MCP service, while retaining the subject identity information of the business operation (the employee user). The employee does not need to perform secondary authentication or authorization.
The new token issued by token exchange (AT_obo) fully retains the authorization propagation chain: travel system → travel planning assistant Agent → HR MCP service. This supports complete traceability and audit capabilities.
Limits
Limit | Description |
Token issuance limit | For token exchange, the IDaaS authorization server accepts only tokens that it issued |
Permission limit | The client must be authorized for the target audience and scope |
Token status limit | The subject token must be within its validity period and must be correctly verified by the authorization server |
Exchange count limit | A token can be exchanged only a limited number of times to prevent infinite authorization loops |
Token type limit | Only exchanges between access tokens are currently supported |