Okta SSO Group Sync: How Group Membership Updates Work at Login and How to Troubleshoot Missing Groups – DataHub Customer Support Portal

Area: Deployment Issues

Sub-Area: SSO / OIDC Configuration — Okta Group Claim Sync

Issue

When using Okta as an SSO provider with DataHub Cloud via OIDC, users expect their Okta group memberships to appear in DataHub automatically. However, groups may not appear on a user's profile after login, may disappear after subsequent logins, or administrators may be unsure whether Okta is actually sending group claims at all. Because the OIDC token exchange happens server-side, groups claims are not visible in browser developer tools, and DataHub does not expose a self-service log of what claims were received. This article explains how the group sync mechanism works, how to verify it is functioning, and how to troubleshoot common failure modes.

You Might Be Asking

Why don't I see any Okta groups on a user's DataHub profile after they log in via SSO?
How can I confirm that Okta is actually sending group claims to DataHub?
Can I view login logs or SSO claim payloads in DataHub?
Why did a user's group membership disappear after a second login?
A user was in a DataHub group after one login but was removed after the next — what happened?
How do I verify the Okta groups claim filter is configured correctly?

How Okta Group Sync Works in DataHub

Understanding the sync mechanism is essential to troubleshooting it correctly:

Group sync happens only at login. DataHub does not poll Okta for group changes. The only moment DataHub reads a user's groups is when that user authenticates via SSO.
Each login is authoritative and replaces previous Okta-sourced groups. When a user logs in, DataHub replaces that user's Okta-sourced group memberships with exactly the list Okta sent in the current token. If Okta sends no groups claim, the user is removed from all Okta-sourced groups.
Manually assigned groups are not affected. Groups added to a user's profile directly inside DataHub (not via Okta) are preserved across logins and are not overwritten by the Okta claim.
The Groups tab on the user's profile is the ground truth. After a user logs in, navigate to their profile in DataHub and check the Groups tab. The groups listed there reflect exactly what Okta sent on the most recent login.
Claims are not visible in the browser. The OIDC authorization code flow means the browser only receives a short-lived code. DataHub's server exchanges that code with Okta for the actual ID token and claims. Browser developer tools cannot show you what groups were included in the token.
DataHub does not expose a self-service login log. DataHub records login events in internal server logs, but these are not accessible from the UI. If you need to verify what claims Okta sent for a specific login, contact DataHub Support and provide the username and approximate login time (UTC).

Solution

Step 1 — Verify That the Okta Application Is Configured to Send a Groups Claim

Okta does not include group membership in OIDC tokens by default. This must be explicitly configured on the Okta application.

Log in to the Okta Admin Console.
Navigate to Applications → [Your DataHub Application] → Sign On.
Click Edit in the OpenID Connect ID Token section.
Set Groups claim type to Filter.

Set Groups claim filter to a pattern that matches your DataHub-related groups. Examples:

# Include all groups (use with caution in large orgs)
Matches regex: .*

# Include only groups starting with a specific prefix
Starts with: DataHub

Ensure the groups scope is included in the application's allowed scopes:
```
openid email profile groups
```
Save your changes.

Important: Group names in Okta are case-sensitive and must exactly match the group names (or IDs) configured in DataHub. A claim filter that is too restrictive — or a group name with an unexpected capitalization difference — will cause groups to silently not be sent.

Step 2 — Verify That the User Is a Member of a Group That Matches the Claim Filter

In the Okta Admin Console, navigate to Directory → Groups.
Open each group that should appear in DataHub and confirm the user is listed as a member.
Confirm the group name matches what your claim filter would select. For example, if your filter is Starts with: DataHub, a group named datahub-admins (lowercase) would not match.

If a user is not a member of any group that matches the claim filter, Okta will send no groups claim, and DataHub will clear that user's Okta-sourced group memberships on login.

Step 3 — Verify the DataHub SSO Configuration

Log in to DataHub Cloud as an admin.
Navigate to Settings → Platform → SSO → OIDC.
Confirm that Extract Groups is enabled.
Confirm that the Groups Claim Name field matches the claim name Okta is configured to send. The default value is groups:
```
Groups Claim Name: groups
```
Confirm that groups is included in the Scope field:
```
openid email profile groups
```

Warning — SCIM conflict: If your organization is using SCIM to provision group memberships in DataHub, enabling Extract Groups simultaneously will cause Okta to overwrite SCIM-managed memberships at every login. If SCIM is managing groups, disable Extract Groups to avoid conflicts.

Step 4 — Verify the Okta System Log to Confirm Claims Are Being Sent

In the Okta Admin Console, navigate to Reports → System Log.
Search for the user's email address.
Filter for the event type user.authentication.sso.
Open the relevant event and inspect the token payload for a groups claim. If the claim is absent, Okta is not sending groups for that user at that moment.

The Okta System Log is the most reliable tool available to end administrators for confirming what claims Okta sent. Changes to group membership and application claim filters are also recorded here, which helps identify when a working configuration stopped functioning.

Step 5 — Confirm Results in DataHub After a Fresh Login

Have the test user sign out of DataHub completely.
Have the test user sign back in via Okta SSO.
As a DataHub admin, navigate to Settings → Identities → Users → [User Profile].
Open the Groups tab. The groups Okta sent on that login will be listed here.

If the groups are still not visible after a fresh login and the Okta System Log confirms groups were sent, contact DataHub Support with the username and the UTC timestamp of the login attempt.

Step 6 — Contact DataHub Support for Log-Level Verification

If you have completed the steps above and cannot determine whether Okta is sending the correct claims, DataHub Support can inspect internal server logs for a specific user and login event. When contacting support, provide:

The username or email address of the affected user
The approximate login time in UTC
Your DataHub Cloud instance URL (e.g., https://<your-instance>.acryl.io)

Additional Notes

Case sensitivity: Okta group names are case-sensitive. A group named S_Okta_DataHub_DEV and a group named S_Okta_Datahub_DEV are treated as different groups. Ensure the exact casing is consistent between Okta group names, the claim filter, and any group references in DataHub.

Duplicate user accounts: If a user has multiple accounts in DataHub (for example, one created by SCIM and one created by a prior SSO login with a different email casing), the Okta group claim will be applied to the account whose email matches the claim. The other account will appear to have no Okta groups. Confirm which account Okta is authenticating when debugging missing group assignments.

Timing: Group membership changes in Okta do not propagate to DataHub until the affected user logs in again. If a user's group membership in Okta changes, those changes will not be reflected in DataHub until their next SSO login.

No self-service login log: DataHub Cloud does not currently provide a UI for viewing login history or OIDC claim payloads. This is a known limitation. The Groups tab on the user profile is the recommended proxy for verifying what was received on the last login.