Client Credentials grant

The client credentials code grant is described in the rfc 6749. This grant can be used when the authorization scope is limited to the protected resources under the control of the client (an application in OAuth2 vocabulary), or to protected resources previously arranged with the authorization server. Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server.

The flow is described in the following chart:

Step 1: Call the /token endpoint

The first step is a call from the client application to the https://rest.axa-assistance.com/auth/v1/token endpoint by adding the following parameters using the “application/x-www-form-urlencoded” format with a character encoding of UTF-8 in the HTTP request entity-body.

Example calls (please replace the client_id and client_secret with your own):

curl -X POST 'https://rest.axa-assistance.com/auth/v1/token' -H 'Content-Type: application/x-www-form-urlencoded' -u 'client_id:client_secret' -d 'grant_type=client_credentials' --data-urlencode 'scope=urn:axa.assistance.travel.countries.read_only'

Passing the client_id and client_secret with the -u parameter will result in the following call being made (please note the Authorization header):

POST /auth/v1/token HTTP/1.1
Host: rest.axa-assistance.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
scope=urn:axa.assistance.travel.countries.read_only

Let’s take a look at the parameters involved:

  • grant_type=client_credentials: it indicates that the client credentials grant type is being used
  • scope=urn:axa.urn:axa.assistance.travel.countries.read_only: these scopes specify the access rights that the resulting access_token must be granted. In this case, the application will only get access to read the list of countries. Additional scopes can be specified, and must be separated by a white space
  • client_id:client_secret: Client application ID and secret, retrieved from the development portal.

Step 2: Use the APIs

If the access token request is valid and authorized, the authorization server will issue an access token. An example of a successful response:

{
  "access_token":"eyJ0eXAi...",
  "token_type":"Bearer",
  "expires_in":3600,
  "scope":"urn:axa.assistance.travel.countries.read_only"
}

The access_token value is the one that will grant access to the apis. It’s actually a JWT. This token can be used to call the apis that are authorized by the scopes that this token was granted.

Let’s take a look at this jwt example.

It’s divided in 3 segments split by a “.”:

  • The first segment of the JWT contains the information regarding the signing algorithm.
  • The second segment contains the token information. There you will find the username in sub.value. As a unique ID to identify a user, we strongly suggest to use: customData.cn.
  • The third segment contains the signature of the first and the second segment using the signing algorithm. The signature should always be verified to ensure that the data have not been tampered.

Example call:

curl -X GET -H "Content-Type: application/json" -H "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhb......GciOiJSUzI1N" "https://rest.axa-assistance.com/travel/v1/countries"