- 19 Nov 2023
- 1 Minute to read
- Print
- DarkLight
Client Credentials Grant
- Updated on 19 Nov 2023
- 1 Minute to read
- Print
- DarkLight
The OAuth 2.0 client credentials grant flow permits a web service (confidential client) to use its own credentials, instead of impersonating a user, to authenticate when calling another web service. This type is commonly used for server-to-server interactions that must run in the background, without immediate interaction with a user, and is often referred to as daemons or service accounts.
In the client credentials flow, permissions are granted directly to the application itself by an administrator. When the app presents a token to a resource, the resource enforces that the app itself has authorization to perform an action since there is no user involved in the authentication.
Get a token
After you've acquired the necessary authorization for your application, proceed with acquiring access tokens for APIs. To get a token by using the client credentials grant, send a POST request to the /oAuth/rest/v2/Token
Agile.Now identity platform.
Access token request with a shared secret
POST /oAuth/rest/v2/Token HTTP/1.1 //Line breaks for clarity
Host: login.agilenow.io:443
Content-Type: application/x-www-form-urlencoded
client_id=535fb089-9ff3-47b6-9bfb-4f1264799865
&scope=openid%20profile%20name
&client_secret=sampleCredentia1s
&grant_type=client_credentials
Parameter | Required/optional | Description |
---|---|---|
client_id | Required | The application ID that's assigned to your app. You can find this information in the portal where you registered your app. |
scope | Optional | A space-delimited list of scopes that identify the resources the application could access on the user's behalf. Default value is openid profile name .* - gives users all her/his scopes. |
client_secret | Required | The client secret that you generated for your app in the app registration portal. The client secret must be URL-encoded before being sent. The Basic auth pattern of instead providing credentials in the Authorization header, per RFC 6749 is also supported. |
grant_type | Required | Must be set to client_credentials . |
Successful response
A successful response looks like this:
{
"token_type": "Bearer",
"expires_in": 3599,
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzIBP...",
"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA"
}
Error response
An error response (400 Bad Request) looks like this:
{
"error":"Unauthorized",
"error_description":"Client authentication failed.",
"Errors":[
"Client authentication failed."
],
"Type":"/Errors/Unauthorized",
"Title":"Unauthorized",
"StatusCode":400,
"Instance":"/oAuth/rest/v2/Token"
}
Use a token
Now that you've acquired a token, use the token to make requests to the resource. When the token expires, repeat the request to the /oAuth/rest/v2/Token
endpoint to acquire a fresh access token.