---
title: Client credentials grant
description: /oauth2/access_token
component: pingam
version: 8.1
page_id: pingam:am-oauth2:oauth2-client-cred-grant
canonical_url: https://docs.pingidentity.com/pingam/8.1/am-oauth2/oauth2-client-cred-grant.html
keywords: ["OAuth 2.0", "Endpoints", "Authorization", "Clients", "Grant Flow", "REST API"]
page_aliases: ["oauth2-guide:oauth2-client-cred-grant.adoc"]
section_ids:
  oauth2-client-credentials-demo: Demonstrate the client credentials grant flow
  prepare-demo-client-credentials: Prepare the demonstration
  proc-token-client-credentials: Get an access token using the client credentials grant
---

# Client credentials grant

* Endpoints

  * [/oauth2/access\_token](oauth2-access_token-endpoint.html)

The client credentials grant is intended for clients who are also resource owners that need to access their own data rather than acting on behalf of a user.

For example, an application that needs access to a protected resource to update its configuration might use the client credentials grant to get an access token.

The client credentials grant flow supports confidential clients only.

![AM supports the client credentials grant.](_images/oauth2-client-cred.svg)Figure 1. OAuth 2.0 client credentials grant flow

1. The client sends its credentials to the authorization server to authenticate and requests an access token.

2. If the client credentials are valid, the authorization server returns an access token to the client.

3. The client requests access to the protected resource from the resource server.

4. The resource server contacts the authorization server to validate the access token.

5. The authorization server validates the token and responds to the resource server.

6. If the token is valid, the resource server allows the client to access the protected resource.

## Demonstrate the client credentials grant flow

Perform these steps to get an access token:

1. [Prepare the demonstration](#prepare-demo-client-credentials)

2. [Get an access token using the client credentials grant](#proc-token-client-credentials)

### Prepare the demonstration

Complete these steps to prepare the client credentials grant flow demonstration:

* AM is configured as an OAuth 2.0 authorization server. Ensure that:

  * The `Client Credentials` grant type is configured in the Grant Types field.

  For more information, refer to [Authorization server configuration](oauth2-configure-authz.html).

* A confidential client called `myClient` is registered in AM with the following configuration:

  * **Client secret**: `mySecret`

  * **Scopes**: `write`

  * **Grant Types**: `Client Credentials`

For more information, refer to [Client application registration](oauth2-register-client.html).

### Get an access token using the client credentials grant

As the client, call [/oauth2/access\_token](oauth2-access_token-endpoint.html) specifying the client's credentials and `grant_type=client_credentials`.

Confidential clients can authenticate to the OAuth 2.0 endpoints in several ways. This example uses the following form parameters:

* **client\_id**=*your-client-id*

* **client\_secret**=*your-client-secret*

For more information, refer to [OAuth 2.0 client authentication](oauth2-client-auth.html).

If the OAuth 2.0 provider is configured for a subrealm rather than the Top Level Realm, you must specify it in the endpoint. For example, if the OAuth 2.0 provider is configured for the `/alpha` realm, use `/oauth2/realms/root/realms/alpha/access_token`.

For example:

```bash
$ curl \
--request POST \
--data "grant_type=client_credentials" \
--data "client_id=myClient" \
--data "client_secret=mySecret" \
--data "scope=write" \
"https://am.example.com:8443/am/oauth2/realms/root/realms/alpha/access_token"
```

|   |                                                                                                               |
| - | ------------------------------------------------------------------------------------------------------------- |
|   | The `scope` parameter is optional if default values are configured in the authorization server or the client. |

The authorization server returns an access token, for example:

```json
{
  "access_token": "<access-token>",
  "scope": "write",
  "token_type": "Bearer",
  "expires_in": 3599
}
```