Groups and roles not returned to client application

Help
, , , ,
1

I’ve turned on the Authz extension and added groups, roles and permissions. I’ve attached the Roles and Permissions to my client. I’ve selected to have the groups and roles returned in the Token as well as persisted to app_metadata. My client is set to NOT be OIDC Conformant.

The groups and roles are correctly saving to app_metadata but they are not returned in the JWT when using the xxxxxx.auth0.com/login URL:

https://xxxxxx.auth0.com/login?client=xxxxxxxxxxxx&protocol=oauth2&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fcallback&scope=openid&response_type=code&state=xxxxxxxxxxxxxxx

I’ve tried changing the scope parameter to scope=openid groups roles as mentioned in multiple places in the documentation. I’ve tried adding my own rules to explicitly add the groups and roles.

Nothing seems to work.

Anyone else had trouble getting this to work with the sample Java Application?

2

I could not reproduce this situation in a general application and there should be nothing specific to a Java application that would influence this. As you already mentioned the contents of the issued tokens can be influenced by the requested scopes and/or if the request is being handled in an OIDC compliant way.

You mention that your client applications is not flagged for OIDC Conformant, however, have in mind that this, by itself, does not imply that the request is not being processed in a compliant way. For example, if you include an audience parameter then you automatically get OIDC compliant behavior no matter the flag; see the reference docs for more info on this.

Depending on the mode in which the request is being processed you either need to:

  • for non-OIDC, include the groups and roles as properties in the user objects (the authorization extension rule does this by default) and include groups and roles as scopes that you specify in the request.
  • for OIDC, create a rule that runs after the authorization extension one and sets custom claims in the issued tokens based on the information at the user object; for example, context.idToken"https://myapp.example.com/roles"] = user.roles. The custom claims need to be namespaced so check the reference docs.

Finally, as mentioned before, nothing of the above is specific to a particular client application technology so I would recommend you to analyse the issued tokens in jwt.io as that way you can know for sure if the problem is the information not being included in the tokens or if the client application is not correctly processing it. If it’s the latter, then update the question with more details about the client application itself.