Receiving Opaque Token Instead of JWT Using Client Credentials Grant

Help
,
1

Hello Auth0 Community,

I’m currently encountering an issue where I receive an opaque token instead of the expected JWT when using the client credentials grant to authenticate against my API. I’ve verified that my API configuration and the audience parameter are correctly set up in the Auth0 dashboard, yet the issue persists. Below is the curl command I’m using to request the token:

curl --request POST
–url ‘https://{DOMAIN}/oauth/token’
–header ‘content-type: application/json’
– data grant_type: “client_credentials”
– data client_id: “CLIENT_ID”
– data client_secret: “CLIENT_SECRET”
– code: url parameter code
– data redirect_uri: “https://APP/callback”
– data audience: “API_IDENTIFIER”

I’ve ensured the following:

  • The audience parameter matches exactly the API identifier set in the Auth0 dashboard.
  • I’m using Wized to do the request.

Given this setup, I was expecting to receive a JWT to facilitate API access, but instead, I receive an opaque token. This outcome is puzzling, especially since the audience parameter is correctly specified, which typically triggers JWT issuance.

Could anyone provide insights or suggestions on what might be causing this issue or what further steps I could take to diagnose and resolve it? Any advice on additional configurations to check or common pitfalls to avoid would be greatly appreciated.

Thank you in advance for your help!

3

Hey there @B.KAN welcome to the community!

Hmm that’s odd :thinking: What makes you think it’s opaque? Do you see any claims (iss, sub, aud, etc.) when you paste the token in jwt.io? Is there a reason you are passing a redirect_uri as it’s not a required (nor relevant) in a client credentials exchange.

4

Hey @tyf!

Thank you so much for your response!

I realize now that my initial message was missing some crucial information that I have updated now, and I appreciate your patience. Let me address your questions:

  1. On the Token Being Opaque: The reason I believed the token to be opaque is based on the format of the response I received from my curl request. Here’s a redacted version of the token for privacy:
      "access_token": "eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIiwiaXNzIjoiaHR0cHM7Ly8kZXYtbjdjaHhsdWpjYnUwaGpvay5ldS5hdXRoMC5jb20vIn0..v56QqsldVs4O65u4.tDkvOBYxdcVPSAfSuczi9O4h-hfr0xNhHGasjFO2gjabA3X2YDCoW4G34Wo6vSp-FM-vYyIgB8GkHLqedyvtXPAKFbeH4C5Hz3e2fE1IkGjEnvy_oWok0gNKs6YSCTlc7mB4tf-cs4iMHX7AMdxaszsS6Dd1sNkfhk9Oj7Bw076ys_BdInXHU3dFpeGTQN3-I9Vw7nw2z8Xla93IP37RggY1zvjNpffjYR3U6zgEOueqL1YJ36xyM67JQWUQG24PhQmDZU3BsLXGEkQaBr1HhJfe5d6lYz9m1Ytuhp_wfLZjxDPFk-w.j7Hpre1s50JcBHg-fx3A0A
      "expires_in": 86400,
      "token_type": "Bearer"

When I attempted to decode this token on jwt.io, it indicated an invalid signature. Furthermore, the structure of the token, notably the presence of two consecutive periods (…) led me to understand it as opaque, according to this documentation Link opaque token I consulted.

  1. Regarding the redirect_uri Parameter: Your point about the redirect_uri not being required or relevant in a client credentials exchange is well-taken. I included it following the documentation about the “Call Your API Using the Authorization Code Flow” Call Your API Using the Authorization Code Flow.

I hope this clarifies the confusion and gives more insight into the issues I’m facing. If there are any further steps I can take or additional details I can provide to resolve this matter, please let me know. Your guidance is greatly appreciated!

5

Great, thanks for confirming! Happy to help :slight_smile:

The authorization code flow referenced there is a user based flow, whereas client credentials doesn’t involve a user. Have you tried constructing a cURL request based on the example here?

6

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