How to include Authorization Extension data (groups/roles/permissions) into issued tokens?

Help
, ,
1

We are currently trying to prototype a client side SPA connection to a resource API and for some reason the groups/roles/permissions are not being included in the tokens even though we have enabled the settings in the authorization extension.

We assume this is something to do with implicit grants (Implicit Flow with Form Post) and using OIDC but my question is how is a resource server supposed to evaluate whether the users access token has the correct permission to execute a route?

For example:

  1. User logs into client and client authenticates with Auth0 and retrieves a TokenID and an AccessToken (audience set to resource API)
  2. The client then sends a request to the resource server with the access token and is validate successfully
  3. PROBLEM: No groups/roles/permissions are contained in the access token so the route is unable to verify whether it has permissions to execute route??

Any help would great, we would expect the Authorization Extension to take care of this but it looks to be a bug when enabling OIDC?

2

The Authorization extension can be configured to expose the relevant information at the user profile level. This is done through a rule that includes the necessary information in the user profile at each login.

When not relying on endpoints that follow the OIDC specification there is functionality that could automatically populate that authorization information into an issued ID Token if the information was requested through scopes. For example:

  1. You make a request with scope=openid+roles.
  2. The user authenticates and the extension rule populate the user profile with updated roles information.
  3. Given we’re not on an OIDC flow and the request included the roles scope then the roles information available at the user profile is mapped into a roles claim included in the ID Token.

(Important: the above does not work when using OIDC compliant endpoints because roles is not a claim defined by OIDC)

If you’re using an OIDC compliant endpoint which is the case if you’re obtaining access tokens for your own API then you need to explicitly add the custom information available at the user profile into the issued tokens. You do this through an additional rule that should execute after the one associated with the Authorization extension; see User profile claims and scope for details on how to do this.

The way you include the information in the access token is also up to you, for example, you can include the raw role information in a custom claim that your API then processes or as an alternative you can role information to API scopes in the rule itself which would mean the API only performs decisions based on access token scopes and the actual role to scope mapping is done in your custom rule.

1 Like
3

From what I’ve read if we are implementing a SPA and a Resource API then we have to enable OIDC as the access token returned from Auth0 won’t be in a JWT format. This then overrides the Authorization Extension configuration of having Groups/Roles/Permissions included in the Tokens.

Should the Authorization Extension not include these as custom claims instead of having to create another rule to do what the extension was doing before OIDC was enabled?

In regards to scope my understanding is that these are used to define the claims included in the token not for storing permissions?

4

From what I’ve read if we are implementing a SPA and a Resource API then we have to enable OIDC as the access token returned from Auth0 won’t be in a JWT format. This then overrides the Authorization Extension configuration of having Groups/Roles/Permissions included in the Tokens.

Should the Authorization Extension not include these as custom claims instead of having to create another rule to do what the extension was doing before OIDC was enabled?

In regards to scope my understanding is that these are used to define the claims included in the token not for storing permissions?

5

Technically what the extension was doing before it now still does in the same way; what’s not available is automatically mapping of non-standard OIDC claims from the user profile to the ID token.

Given custom claim will require a namespace you now need to do that explicitly. In relation to including the data as access token scopes or custom claims it’s like I mentioned a matter of preference and your specific requirements. I just wanted to keep the options open.

Also, for follow-up to answers use the comment system and/or updates to the original question instead of posting as answers.

6

Hi jmangelo,

Thanks for the response.

I would have expected if both options are enabled (OIDC & Include groups/roles/permissions in token) then the non-standard OIDC claims would have been included in the tokens and named with a default namespace of the Auth0 account. Could someone update the documentation of the extension so its clearer that these are excluded if OIDC is enabled?

For now I’ve just extended a copy of the extension rule so it includes the non-standard claims.

Thanks,

7

Hello John,
Can you explain how you have extended a copy of the extension rule so that the groups/roles/permissions get’s added to the JWT?
I’m struggling with this for a few days now and I can’t get it to work. The documentation about this is very confusing, links pointing to a lot of other pages but not explaining what I really need.

8

Hello John,
Can you explain how you have extended a copy of the extension rule so that the groups/roles/permissions get’s added to the JWT?
I’m struggling with this for a few days now and I can’t get it to work. The documentation about this is very confusing, links pointing to a lot of other pages but not explaining what I really need.

9

Hi w.franssen,
I made a copy of the ‘auth0-authorization-extension’ rule and extended it to include the groups/roles/permissions in the OIDC format. Code snippet below showing changes:

var namespace = 'https://yourdomain.com/';      
context.idToken[namespace + 'permissions'] = data.permissions;
context.accessToken[namespace + 'groups'] = data.groups;
context.accessToken[namespace + 'roles'] = data.roles;
context.accessToken[namespace + 'permissions'] = data.permissions;

Let me know if you have any questions

10

Given the breaking changes of OIDC and the importance of user groups/roles/permissions, i agree with w.frannsen, the documentation is confusing. Prior to creating custom claims, the roles claims could be passed to a .net core backend without any additional configuration.

Now that we must define custom claims with a namespace, we must also receive custom claims in the back-end. That takes extra configuration, THAT WE FIND OUT THE HARD WAY.

11

There’s still some mystery around. How to check in the backend(ex: Spring boot) custom claim?

  JwtWebSecurityConfigurer
                    .forRS256(apiAudience, issuer)
                    ...
                    .antMatchers(GET, "/private").hasRole("MY_CUSTOM_ROLE")

It does not read from the custom defined namespace.