Okta Workforce Connection does not contain groups

[david77]

We use Auth0 as our identity provider and have a partner who uses Okta. We are attempting to setup Auth0’s Okta Workforce connection SSO provider configuration.

We have everything setup correct – meaning that we are able to redirect to their Okta login and redirect back to our application with the user authenticated.

Issue

The issue is we do not get the groups during the transaction with Auth0. I have read through several Auth0 forum posts about this. This one being the most notable which says that Okta does not send groups from the Workforce connection.

Symptoms
We are not seeing any group information in users’ profiles/tokens.
Cause
The Okta Workforce connection only supports the basic profile and ignores other claims.

I also read a post from Okta’s forum about the same issue. However, this reply makes it seem like Okta should be respecting the scope=group parameter.

That expression should, at the very least, return the “Everyone” group…

What We Have Configured

We have this configuration in our Auth0 connection with Okta:

I had our partner capture a .har file of the entire login flow so I could verify that we are in fact sending the groups scope.

https://{parterns-domain}.okta.com/oauth2/v1/authorize?scope=%20openid%20email%20profile%20groups&client_id=some-hash&response_type=code&redirect_uri=https%3A%2F%our-tenant.auth0.com%2Flogin%2Fcallback&response_mode=query&code_challenge=some-hash&code_challenge_method=S256&state=some-hash

However, when I check the user in my Auth0 dashboard after they have authenticated, I only see these fields mapping from the Okta login (these correlate to the attributes.* in the json in the image above):

{
  "email": "first.last@company.io",
  "federated_locale": "US",
  "federated_zoneinfo": "America/Los_Angeles",
  "name": "firstname.lastname",
  ...other auth0 fields
}

Note how we are getting the federated_locale and federated_zoneinfo but not the federated_groups.

From the auto-populated Okta metadata json file, it looks like groups should be a supported scope:

{
  "issuer": "https://{parnters-tentant}.okta.com",
  "jwks_uri": "https://{parnters-tentant}.okta.com/oauth2/v1/keys",
  "token_endpoint": "https://{parnters-tentant}.okta.com/oauth2/v1/token",
  "claims_supported": [
    "iss",
    "ver",
    "sub",
    "aud",
    "iat",
    "exp",
    "jti",
    "auth_time",
    "amr",
    "idp",
    "nonce",
    "name",
    "nickname",
    "preferred_username",
    "given_name",
    "middle_name",
    "family_name",
    "email",
    "email_verified",
    "profile",
    "zoneinfo",
    "locale",
    "address",
    "phone_number",
    "picture",
    "website",
    "gender",
    "birthdate",
    "updated_at",
    "at_hash",
    "c_hash"
  ],
  "scopes_supported": [
    "openid",
    "email",
    "profile",
    "address",
    "phone",
    "offline_access",
    "groups"
  ],
  "grant_types_supported": [
    "authorization_code",
    "implicit",
    "refresh_token",
    "password",
    ...
  ],
  ...
}

My Questions

1. Is there anything in my configuration that appears to be off? And/or is there anything I should be doing differently?
2. Does Okta Workforce connection not send groups even if they are explicitly requested in the scope parameter?

[andrea]

I read Auth0’s response in that thread a bit differently. My read instead is that, even if other claims are being returned in the token that Auth0 is receiving (including a groups claim), the Okta Workforce connection does not map these values into Auth0.

It might be worth double checking in their community forum to see if they can confirm what claims Auth0 does support mapping in (which might be limited to standard OIDC claims)

[david77]

Ahh, good catch. I didn’t read it that way at first. So it is possible that Auth0 is receiving the groups and just dropping it on the floor. I will open a support ticket or forum post for some clarification.