The Client Credentials Grant (defined in RFC 6749, section 4.4) allows an application to request an Access Token using its Client Id and Client Secret. It is used for non interactive applications (a CLI, a daemon, or a Service running on your backend) where the token is issued to the application itself, instead of an end user.

Before beginning this tutorial, please:

• Make sure you that your application has the Client Credentials grant type enabled. Regular web applications and machine to machine applications have it enabled by default.

• Register the API with Auth0 with the required scopes.

• Authorize the application to call the API by creating a Client Grant either using the Dashboard or using the Management API.

To ask Auth0 for tokens for any of your authorized applications, perform a POST operation to the https://YOUR_DOMAIN/oauth/token endpoint with a payload in the following format:

Where:

• grant_type: This must be client_credentials.
• client_id: Your application's Client ID. You can find this value at the application's settings tab.
• client_secret: Your application's Client Secret. You can find this value at the application's settings tab.
• audience: The Identifier value on the Settings tab for the API you created as part of the prerequisites for this tutorial.

The response contains a signed JSON Web Token, the token's type (which is Bearer), and in how much time it expires in Unix time (86400 seconds, which means 24 hours).

If you decode the access_token you will see that it contains the following claims:

You can change the scopes and add custom claims to the Access Token you got, using Hooks.

Hooks allow you to customize the behavior of Auth0 using Node.js code. They are actually Webtasks, associated with specific extensibility points of the Auth0 platform (like the Client Credentials grant). Auth0 invokes the Hooks at runtime to execute your custom logic.

For more information and details on how to do that refer to Using Hooks with Client Credentials Grant.

Once your API receives a request with a Bearer Access Token, the first thing to do is to validate the token. This consists of a series of steps, and if any of these fails then the request must be rejected.

For details on the validations that should be performed by the API, refer to Verify Access Tokens. You can find examples on how to do it in different platforms in the Quickstarts for backend applications.

For an example implementation see the Server Client + API architecture scenario.

This is a series of tutorials that describe a scenario for a fictitious company that wants to implement a Timesheets API and send timesheets entries from a server process using OAuth 2.0. The tutorials are accompanied by a sample that you can access in GitHub.