Token Exchange Flow Use Cases
To decide if the OAuth 2.0 token exchange flow is the right solution for your company, learn more about when to use it.
Required Editions
| Available in: Enterprise, Performance, Unlimited, and Developer Editions |
When an enterprise system includes multiple service providers and an external identity provider, use the token exchange flow to integrate Salesforce without making it the center of your integration pattern.
For example, suppose your company hosts conferences with external speakers. You host an event management platform that includes many components.
- An enterprise identity provider, such as Okta, that provides identity services such as login, registration, and password reset.
- Multiple service providers such as SAP, Concur, and other CRM apps that provide various services to speakers. For example, the portal integrates with Concur so speakers can log expenses.
- A microservice infrastructure that serves data to speakers. For example, the portal uses Amazon Web Services to show speakers their schedule.
In this system, to give the platform access to data, services are built around the identity provider. After the user logs in, the platform gets an access token from the identity provider. To give customers access to data served by the service providers or microservices, the platform exchanges this access token for a token that grants access to the specific data they requested.
With the token exchange flow, use this same pattern to integrate Salesforce. Take a token from the identity provider—an access token, refresh token, JSON Web Token (JWT), ID token, or SAML 2.0 assertion. Validate it in Salesforce and map it to a Salesforce user. When the exchange is complete, the user has a Salesforce access token, plus any other Salesforce tokens that are requested. For example, to give speakers a way to log Support cases using Service Cloud, integrate Salesforce using the token exchange flow. Speakers can access their Service Cloud data in the platform.
Without the token exchange flow, integrating Salesforce is much more complicated. If all services except Salesforce accept tokens from the identity provider, then the pattern must be redesigned around Salesforce. For example, Salesforce integrates with Okta, and then all services accept tokens from Salesforce. When this pattern isn’t realistic, the token exchange flow is a simpler, more compatible alternative.
This flow is supported for your org-specific My Domain login URL (for internal users, also known as employees) and your Experience Cloud sites (for external users, also known as customers and partners).
How it Works
At a high level, here’s how the token exchange flow works.
Before the flow starts, the user is logged in to your platform and already has a token from the identity provider.
- Within your platform, the user requests access to protected Salesforce data.
- The platform sends a token request to the Salesforce token endpoint.
- Salesforce uses a token exchange handler to validate the token and map it to a Salesforce user. If no user exists, the handler can be configured to create one. You control the validation and subject mapping processes.
- Salesforce returns an access token to the platform, along with any other requested tokens.
- The platform uses the access token to make an authenticated request for Salesforce data. The end user can now access their Salesforce data in your platform.
Next Steps
If the token exchange flow sounds right for your use case, get started with its setup.
