Auth0 Support for API Keys and Personal Access Tokens

Knowledge Articles
, , ,
1

Last Updated: Jul 11, 2025

Overview
This article clarifies Auth0’s position on the use of API keys and Personal Access Tokens (PATs). It explains that while Auth0 does not offer a native PAT system, equivalent functionality for API keys can be achieved using the Client Credentials Grant with a Machine-to-Machine (M2M) application.

Applies To

  • API Keys
  • Personal Access Tokens (PAT)
  • Machine-to-Machine (M2M) Applications
  • Client Credentials Grant

Cause
Auth0 does not provide a built-in feature for Personal Access Tokens (PATs) similar to those found on platforms like GitHub. For programmatic access typically associated with API keys, the functionally equivalent method in Auth0 is to use the credentials of a non-interactive, Machine-to-Machine (M2M) application.

The primary distinction is that traditional API keys are often static credentials validated directly by an API. In the Auth0 model, the M2M application’s client credentials are used to obtain a short-lived JSON Web Token (JWT) from the authorization server, and this token is then sent to the API for validation.

Solution
To implement a secure, API key-like authentication model for programmatic access, create and use a Machine-to-Machine (M2M) application.

  1. Register a Machine-to-Machine Application: In the Auth0 Dashboard, navigate to Applications and create a new application, selecting Machine-to-Machine Applications as the type. For more information, see Register Machine-to-Machine Applications.
  2. Authorize the Application: Grant the M2M application the necessary permissions (scopes) to access the required API.
  3. Use Client Credentials for a Token Exchange: Use the Client ID and Client Secret from the M2M application to perform a Client Credentials Grant. This involves making a POST request to the /oauth/token endpoint to receive an access_token. For more information, see Call Your API from a Machine-to-Machine App.
  4. Call the API: Use the obtained access_token as a Bearer token in the Authorization header of requests to the protected API.

NOTE: The Client ID and Client Secret are confidential credentials and must be stored securely in the client application.

6 Likes