Getting a Bearer token to access a production API with Postman

I am developing a site with a frontend (React) and a backend (Flask). I’m using Auth0 to manage login on both sides. I have created

  1. An Auth0 Web Application
  2. An Auth0 API
  3. An Auth0 Machine-to-Machine Application

App #3 is linked to API #2 and the Auth0 Management API. Both are marked “Authorised” in the “APIs” tab. The token expirations for API #2 are the defaults, 86400 and 7200.

When the web application calls the API’s endpoints, is gets a bearer token from getAccessToken() in the nextjs-auth0 library. Both locally and in production, the environment variables reference the CLIENT_ID/CLIENT_SECRET of the Web Application #1. This works well both locally and in production.

When I want to call my own API endpoints directly, I need to add a Bearer token to the Postman calls. I have tried “cheating” and simply printing the bearer token above and then using that in Postman. This fails with 401 “token is expired” both locally and in production. The error is generated by the requires_auth() method in the API code which I have copied verbatim from the Python API Quickstart.

After some reading, it seemed like perhaps the right solution is to use the Client Credentials Flow on the command line to fetch a token which I can paste into Postman. There are instructions in the “Test” tab of the API #2 above. So I have selected the M2M application #3 from the popup button and used the sample code there to fetch a token using the provided values:


It returns a different token which nevertheless fails with a 401 ExpiredSignatureError. When I look at the JWT itself using, it says that the token expires tomorrow, 24 hours after it was issued. The site tells me “Signature Verified.” The audience in the returned token is the API identifier which I passed above, which is the audience I’m checking for in the backend API.

The tenant is set to Development. Ultimately, the production environment will presumably need a separate Production tenant. But I don’t see how that will solve anything, since I would still be in the same situation with the 3 apps and /oauth/token issuing me tokens which don’t seem to be valid.

What am I doing wrong?? Is there something besides the expiry date itself which can cause PyJWT to throw an ExpiredSignatureError?

Hi @nk9,

Thanks for reaching out to the Auth0 Community!

This is correct. You’ll want to use the client_credentials flow to obtain an access token and call your API with that token.

Now, I understand that you’ve mentioned that the token expirations for your API are set to the default values, and this will seem redundant, but could you please double-check the following:

  • Your API Token Expiration values are set large enough. Might even be worth using a new number and saving the changes. (i.e 86401)
  • Your API Audience must match the Audience you used during the client_credentials flow

I have just been testing this for some time and have not been able to reproduce your error unless I change my Token Expiration time to a short duration, something like 10 seconds. This leads me to believe that the token itself has expired and can be corrected by changing the Token Expiration setting.

You could also try using the access_token that is generated in the Response in the API>Test Tab to see if that resolves your issue.

Please let me know how this goes for you.

Thank you.

1 Like

Thank you very much for engaging with this and your suggestions. I have figured out what the problem was: Postman requires you to save the Collection Folder after you update the Token value.

So I was changing the Token again and again but since I hadn’t saved, Postman was still providing a token from days ago. This token had obviously expired! (This has bitten me before, and honestly their model is totally confusing.) But now that I’m saving, the token is working on the backend both locally and in production. I wasn’t paying close enough attention to the value of the delivered token when I was trying to debug the API, or I would have caught this much sooner.

Hope my experience can help someone else in the future!

Hi @nk9,

Thank you for your quick response!

We’ve all been there with Postman! I’m so glad you were able to resolve the issue.

Please let me know if there’s anything else I can do to help.

Have a great rest of your day.

Thank you.

1 Like

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