Single Sign-On
Let your team sign in to MyLiveChat with the accounts they already have, and let your provider add and remove people automatically. OpenID Connect and SCIM 2.0, included — not an enterprise-tier upsell.
Any OIDC provider
Okta, Entra ID, Google Workspace, Auth0, JumpCloud, OneLogin, Ping.
SCIM provisioning
New starters appear. Leavers are deactivated, never deleted.
Sign-in log
Every attempt recorded — including the ones we refused, and why.
Setup
Paste your issuer URL and we read the rest from your provider’s own OpenID configuration. Transcribing endpoints by hand is the most common way an SSO setup breaks — and it breaks at a login screen, where the person affected cannot get in to fix it. So we do not ask you to.
In your provider, create an OIDC web application and register the redirect URI we show you in the dashboard.
Paste your issuer URL into Dashboard → Single Sign-On and press Fetch endpoints. Review what came back, add your client ID and secret, save.
Optionally restrict which email domains may sign in, then turn it on. Your team gets a sign-in link they can bookmark or launch from your provider’s app dashboard.
Password sign-in always keeps working. Turning SSO on adds a way in; it never removes one. If your provider has an outage, you still have your account — which is not something you want to discover the hard way.
SSO covers your whole team, not one owner account. An agent who signs in with your provider lands straight in the chat console, ready to take conversations.
Deliberately. If a provider naming an email address could create an account, anyone controlling a configured provider could mint them. People are added by an admin, or by your provider through SCIM — never by the act of arriving at the login page.
When SCIM removes someone, we disable their agent. Deleting would take their chat history’s attribution with it, and a mis-scoped group in your provider would make that unrecoverable. Disabling is reversible.
Rollout
Single sign-on fails in a uniquely awkward place: the login screen. The person who needs to fix it is the person who cannot get in. Sequencing the rollout removes that risk entirely, and it costs nothing but patience.
Connect the provider first and sign in yourself while password sign-in is still available to everyone. Add a second admin and have them do the same from their own device, because a configuration that works for its author is not yet proof of anything. Only once two people have signed in successfully should you invite the wider team, and only after that should you restrict which email domains may sign in.
- Keep at least one admin who can sign in with a password, and know who it is
- Test from a device that has never signed in before, not the browser you configured it in
- Send the team the sign-in link before you announce the change, not after
- Add the domain restriction last, once real people have signed in successfully
After go-live
Most support requests after an SSO rollout have three causes, and the log names all of them without anyone having to guess. A refusal because the address is not marked verified by your provider is a provider-side fix. A refusal on domain means someone is signing in with a personal address rather than their work one. A refusal because there is no such agent is the deliberate design: arriving at the login page never creates an account, so somebody has to be added by an admin or provisioned by SCIM first.
It is also worth being clear about what SSO covers and what it does not. It governs how your team reaches the console and dashboard. It is not a visitor identity system: a public chat widget is not an authentication channel, and you should never treat something a visitor typed into chat as proof of who they are. Roles remain admin and agent, so SSO decides who gets in, not what they can do once inside.
Related reading: access control for chat teams and offboarding an agent properly.
Included, not upsold
Connect your provider, let it manage who has access, and get on with answering customers.
Related:
dashboard & admin ·
integrations & API ·
chat security basics