How to specify scopes in an authorize call

Hello, Auth0 community,

Warning: I’m new to Auth0 so be prepared for stupid questions.

I have the following problem and I don’t understand what I’m doing wrong so maybe you can help.

At login I need to retrieve the user’s roles so I follow the documentation here: Auth0 Management API v2

…which says that I need the scopes “read:users read:roles read:role_members”

So my authorize request contains these scopes as you can see below

https://mytenant.eu.auth0.com/authorize?client_id=my_client_id&redirect_uri=http%3A%2F%2Flocalhost%3A4000%2Fauth%2Fauth0%2Fcallback&response_type=code&scope=openid+profile+email+read%3Ausers+read%3Aroles+read%3Arole_members&state=whatever_state

Still, in callback the scopes I’m getting are only “openid profile email”

What am I missing here?

Thanks in advance!

Hey there @o.d welcome to the community!

Can you help me better understand your specific use case here? Typically, roles are added to tokens by way of an Action. If you are looking to get a user’s roles server-side then you will want to request a Management API Access token for use against the Management API.

The more details you can provide about your use case the better :slight_smile:

Thanks for answering!

In the meanwhile the things got a bit more clear for me and I hope I can explain better.

I’m using Auth0 from Elixir and this is why in my question I didn’t show any library calls, because it’s not a popular language and what matters in the end is the HTTP requests sent to Auth0.

What I need to do is to get the user roles from Auth0. I understand that I need to make a call to Auth0 Management API Get-user-roles with the token in the “Authentication” header as a “Bearer ”.

The problem is that when I do so I get a 403 Forbidden error with the message “Insufficient scope, expected any of: read:users,read:roles,read:role_members”. If I decode the token on jwt.io I see this:

{
  "iss": "https://mytenant.eu.auth0.com/",
  "sub": "auth0|66223049b368c7956fdfeabd",
  "aud": [
    "https://mytenant.eu.auth0.com/api/v2/",
    "https://mytenant.eu.auth0.com/userinfo"
  ],
  "iat": 1713786790,
  "exp": 1713873190,
  "scope": "openid profile email",
  "azp": "S1MDQ0d0vXHNOspBV0LwUeYPWrQHUSV8"
}

…for which is pretty obvious that it doesn’t have the required scope.

If I look at the authentication call that was made to Auth0 and I see that the call is specifying the correct scopes:

https://mytenant.eu.auth0.com/authorize?
audience=https%3A%2F%2Fmytenant.eu.auth0.com%2Fapi%2Fv2%2F&
client_id=myclient_id&
redirect_uri=http%3A%2F%2Fmy_url.com%3A4000%2Fauth%2Fauth0%2Fcallback&
response_type=code&
scope=openid+profile+email+read%3Ausers+read%3Aroles+read%3Arole_members&
state=J2S_OE79vKpxAkGBz9M1oySI

Also, please note that I’ve give permissions for my application to call the management API with the scopes read:users,read:roles,read:role_members in Dashboard → Applications → APIs → Auth0 Management API → Settings → Machine to machine applications

And here is where I got blocked. What am I missing here? Why doesn’t the token contain the requested scopes?

Thanks,
ovidiu

No problem, I’m happy to help!

The issue seems to be that you are using an access token of a user as opposed to a Management API Access token - The authorize request shared is that of a interactive (user-involved) flow as opposed to non-interactive (machine to machine). In general, you won’t be able to use a user’s access token against the Management API except for a very limited set of use cases due to security implications (see public vs. confidential clients). A Management API access token when decoded will look something like:

You’ll need to handle requesting a Management API access token on your backend as an entirely separate process to getting a user’s access token. For testing purposes, you can navigate to Applications → APIs → Management AP → Test and choose the relevant application. This will provide you with an example access token for the M2M app which you can use against the Management API to get a user’s roles.

This should help outline the idea at a high level:

Hope this helps!

1 Like

This solved my problem.

So, instead of using the “user access token” received in the OAuth callback, I had to use a “Management API access token”, which is obtained by calling the get-token endpoint of the Authentication API

Thanks a lot for the help!

1 Like

No problem! Thanks for following up :slight_smile: