Access token for machine-to-machine API

I’m confused about how to configure a “Custom API” on my tenant dashboard so that it can make calls to the “Auth0 Management API”. For example, I want my API to collect “users” from the “Auth0 Management API”.

I’ve added a special “Application” on my tenant dashboard whose only role is to provide a client_id and client_secret so that I can perform a POST to get an access token from Auth0. This Application has no other use for me. I store the resulting token in the local state of my backend service and use that to access the “Auth0 Management API”. It looks like I need to handle token expiration and so on, since I expect my backend to run for long periods (more than a day) and I currently only perform this access at startup.

Is this the preferred/only way to get an access token that my backend service can use to access the “Auth0 Management API”? I was hoping for a mechanism that I could enable once at configuration/setup and then leave alone.

Thanks,
Tom S.

Hey there @tms!

Assuming your backend is requesting management API tokens, you don’t need to configure another API in your dashboard. The audience is the management API identifier itself, so https://YOUR_DOMAIN/api/v2/

https://auth0.com/docs/secure/tokens/access-tokens/get-management-api-access-tokens-for-production#get-access-tokens

1 Like

Here is the request I make (using an Application created for just this) that works:

const requestData = `{"client_id":"<client_id>","client_secret":"<client_secret>","audience":"https://0-0-zeetix.us.auth0.com/api/v2/","grant_type":"client_credentials"}`
const url = `https://0-0-zeetix.us.auth0.com/oauth/token`;
const tokenOptions = {
  method: 'POST',
  url: url,
  headers: { 'content-type': 'application/json' },
  data: requestData
};
response = await axios.request(tokenOptions)

I tried removing the client_id and client_secret parameters as per your response, as follows:

const requestData = `{"audience":"https://0-0-zeetix.us.auth0.com/api/v2/","grant_type":"client_credentials"}`
const url = `https://0-0-zeetix.us.auth0.com/oauth/token`;
const tokenOptions = {
  method: 'POST',
  url: url,
  headers: { 'content-type': 'application/json' },
  data: requestData
};
response = await axios.request(tokenOptions)

When I run the latter, I get an error response:

"Request failed with status code 401"

It may be irrelevant, but I also notice that in the “Machine to Machine Applications” tab of the “API” section of my tenant dashboard, the only entries are for “Applications” (with a client_id and client_secret").

I fear I misunderstand something basic here, so please tolerate my confusion.

1 Like

Thanks for following up!

As you’ve noticed, you will need client credentials (client id + secret) in order perform a client credentials exchange for an access token. I was referring to the fact that you don’t need to create another API in your dashboard - You do however need to have a m2m application created (where client ID and secret are generated) AND authorize that app in the Management API settings of your dashboard. This is done in the Machine to Machine Applications tab that you mentioned.

The following documentation outlines the concept of using an M2M app to to call an API - The only difference is that instead of calling your own API, you are using the M2M app to retrieve an access token to call the Auth0 Management API.

I don’t need to create another API in the dashboard, but it appears that I do need to create a separate Application – of type Machine-To-Machine – whose only function is to provide a client_id and client_secret.

I have a backend API. I already have an Application of type SPA. When I use the client_id and client_secret of that SPA Application, I get a 403 complaint in response to the token request.

I therefore gather that each API I create (I have two so far) requires a Machine-To-Machine Application instance, and I then need an additional SPA Application for each front-end that I use.

I’m not complaining, I’m just trying to mirror my learnings.

It would be awesome if there was a single documentation URL where these sorts of constraints were presented in a more organized way.

Thanks for following up @tms!

It is not recommended that SPAs request management API tokens for reasons outlined here. The M2M approach essentially allows your backend to proxy requests on behalf of your SPA, keeping the client id and secret safe. This use case is outline here:

You should be able to utilize a single M2M app and authorize it for multiple APIs.

Ah, got it – a single M2M app authorized to provide a token for each API.

That makes all kinds of sense.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.