SSO and User Groups

This section is for those who administer your Identity Provider (IdP), for example Entra ID (Azure AD), Okta or Google. Learn how to configure Single Sign-On (SSO) and user groups for Intric.

SSO Setup (Single Sign-On)

Intric uses OIDC (OpenID Connect) for login, which makes it possible for your users to log in with their existing organization accounts.

Information you need to send to Intric

For Intric to be able to configure SSO against your IdP, you need to provide:

• Issuer: URL to the issuer (e.g., https://login.microsoftonline.com/{tenant-id}/v2.0)
• Client ID: Your client ID from IdP
• Client Secret: The secret value, not the secret ID

If you use Entra ID, you can send the Directory (tenant) ID instead of the issuer URL — we derive the issuer from it.

Note the expiry date of the client secret. Logins stop working when it lapses, so send us the new value before it rolls over, or issue a secret with a long lifetime.

Configuration on your side (in your IdP)

In your Identity Provider, you must whitelist the following callback URL:

https://login.intric.ai/idps/callback

Register it as a Web redirect URI. This is the only URL you need to add — no logout URL, no single-page-application or mobile platform, and no implicit flow. Intric uses the authorization code flow with PKCE, handled server-side.

This allows Intric to receive login confirmations from your IdP.

Email addresses must be present

Intric links each login to a user account by email address, so every user who will log in needs an email address in the token. In Entra ID the email claim is taken from the user’s mail attribute — not from the UPN — so an account with no mail value cannot be linked. Guest accounts are unaffected; they get an email claim by default.

User Groups

User groups are collections of users in your company’s user system. In Intric, you can use these groups to easily manage access to Spaces for multiple users at once, instead of inviting each user individually.

How it works

When a user logs in to Intric, information about which groups they belong to is automatically fetched from your existing system. A user who is a member of a user group that has been given access to a Space then automatically gets access to the published assistants in the Space when the person logs in to Intric.

Configuration and functionality

How does the configuration work?

For user groups to work in Intric, your system needs to send group information when users log in. This is done through something called a “groups claim” in the login token.

Technical detail: Token must contain a key called “groups” with a list of group identifiers:

"groups": ["group 1", "group 2", "group 3"]

Important requirements for group configuration

Correct format:

• The key must be exactly groups
• The value should be a flat list with text strings
• Example: ["Group 1", "Group 2", "Group 3"]

Incorrect format:

• Avoid nested structures
• Example of error: ["group1": ["group1.1", "group1.2"], "group2": ["group2.1"]]
• Note: Nested groups in themselves are fine in your system, as long as the list sent to Intric is flat

How groups are created and updated

• Automatic handling: Groups are automatically created in Intric the first time a user logs in who belongs to them
• Update: Group membership is updated every time a user logs in
• Note: By default this works entirely from the information in the token — we do not call Microsoft’s Graph API. An optional Graph-backed sync is available if you need group changes to apply without waiting for the user’s next login; contact Intric support to discuss it

Important limitations to be aware of

1. Group identifiers cannot be changed

The text strings sent from your system are used as unique identifiers in Intric.

• If you change from group names to object ID (or vice versa), Intric sees this as completely new groups
• Example: If you switch from “IT-support” to “12345-abcde”, a new group is created, and the connections to the old group disappear

2. Removal of groups (Scenario example)

Here’s a common scenario that can cause confusion:

1. Görgen configures the IdP to send all 10 groups on the token, but actually only wants 3 of them
2. Lina logs in to Intric and belongs to all 10 groups in the IdP
3. Görgen sees that all 10 groups have been created in Intric
4. Görgen removes the 7 groups he doesn’t want in Intric
5. Görgen changes the configuration in the IdP so that only the 3 desired groups are sent on the token
6. Lina (who is still logged in) does something in Intric that triggers group synchronization
7. Intric sees that there are groups that Lina belongs to (from her session) that no longer exist in the system → Intric creates them again
8. Görgen sees that the groups appear again: “But I removed them!”

Solution: Lina must log out and in again for her session and group membership to correctly reflect the new configuration.

3. A missing groups claim removes memberships

Group membership in Intric mirrors the last token we saw. If a user logs in and the token carries no groups at all, that user is removed from every synced user group — and loses the access those groups granted. This is worth knowing because a misconfiguration on the IdP side usually shows up as “SSO works, but the user has no access” rather than as a login error.

Important considerations (Entra ID)

If you use Microsoft Entra ID (Azure AD), configure the groups claim so that only the groups Intric needs are sent. Intric creates one user group per identifier it receives, so a token carrying your whole directory produces a user group in Intric for every group your users belong to.

Send only the groups you choose

This takes two steps, and both are required:

1. Assign the groups to the application. Enterprise applications → your Intric application → Users and groups → add exactly the groups Intric should know about. Security groups and Microsoft 365 groups can be assigned; distribution lists cannot. Group-based assignment requires Entra ID P1 or P2.
2. Add the groups claim, limited to those groups. App registrations → your Intric application → Token configuration → Add groups claim → select “Groups assigned to the application” → Save. In the application manifest this is a single property:

"groupMembershipClaims": "ApplicationGroup"

Leave “Customize token properties by type” untouched. Its default already emits group object IDs, which is what Intric matches on.

Do not choose “Security groups” or “All groups”. Both ignore the assignment list and send every group the user belongs to. They also risk running into Entra’s limit of 200 groups per token: above that limit Entra omits the groups claim entirely, which means affected users sync no groups and lose the ones they already have (see limitation 3 above).

Nested groups are not included

With “Groups assigned to the application”, Microsoft’s documentation states that nested groups are not included and the user must be a direct member of the group assigned to the application. So if a group you assign contains other groups rather than users, assign those child groups directly as well. Otherwise those users log in with an empty groups claim and lose their access.

Group names vs Object ID

By default Entra ID sends group object IDs, and we recommend keeping it that way. Object IDs are stable — a group renamed in Entra ID keeps the same identifier, whereas a name-based identifier would orphan the existing Intric group and silently create a new one (see limitation 1 above).

Because object IDs are not readable, send Intric a list mapping each group name to its object ID, and tell us when you assign further groups later. We label the user groups in Intric so your administrators see recognisable names.

If you would still rather send names, note that the sam_account_name formats only apply to groups synchronised from an on-premises Active Directory — groups created in Entra ID are omitted from the claim entirely under those formats. Talk to Intric support before changing the format on an existing setup, since it re-creates every group.

Recommendations and best practices

Planning before implementation

• Decide which groups are needed in Intric before you start
• Configure your system to only send these groups from the start
• Test with a test user before full-scale rollout

Avoid common pitfalls

• Don’t send more groups than necessary
• Don’t change group identifiers after implementation
• Test all changes in development environment first

If problems occur

• Check that token contains correct "groups" claim
• Verify that group names/IDs are stable
• Ask users to log out and in again after configuration changes

Step-by-step guide for setup

1. Prepare your IdP

   • Decide which groups should be synced
   • Configure groups claim to send these groups
   • Verify that the format is correct (flat list)

2. Gather information

   • Issuer URL (or, for Entra ID, the Directory (tenant) ID)
   • Client ID
   • Client Secret
   • Whitelist callback URL
   • A list mapping group names to the identifiers you send

3. Send to Intric

   • Contact Intric support with the information
   • Intric configures SSO on their side

4. Test

   • Log in with a test user
   • Verify that groups sync correctly
   • Test access to Spaces

5. Roll out

   • Inform users that they should now use SSO
   • Monitor logins the first days
   • Adjust as needed

Support

If you encounter problems or have questions about SSO configuration, contact Intric support. We help you with:

• Troubleshooting SSO connection
• Configuration of groups claim
• Entra ID-specific settings
• Best practice for your organization