Connect your identity provider (SSO)

Connect SUPERWISE Chat to your company’s identity provider so your people sign in with the accounts they already have. When SSO is in place, your team logs in through your provider — Okta, Microsoft Entra ID, Auth0, or Frontegg — and Chat picks up who they are, which organization they belong to, and what they’re allowed to do, all from the sign-in token. No separate Chat passwords to manage, and access follows your existing joiner/mover/leaver process.

This is an admin task. You’ll do it once, test it, and then your whole org is covered.

Who this page is for

You’re an IT or workspace administrator setting up sign-in for your organization. You don’t need to be an engineer — but you will need administrator access to your identity provider so you can register an application and read its connection details.

What you’ll achieve

By the end of this guide your users will be able to:

• Sign in to SUPERWISE Chat using your company identity provider (single sign-on).
• Land in the correct organization automatically, kept separate from every other customer.
• Get the right level of access from day one, because their group/role membership in your provider maps to a role in Chat.

SUPERWISE Chat speaks OpenID Connect (OIDC), the open standard supported by every major identity provider. If your provider supports OIDC — and Okta, Entra ID, Auth0, and Frontegg all do — it will work here.

Before you begin

Have these ready before you start. Gathering them up front makes the connection a five-minute job.

You’ll need	Where it comes from
Administrator access to your identity provider	Your Okta / Entra / Auth0 / Frontegg admin console
The Chat sign-in (redirect) URL	Provided by your SUPERWISE contact for your workspace — looks like https://<your-workspace>/api/auth/callback
A new OIDC application registered in your provider	You’ll create this in step 1
Your provider’s discovery details — issuer URL, client ID, and client secret	Shown after you register the application
A test user assigned to the new application	A real account you can log in with to verify

Get your exact URLs first

Before you register anything, ask your SUPERWISE contact for the exact redirect URI and logout URL for your workspace. Pasting the precise values into your provider now saves you the single most common setup error — a redirect mismatch — later.

Step 1 — Register an application in your identity provider

In your provider’s admin console, create a new application for SUPERWISE Chat.

