I’m using a client credentials flow to access the Management API. I’ve configured the settings such that my M2M app is authorized to request access tokens for the Management API, and it has all available permissions. I’ve decoded the token at jwt.io and ensured it has all possible scopes, and the audience is the Management API identifier.
The issue appears to have something to do with the domain. My domain looks like this: {tenant-name}.us.auth0.com.
I’m performing the client-credentials token request using the audience: https://{tenant-name}.us.auth0.com/api/v2/
When I make a GET request to /api/v2/clients I get a 400 error - bad request
if I make the request to the same endpoint, but removing ‘.us’ from the domain, I get a 401:
I tried doing it that way. The behavior is exactly the same.
If I send a request where the domain matches what’s in the audience, I get a 400 bad request. If I remove the ‘.us’ from the domain, I get 401 Unauthorized: Bad audience (because the audience still has the ‘.us’ in it?).
Audience: https://{tenant-name}.us.auth0.com/api/v2/
GET request to any API endpoint beginning with this returns 400 Bad Request
GET request to any API endpoint beginning with thishttps://{tenant-name}.auth0.com/api/v2/ returns
I found a solution, but I don’t understand the problem. My actions-flow added some custom claims to the token. When I removed the action, it worked as expected.
I don’t understand why having custom claims would affect the ability to access the Management API. If anyone can tell me what’s going on that would be helpful. Thanks!
EDIT:
Originally, the action set the custom claims to include every scope as a key with “true” as the vaue. In this case there were lots of scopes, so there were many key-value pairs in the custom claims. I altered the action so there are less items in the custom namespace claims. Now it works again. Is there some documentation missing about how many claims are allowed? Or is this an issue worth investigating?
The access token is passed as a bearer token in an HTTP header. The standard doesn’t specify a size limit, but web browsers impose a limit. If the access token was larger than 8K, that probably was the issue.