Unify and manage your data

Obtaining access tokens with client credentials grant type

Getting an access token from the Reltio Auth Server using the client_credentials as grant type.

This operation authenticates a user in the system based on the Client ID and client credentials. It returns an access token that will be used in other API requests.

Request

POST https://auth.reltio.com/oauth/token
Authorization: Basic Y2xpZW50X2lkOmNsaWVudF9zZWNyZXQ=
Content-Type: application/x-www-form-urlencoded
Body: grant_type=client_credentials  
Table 1. Parameters
Name RequiredDescription
HeadersAuthorizationYes

The content of the Authorization header should be equals to Basic <Base64 encoded credentials> where <Base64 encoded credentials> is built by concatenating Client ID and Client Secret separate by a colon <client_id>:<client_secret>. The string is encoded in Base64 generating a new set of characters which needs to be put in the header.

Content-TypeYesapplication/x-www-form-urlencoded
Body Parametersgrant_typeYesType of access token request. Value: client_credentials.
Machine-To-Machine (M2M) communication between a 3rd-party application and Reltio requires the application to authenticate the following best practices securely. So, instead of using a common username, a Client ID must be used. This enables better account management and ensures compliance with security requirements.

You can get access using the following methods:

  • Make a request to the Reltio Auth with a Client ID and a client credential (secret). The client can request an access token using only their client credentials when:
    • requesting access to the protected resources under its control
    • requesting access of another resource owner that has been previously arranged with the authorization server
    Make sure that the client credentials grant type is used only for confidential clients.
  • The client authenticates with the authorization server and requests an access token from the token endpoint. The application is authenticated as a client with the default ROLE_API role and a set of arbitrary scopes, which limits its access to the respective API endpoints. No user is associated with the client; however, to maintain the /checkToken request format, a virtual user data is displayed with a username containing Client ID and tenants containing all customer tenants. To enable application access for a client, the client_credentials grant is added to its configuration. Reltio Auth creates an access token for the application user account associated with the client and returns the access token. To include specific roles assigned to a user that will be rendered at the /checkToken endpoint, these roles must be added to the scope field of the client.
    access_token: 24bc1fb5-8440-4d5e-8431-53b7c9a4dc35
  • The application makes the request to the Reltio API with the access token.
Note:
  • Multiple client keys and secret credentials are supported for different application access. Each pair is provisioned for each application rather than being shared.
  • The client key/secret credential enables you to create a new pair and revoke existing ones, over the API. For more information, see topic Create a customer client.

Token API request limit

By default, tokens expire after 60 minutes. To authenticate into Reltio using scripts or integrations, you must get a token, store it, and use it until it expires. Get a new token after the current one expires.

If you don't store your token, you will need to request a token every time you want to authenticate into Reltio. This is a highly inefficient practice. In Reltio, we have a limit of 10 GET token requests per second. If you exceed this limit, you will see the 429 HTTP status (Too Many Request) message. This indicates that you need to change the way you are requesting tokens to ensure it complies with our limit.

Note: To get a new token before the current one expires, enable the Multi Token Support feature. For more information, see topic Multi Token Support.