1. Create a new OIDC / OpenID Connect web application (sometimes called a “Regular Web App” or “Confidential client”).
2. Set the sign-in redirect URI to the Chat callback URL your SUPERWISE contact gave you (the …/api/auth/callback address). This is where your provider sends users back after they authenticate.
3. Set the sign-out / logout URL if your provider asks for one.
4. Request the standard scopes openid, profile, and email. These let Chat read the user’s identity and address. Auth0 and some providers also want offline_access for refresh tokens — include it if offered.
5. Save the application. Your provider will display three values you’ll need next:
   • the issuer URL (your provider’s base address, e.g. https://yourcompany.okta.com or your Auth0/Entra tenant URL),
   • the client ID, and
   • the client secret.

Keep the client secret safe — treat it like a password. You’ll hand these three values to SUPERWISE (or enter them in your workspace settings) in step 4.

Step 2 — Decide how your provider identifies organizations

SUPERWISE Chat keeps every customer’s data in its own isolated organization (tenant). To put each user in the right one, Chat reads an organization claim from the sign-in token. Different providers name this differently — you just need to know which one yours uses so the mapping in step 3 is correct.

Provider	Organization claim	Good to know
Frontegg	tenantId	The default for SUPERWISE. Can carry several organizations in one token; Frontegg owns the organization lifecycle.
Auth0	org_id	Uses Auth0 Organizations. A user works in one organization at a time and switches between them, rather than several at once.
Microsoft Entra ID	the directory / tenant identifier in the token	Standard OIDC; map the directory identifier claim to the organization.
Okta	a group or custom claim you choose	Add a claim in Okta that carries the organization identifier, then map it in step 3.

If your provider doesn’t surface organizations the way you need, your SUPERWISE contact can help you add a custom claim. You only have to settle this once.

Step 3 — Map your provider’s claims to Chat

A claim is a piece of information your provider puts inside the sign-in token — the user’s email, their name, their organization, their group memberships. SUPERWISE Chat needs to know which claim is which so it can set up each person correctly.

You’ll confirm a small mapping table. The defaults below fit most setups; adjust only the rows where your provider uses a different name.

Chat needs	Typical claim	What it’s used for
User ID	sub	The stable, unique identifier for the person
Email	email	Their address and display identity
Display name	name	How they appear in Chat
Organization	tenantId (Frontegg) / org_id (Auth0) / your chosen claim	Puts them in the right isolated organization (from step 2)
Roles / groups	roles	Their access level — drives what they can do in Chat

Roles come from your provider

The roles claim is how group membership in your identity provider becomes access in Chat. Put a user in your “Chat Admins” group and have your provider emit that in the roles claim, and they arrive in Chat with admin rights — no separate assignment needed. You can also manage roles inside Chat afterward; see Users & roles for the full role hierarchy and what each role can do.

Step 4 — Connect Chat to your provider

Hand the details from steps 1–3 to SUPERWISE, or enter them in your workspace’s identity settings:

• Issuer URL, client ID, and client secret from step 1.
• The organization claim from step 2.
• The claim mappings from step 3.
• For Auth0, the audience / API identifier for your application (Auth0 requires it).

Once these are in place, Chat validates every sign-in against your provider’s published signing keys automatically — there’s nothing more to keep in sync. The connection picks up key rotations and certificate changes on its own.

New people joining your org

By default, Chat is set to invite-only: a user can sign in only if they belong to an organization that’s already been set up. This is the recommended, secure posture for production — you control exactly who gets in. If you’d like new sign-ins or new organizations to be created automatically instead, ask your SUPERWISE contact about enabling automatic provisioning. We recommend leaving it invite-only and using your provider’s group assignments to control access.

Step 5 — Test the connection

Always verify with a real account before you announce SSO to the company.

1. Make sure your test user is assigned to the new application in your provider.
2. Open SUPERWISE Chat in a fresh private/incognito window.
3. You should be redirected to your provider’s login page.
4. Sign in with your test user.
5. You should be returned to Chat and land in the right organization, signed in as that user.
6. Confirm the user has the access level you expect — if you mapped a role/group, check they can see and do what that role allows, and nothing more.

When all six checks pass, your connection is live. Roll it out to the rest of your org.

Worked example: Okta

A typical Okta setup, end to end:

1. In the Okta admin console, create an app integration: OIDC – OpenID Connect, application type Web Application.
2. Set the Sign-in redirect URI to your Chat callback URL (https://<your-workspace>/api/auth/callback) and the Sign-out redirect URI to your Chat logout URL.
3. Request scopes openid profile email.
4. Assign your test user (and later, the right Okta groups) to the application.
5. From the app’s General tab, copy the Client ID and Client secret; your issuer is your Okta org URL (e.g. https://yourcompany.okta.com).
6. To carry roles, add a groups claim to the token in Okta’s authorization server, and map that claim to Roles in step 3.
7. Hand the issuer, client ID, client secret, and your organization/roles claim names to SUPERWISE (step 4), then run the step 5 test.

Entra ID, Auth0, and Frontegg follow the same shape — register the app, set the redirect URI, request the standard scopes, then map the organization and roles claims.

Troubleshooting

If something doesn’t work, it’s almost always one of these — each has a quick fix.

Symptom	Likely cause	Fix
Redirect / “state mismatch” error after login	The redirect URI in your provider doesn’t exactly match Chat’s callback URL	Copy the exact callback URL from your SUPERWISE contact into your provider’s allowed redirect URIs — match it character for character, including https:// and any trailing path. Then clear cookies and retry in a fresh window.
”Sign-in not configured”	The connection details haven’t been applied yet, or one is missing	Confirm the issuer URL, client ID, and client secret are all entered. Allow a moment after saving, then retry.
Login succeeds but the user can’t get in / sees an access error	The user’s organization isn’t set up in Chat (invite-only is on)	Confirm the user belongs to an organization that’s been provisioned, or ask your SUPERWISE contact to add it. This is the expected, safe behavior — unknown organizations are turned away by design.
User lands in the wrong org, or with no org	The organization claim is mismatched	Re-check step 2: confirm which claim your provider uses for organizations (tenantId vs org_id vs your custom claim) and that the mapping in step 4 points at it.
User signs in but has the wrong access level	The roles/groups claim isn’t mapped, or the user isn’t in the expected group	Verify the user’s group membership in your provider, that the group is emitted in the roles claim, and that the claim is mapped (step 3). You can also set the role directly in Chat — see Users & roles.
Multi-organization users behave unexpectedly	Provider differences	Frontegg can carry several organizations in one token; Auth0 has users switch between organizations one at a time. Set expectations to match your provider.

If you’re still stuck, the Admin troubleshooting page has a broader checklist, and your SUPERWISE contact can confirm your workspace’s exact URLs and connection state.

Related pages

• Users & roles — the role hierarchy and what each role can do once people are signing in.
• Admin troubleshooting — wider diagnostics for sign-in and access issues.
• Tenant isolation — how your organization’s data is kept separate from everyone else’s.
• Audit & usage — review sign-ins, access changes, and activity for your organization.