Client credentials grant
- Endpoints
The client credentials grant is used when the client is also the resource owner and is accessing its own data rather than acting on behalf of a user. For example, an application that needs access to a protected resource to retrieve its own data to perform a task, or update its configuration, would use the client credentials grant to acquire an access token.
The client credentials grant flow supports confidential clients only.
Client credentials grant flow explained
-
The client sends its credentials to the authorization server to get authenticated, and requests an access token.
-
If the client credentials are valid, the authorization server returns an access token to the client.
-
The client requests access to the protected resources from the resource server.
-
The resource server contacts the authorization server to validate the access token.
-
The authorization server validates the token and responds to the resource server.
-
If the token is valid, the resource server allows the client to access the protected resources.
Obtain an access token using the client credentials grant
Perform the steps in the following procedure to obtain an access token. This procedure assumes the following configuration:
-
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, see Authorization server configuration.
-
-
A confidential client called
myClient
is registered in AM with the following configuration:-
Client secret:
forgerock
-
Scopes:
write
-
Grant Types:
Client Credentials
-
For more information, see Client application registration.
-
The client makes a POST call to the authorization server’s token endpoint specifying, at least, the following parameters:
-
grant_type=
client_credentials
For information about the parameters supported by the
/oauth2/access_token
endpoint, see /oauth2/access_token.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, see OAuth 2.0 client authentication.
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:
$ curl \ --request POST \ --data "grant_type=client_credentials" \ --data "client_id=myClient" \ --data "client_secret=forgerock" \ --data "scope=write" \ "https://openam.example.com:8443/openam/oauth2/realms/root/realms/alpha/access_token"
Note that the
scope
parameter has been included. Scopes are not required, since they can be configured by default in the authorization server and the client, and have been added only as an example.The authorization server returns an access token in the
access_token
property. For example:{ "access_token": "sbQZuveFumUDV5R1vVBl6QAGNB8", "scope": "write", "token_type": "Bearer", "expires_in": 3599 }
-