Group scope in OIDC?

[cdodge]

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.

Any advice? Thanks

[markd]

Hello @cdodge,

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:

Why isn't "Username" brought back in the token?

Hi @mike.griffin, There are probably better ways to code this, but here’s an example rule that adds user.username to the idToken: function (user, context, callback) { user.username = user.username || ""; context.idToken['https://sso.yourdomain.com/username'] = user.username; callback(null, user, context); } The namespace https://sso.yourdomain.com/ can be whatever you want (but not an Auth0 domain). Just needs to be a unique string. Or if, say, you manage your own username in app_meta…

[kim.maida]

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:

This feature is included starting in the Developer pricing tier.

[cdodge]

Thank you Kim,

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.

Thank you again very much for your help

[kim.maida]

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.

The Using Rules with the Authorization Extension docs should be able to provide some additional information on how to go about this.

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?

{
  sub: '[sub]',
  ...,
  groups: '[some value]'
}

or:

{
  sub: '[sub]',
  ...,
  scope:  'somegroupname'
}

or (other)?

Because groups is not a standard OIDC claim, in order to add it to a token directly, Auth0 requires that a collision resistant namespace be used for adding additional claims. This is to conform with OIDC recommendations.

[cdodge]

Yea, while ‘groups’ scope is not part of the spec per se, it does appear to be widely used. For example: okta.com:

Returning Groups in the OpenID connect userinfo API call

Yes, a claims called ‘groups’ and is an array of strings. So the former in the token payload

Thank you very much

[kim.maida]

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!

[cdodge]

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.

Thanks again

[kim.maida]

You’re welcome! Please don’t hesitate to let me know if there’s anything else we can do to help make the implementation painless for you.