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 connected 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 |
See New connected apps can no longer be created in Spring ‘26 for more details.
To use the client credentials flow, you must create a connected 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 a connected app. Then, to configure your connected 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 connected 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 connected 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 connected 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=*******************These parameters must be included in the request.
| Parameter | Description |
|---|---|
client_id |
The consumer key of the connected app. To access the consumer key, from the App Manager, find the connected app and select View from the dropdown. Then click Manage Consumer Details. You're sometimes prompted to verify your identity before you can view the consumer key. |
client_secret |
The consumer secret of the connected app. To access the consumer secret, from the App Manager, find the connected app and select View from the dropdown. Then click Manage Consumer Details. 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 connected 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 a connected 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 a connected 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.
|
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. |
