Single Sign-On

Your identity provider. Your rules.

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

Three fields, not three days.

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.

  1. 1
    In your provider, create an OIDC web application and register the redirect URI we show you in the dashboard.
  2. 2
    Paste your issuer URL into Dashboard → Single Sign-On and press Fetch endpoints. Review what came back, add your client ID and secret, save.
  3. 3
    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.

It cannot lock you out

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.

Agents, not just admins

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.

Signing in never creates an account

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.

Leaving deactivates, never deletes

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.

For your security review

The details a questionnaire asks for.

  • Protocol. OpenID Connect Authorization Code flow. We do not implement SAML.
  • Identity source. Read from your provider’s userinfo endpoint over TLS, server to server — never parsed from a token handed to us by a browser.
  • Email verification. An address your provider has not marked verified is refused.
  • Domain allowlist. Optional, and bounds which addresses your provider is permitted to assert.
  • MFA. Enforced by your provider under your own policy. We do not run a second one.
  • Audit. Every sign-in attempt logged with outcome, including refusals and the reason.
  • Provisioning. SCIM 2.0 — /Users with filter, create, update, patch and deactivate.
  • Tenancy. The site is resolved from your token alone; a request cannot name the tenant it acts on.

Full API reference: v1 documentation · security posture: trust centre

Rollout

Turn it on in an order that cannot strand you.

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

What the sign-in log is telling you.

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

Enterprise sign-in without the enterprise tier.

Connect your provider, let it manage who has access, and get on with answering customers.

Related: dashboard & admin · integrations & API · chat security basics

Free forever for 1 agent

Give every visitor an instant way to reach you.

Launch live chat, connect your knowledge base, and add AI answers when you are ready. No credit card, no trial clock.