OAuth 2.0 Client Credentials Flow for Server-to-Server Integration
Sometimes you want to directly share information between two applications without a user getting in the way. For these scenarios, you can use the OAuth 2.0 client credentials flow. In this flow, the client app exchanges its client credentials defined in the external client app—its consumer key and consumer secret—for an access token. This flow eliminates the need for explicit user interaction, though it does require you to specify an integration user to run the integration. You can use this flow as a more secure alternative to the OAuth 2.0 username-password flow.
Required Editions
| Available in: both Salesforce Classic and Lightning Experience |
| Available in: All Editions |
To use the client credentials flow, you must create an external client app and configure its OAuth settings and access policies.
For example, you build a custom app to run automated reports from Salesforce. You want the app to run reports every night. To integrate your custom app with Salesforce, you set up an external client app. Then, to configure your external client app for the client credentials flow, you enable the flow and assign an integration user. When the nightly report service kicks off, your custom app accesses Salesforce data using these high-level steps.
- The external client app sends its client credentials to the Salesforce OAuth token endpoint via a POST request.
- Salesforce validates the client credentials and authenticates the app.
- Salesforce returns an access token on behalf of the integration user you assigned.
- The external client app uses the access token to call a Salesforce API, such as REST API.
- The API responds with the requested data for the report.
Request an Access Token
Let’s break down the process of getting an access token with the client credentials flow.
To initiate the flow, the external client app posts its client credentials to the Salesforce token endpoint. You can include the client credentials as parameters in the body of the request. Or, for added security, put your client credentials in a Basic authorization header.
Here’s an example POST request with the client credentials in the request body.
POST /services/oauth2/token HTTP/1.1
Host: MyDomainName.my.salesforce.com
grant_type=client_credentials&
client_id=*******************&
client_secret=*******************For this flow, requests to https://login.salesforce.com and https://test.salesforce.com aren't supported. Use your My Domain URL instead. To find your My Domain URL, from Setup, in the Quick Find box, enter My Domain, and then select My Domain.
These parameters must be included in the request.
| Parameter | Description |
|---|---|
client_id |
The consumer key of the external client app. To access the consumer key, from the External Client App Manager, find the external client app and select Edit Settings from the dropdown. Then expand the OAuth Settings section and click Consumer Key and Secret. You're sometimes prompted to verify your identity before you can view the consumer key. |
client_secret |
The consumer secret of the external client app. To access the consumer secret, from the External Client App Manager, find the external client app, and select Edit Settings from the dropdown. Then expand the OAuth Settings section, and click Consumer Key and Secret. You’re sometimes prompted to verify your identity before you can view the consumer secret. |
grant_type |
The OAuth 2.0 grant type that the external client app requests. For
the client credentials flow, this value must be set to
For a detailed explanation of the client credentials grant type, see section 4.4 Client Credentials Grant in The OAuth 2.0 Authorization Framework from the Internet Engineering Task Force. |
Here’s an example with the client credentials in a Basic authorization header. With
this format, the client_id is appended to the client_secret
in the format client_id:client_secret, and the resulting value is
Base64-encoded.
POST /services/oauth2/token HTTP/1.1
Host: MyDomainName.my.salesforce.com
Header: Authorization: Basic
TXlDbGllbnRJRDpNeUNsaWVudFNlY3JldA==
grant_type=client_credentialsIf you use this format, the
grant_type is the only required parameter in the request body. The
grant_type must be set to
client_credentials.
Salesforce Grants an Access Token
After validating the client credentials, Salesforce returns a response containing an access token and requested scopes. The app can use the access token to access protected data in Salesforce.
Here’s an example access token response in JSON format.
{
"access_token": "*******************",
"instance_url": "https://yourInstance.salesforce.com",
"id": "https://login.salesforce.com/id/XXXXXXXXXXXXXXXXXX/XXXXXXXXXXXXXXXXXX",
"token_type": "Bearer",
"scope": "id api",
"issued_at": "1657741493799",
"signature": "c2lnbmF0dXJl"
}These parameters are included in the response.
| Parameter | Description |
|---|---|
access_token
|
OAuth token that an external client app uses to request access to a protected resource on behalf of the client application. Additional permissions in the form of scopes can accompany the access token. |
instance_url
|
A URL indicating the instance of the user’s org. For example: https://yourInstance.salesforce.com/. |
id
|
An identity URL that can be used to identify the org and integration user. The
format of the URL is https://login.salesforce.com/id/orgID/userID. |
token_type
|
A Bearer token type, which is used for
all responses that include an access token.
|
scope
|
The scopes associated with the access token. Scopes further define the type of protected resources that the client can access. You assign scopes to an external client app when you build it, and they’re included with the OAuth tokens during the authorization flow. Because the client credentials flow doesn’t support UI sessions and doesn’t issue a refresh token, Salesforce automatically filters out these scopes.
For more information, see OAuth Tokens and Scopes. |
issued_at
|
Time stamp of when the signature was created in milliseconds. |
signature
|
Base64-encoded HMAC-SHA256 signature signed with the client_secret. The signature can include the
concatenated ID and issued_at value, which you
can use to verify that the identity URL hasn’t changed since the server sent
it. |

