How to implement the Client Credentials Grant
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 Credentialsgrant type enabled. Regular web applications and machine to machine applications have it enabled by default.
Register the API with Auth0 with the required scopes.
Ask for a token
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:
grant_type: This must be
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 (JWT), 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:
Modify scopes and 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.
Verify the token
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.