Group sync lets your external identity provider (IdP) act as the source of truth for end-user group memberships. Turn it on for an IdP configuration, and Celigo reads the groups claim from OIDC tokens during MCP authentication and matches those group names, exactly, to your Celigo end-user groups. If someone belongs to "Engineering" in Okta, they're matched to "Engineering" in Celigo; no mapping table, no transformation.
This removes the need to manage group memberships by hand in Celigo, and makes sure end users get the right MCP server access based on groups your organization already manages elsewhere. Group sync depends on your IdP sending group names in the token, and most providers don't do that by default.
Group sync also drives JIT (just-in-time) provisioning: the first time an end user authenticates through your IdP, Celigo creates their end-user account automatically and maps them to the right groups that are already matched. JIT itself works independently of group sync. — see Enable JIT provisioning.
Prerequisites
- You need the administrator access level
- Your account must be multi-environment. Group sync isn't available on legacy sandbox-only accounts
- At least one external IdP must already be configured. See Configure end-user authentication
- Your IdP must be set up to include group information in OIDC tokens
Which providers group sync works with
Group sync only works out of the box with IdPs that send group names in the token without extra configuration on Celigo's side. Most enterprise IdPs don't:
- Okta: Its not supported. Okta withholds the groups claim unless the groups OAuth scope is requested, and Celigo doesn't request it
- Microsoft Entra ID: Its not supported. Entra emits group object IDs (GUIDs), not names, and group sync matches on name only
- Auth0: Its does not support without a custom action added on the Auth0 side
- OneLogin: Its not supported, for the same reason as Okta.
- Duo: Its not supported. Duo sends LDAP distinguished names, not group names.
- JumpCloud: Its not support for any user who belongs to exactly one group (a JumpCloud quirk with single-group claims).
How group sync works
Group sync matches your IdP's group claims to Celigo end-user groups by exact name, including capitalization. Finance matches Finance, not finance or Fin.
Turn on group sync per IdP. Each time an end user signs in through that IdP, Celigo updates their IdP-synced group memberships to match the current token, adding and removing groups as needed. Memberships you added manually aren't affected.
Create your Celigo groups before turning on group sync. Celigo doesn't create groups for unmatched claim names, it drops them silently. If the matching Celigo groups don't exist yet, sync will appear to do nothing.
If multiple IdPs send the same group name, their end users share one Celigo group.Only group memberships resync on login; other profile fields don't.
Enable group sync on an IdP configuration
- Go to Account (the avatar at the top right of the page), and then select Security.
- On the left, go to End users → Authentication.
- Select the IdP configuration you want to enable group sync for, or create a new one.
-
Turn on Group sync.
- Optionally, turn on JIT provisioning to auto-create end-user accounts for people signing in for the first time.
- Select Save.
Once saved, end users are assigned to matching Celigo groups every time they authenticate through this IdP. For the full IdP form field reference (Name, Routing, Email domains, Issuer URL, Client ID, Client secret, and the read-only Callback URL), see Configure end-user authentication > Field reference.
Configure your IdP to send group claims
Your IdP needs to include group information in OIDC tokens before group sync can do anything, most providers need extra configuration or don't support it at all. Full setup steps live in the per-provider walkthroughs, here's the short version:
- Okta: Add a group's claim to the ID token in your Okta application's Sign On settings, and filter it to the groups you want to send. See Configure Okta as an end-user IdP. (The groups-claim portion of that guide carries a hold banner pending an engineering fix — sign-in and JIT are safe to use today.)
- Microsoft Entra ID: Entra ID returns group claims as object IDs (GUIDs) by default, not display names. Since group sync uses exact name matching with no mapping table, leaving this unconfigured means every group claim looks unrecognized and nothing syncs. Configure your app registration to emit group display names instead, using the optional groups claim with emit_as_name_values, or cloud_displayname / dns_domain_and_sam_account_name in token configuration
- Auth0: Add a custom action that adds a group's claim to the ID token from user metadata or organization memberships. Auth0 also reserves the claim name groups for its own use, so you'll need to send yours under a namespaced URI claim instead. See Configure any OIDC identity provider as an end-user IdP
- Ping Identity: Configure the groups claim in your OIDC application's attribute mapping. Whatever the source, the names your IdP sends need to match your Celigo group names exactly. Name your Celigo groups to match your IdP groups, or vice versa
Enable JIT provisioning
JIT provisioning creates an end-user account automatically the first time someone authenticates through your IdP and doesn't already have a Celigo end-user account.
- Go to Account → Security → End users → Authentication → select the IdP configuration.
-
Turn on JIT provisioning.
Note: Group sync doesn't need to be on as JIT and group sync are independent settings, but without group sync, or on a provider group sync doesn't work with, the new end user won't be placed in any group automatically.
Select Save.
When a new user authenticates through this IdP for the first time:
- The end-user record is created immediately as Active, using the name and email from the token. There's no verification step and no verification email on this path.
- If group sync is on and the IdP's groups claim matches existing Celigo groups by name, the user is placed in those groups. Unmatched claim names are dropped.
- The end user shows up in End users → Users with a "JIT" source indicator and the name of the IdP that provisioned them.
If the user already exists as an end user from a manual invite, or from JIT in a different account, JIT links the IdP to that existing record instead of creating a duplicate. Profile fields already set are preserved; any that are blank get filled in from the token.
Existing user behavior on re-login
After the first link, only group memberships re-sync on later logins:
- Group memberships: Re evaluated on every login against the latest groups claim. Adds and removes IdP-synced memberships; leaves manually added memberships alone
- name and email: Preserved as set at first link. Not overwritten by a different value from the IdP on later logins, unless the field was blank, in which case it's populated then
- Other profile fields: The same end user object can connect to multiple IdPs across multiple accounts, and re-syncing profile fields from one IdP on every login would risk overwriting values of another IdP set. To change a user's name or email directly, an admin edits the end-user record. If someone's email changes in your IdP, Celigo treats it as a new identity and JIT creates (or links to) a separate end user record under the new email there's no way to carry the old record's memberships forward automatically. Matching for end users is email-based, so a reused or changed email address is worth double checking after any change on the IdP side
Handle multiple IdPs
Each configured IdP has its own group sync settings, its own toggle, group claim field, and JIT provisioning setting.
- End users are routed to an IdP by email domain, or to a catch-all "All end users" IdP if one exists
- If multiple IdPs send the same group name, users are added to the same Celigo group. Group names are shared across the account rather than scoped to an individual IdP
- Each IdP can use a different group claim field, groups for Okta, memberOf for Entra ID, for example