Hello, I’m new to Auth0, but I’ve certified my OIDC compliant application against Okta and I’m trying to do the same with Auth0. Apologies if this is a commonly asked question,.
Although I’m getting through the OIDC handshake, I’m having trouble getting Auth0 send the “groups” scope. While “groups” may not be part of the OIDC spec, it does seem to be widely used in the industry.
Is there formal support in Auth0 for the “groups” scope? If not, is there a work around? I see that we can add custom attribute/claims, but I’d prefer not to have to change my client code to make additional round-trips and parse out payloads specific to a particular SSO-as-a-service provider. So far Okta and OneLogin seem to honor the “groups” scope.
For attributes that are not part of the standard scopes, you can add custom claims to your token using rules. You can see an example at the link below:
You can also use the authorization extension to configure groups, roles, and permissions in Auth0. In the extension configuration, you’ll see a Dashboard that has some options as follows:
I added the Authorization Extension and now I’m at the point where if I “try” the rule that was generated by Authorization Extension in the Rule editor it works (I see the groups I mapped by user to in the extension), but still on the /UserInfo response after OIDC handshake, it’s still missing.
Is there something left to do to map it to the output on the UserInfo OIDC response?
Also, the response on the Rule tester is different (but similar in some ways) than what I see from my OIDC based called to UserInfo, so it seems like there’s some intermediate mapping going on.
Do you see the groups in the user’s app_metadata in the Users section of your Dashboard if you view their details after logging in as one of the users that you assigned to the group?
In order to grab the contents of the app_metadata groups/roles/permissions in the ID token (the payload of which is returned by the /userinfo endpoint), you’ll want to add a Rule to add the authorization extension’s data to custom claims in the ID and/or access token.
I’m not entirely sure what you mean by “groups scope” in your original message; are you referring to a token claim called groups? (This is not the same as scopes; if you’re interested in utilizing scopes, we can certainly talk about that too!)
Are you expecting this result in your token payload?
Although widely used, if you are using an OIDC conformant client, adding non-standard custom claims that are not collision-resistant is not supported. Please see this related answer for more details.
Adding the collision-resistant namespace does solve this issue while adhering to OIDC recommendations, and I’m happy to help you implement that, if it’s an option for you!
Thanks for all of your help Kim. It seems like I’ll need to update our client to add a Auth0 specific bit of code to look for the groups information elsewhere in the payload.