Token Exchange Flow
The Token Exchange flow (defined in RFC 8693) enables applications to exchange one type of token for another. This is particularly useful in scenarios like delegation, impersonation, or when you need to convert tokens between different formats or security contexts.Overview
This flow allows a client to request a new security token by presenting an existing token. Common use cases include:- Delegation: Acting on behalf of another user or service
- Impersonation: Assuming the identity of another entity
- Token translation: Converting tokens between different formats or contexts
- Service-to-service communication: Exchanging user tokens for service-specific tokens
Flow Steps
- Obtain Initial Token: Acquire a subject token (e.g., from another OAuth flow)
- Token Exchange Request: Submit the subject token to the token endpoint with the token exchange grant type
- Receive New Token: Obtain the exchanged token with appropriate scope and audience
- Access Resources: Use the new token to access protected resources
Implementation
Prerequisites
Before starting, you’ll need:- Your application’s
client_idandclient_secret - A valid subject token (the token you want to exchange)
- The token endpoint:
https://login.camall.io/oauth/token - Target audience or resource identifier (optional)
- Requested token type (optional)
Step 1: Obtain a Subject Token
First, acquire a token using another OAuth flow (e.g., Authorization Code, Client Credentials, or Device Code flow). This will be your subject token.Step 2: Initiate Token Exchange
Exchange the subject token for a new token with different properties:grant_type=urn:ietf:params:oauth:grant-type:token-exchange: Specifies token exchange flowsubject_token: The token being exchanged (required)subject_token_type: Type of the subject token (required)urn:ietf:params:oauth:token-type:access_token- OAuth 2.0 access tokenurn:ietf:params:oauth:token-type:refresh_token- OAuth 2.0 refresh tokenurn:ietf:params:oauth:token-type:id_token- OpenID Connect ID tokenurn:ietf:params:oauth:token-type:jwt- JSON Web Token
client_id: Your application’s client IDclient_secret: Your application’s client secretscope: Requested permissions for the new token (optional)resource: URI of the target service (optional)audience: Logical identifier of the target resource (optional)requested_token_type: Type of token being requested (optional)
Step 3: Exchange with Actor Token (Delegation)
For delegation scenarios where one entity acts on behalf of another:actor_token: Token representing the entity acting on behalf of the subjectactor_token_type: Type of the actor token
Step 4: Exchange with Specific Audience
Request a token for a specific target service:audience: Logical name of the target serviceresource: Physical location of the target resource
Step 5: Use the Exchanged Token
Make authenticated API requests using the exchanged token:Complete Example Script
Here’s a complete bash script demonstrating the token exchange flow:Token Type Reference
Subject Token Types
urn:ietf:params:oauth:token-type:access_token- OAuth 2.0 access tokenurn:ietf:params:oauth:token-type:refresh_token- OAuth 2.0 refresh tokenurn:ietf:params:oauth:token-type:id_token- OpenID Connect ID tokenurn:ietf:params:oauth:token-type:saml1- SAML 1.1 assertionurn:ietf:params:oauth:token-type:saml2- SAML 2.0 assertionurn:ietf:params:oauth:token-type:jwt- JSON Web Token (JWT)
Requested Token Types
urn:ietf:params:oauth:token-type:access_token- OAuth 2.0 access token (default)urn:ietf:params:oauth:token-type:refresh_token- OAuth 2.0 refresh tokenurn:ietf:params:oauth:token-type:jwt- JSON Web Token (JWT)
Use Cases
Delegation Scenario
A user delegates access to a service to act on their behalf:Service-to-Service Communication
Exchange a user token for a service-specific token:Security Best Practices
- Validate tokens: Always validate subject and actor tokens before exchange
- Limit scope: Request only the minimum necessary permissions
- Specify audience: Use the audience parameter to limit token usage to specific services
- Short-lived tokens: Exchanged tokens should have limited lifetime
- Use HTTPS: All endpoints must use HTTPS in production
- Secure credentials: Never expose client secrets in client-side code
- Audit exchanges: Log token exchange operations for security monitoring
- Validate token types: Ensure subject_token_type matches the actual token format