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?
@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.
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?
I’m attempting to use the new JWT Authorizers in API Gateway - Controlling access to HTTP APIs with JWT authorizers - Amazon API Gateway. 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.