How can I get permissions into my scope in the access token?

I am using an AWS HTTP API with a JWT Authorizer. The JWT Authorizer can check the “scope” part of the access token to allow execution of the HTTP API endpoint. The scopes defined in the authorizer check the “scope” portion of the access token - if it finds the scope in the access token it allows the client to executed the endpoint.

My Auth0 user has a set of permissions - are they “scopes”? It’s not clear, but these permissions do show up in the access token as an array in the “permissions” part.

How can I get the list of permissions into the “scope” part of the access token so that I can use these permission in the AWS HTTP API JWT Authorizer?

Hi @groffcole,

see


This question came up quite a lot in the past, you can see other related threads here:

https://community.auth0.com/search?q=permissions%20scope%20scope%3D%20user%3Amathiasconradt

@mathiasconradt - Like you’ve referenced, it seems like the best solution is to use a rule that puts the permissions into the scope claim. Is this a recommended solution? I just want to make sure I do things correctly rather than attempting a workaround.

One of the other solutions I was thinking is that I could have separate HTTP APIs for admin and regular user functionality. The different endpoints would authenticate tokens from different audiences - an admin audience and a regular user audience. Then I wouldn’t have to add scopes to the JWT Authorizers. This solution would require double the resources in some cases - fore example, two Auth0 APIs and two AWS HTTP APIs. This might be too whacky to manage.

Any other thoughts?

Thanks.

Any other thoughts?

The other way is to change the JWT Authorizer class on resource server side and let it check the permissions claims instead of scope claim. Not sure about AWS and what they offer, but I assume they allow custom authorizers.

I could have separate HTTP APIs for admin and regular user functionality

How do these roles relate to scope and permissions claim in your scenario? Asking because you didn’t mention them in the initial post. Do these user roles make the authorization request in a different way, or does RBAC only apply to one of them?


Related resources:

I’m attempting to use the new JWT Authorizers in API Gateway - https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html. They are simpler than creating a custom authorizer, which is how things work for the older type of API Gateway in AWS. I could use the older API Gateway and have my own custom authorizer, but I’d like to use the newer stuff. The newer JWT Authorizers don’t allow you to specify where the “scopes” are located in your access token.

As for the admin and regular user functionality, I was thinking that I could have two APIs with different audiences. Then I could have two different JWT Authorizers - they won’t check scopes they will only care about the audience. Does that make sense? I’m basically just trying to protect different endpoints based on “admin” and “regular logged in user” functionality.

Then I could have two different JWT Authorizers - they won’t check scopes they will only care about the audience. Does that make sense?

I’d say all mentioned approaches are valid approaches. One isn’t required to rely on permissions or scopes in tokens or even use the RBAC functionality in Auth0 at all. For all-first-party scenarios (client and backend all provided by you, and where client trusts backend), it’s even valid to handle permissions entirely outside the scope of the tokens.
Therefore, I’d say, whatever works best for you and the components you want to use.

Thank you, Mathias. I appreciate the help.

2 Likes

Thanks for co-operation guys!

@mathiasconradt - The solution I ended up with was this:

  1. For my Auth0 API, I turned on the Enable RBAC feature.
  2. For the configuration of the react-auth0-spa, I made sure to pass a scope that included the permissions I want to return in the scope for any user.

With these two steps only, It causes the permissions to show up in the scope claim.

I’m excited that this solution worked and that it’s simple. I was having a really frustrating time until I realized this works.

2 Likes

Glad you have it figured out!

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