The account nobody remembers is the one that matters
Most chat tools arrive sideways. Somebody in support signs up, invites four colleagues, and the account exists for two years before anyone in IT hears about it. That history is why chat is so often missing from the offboarding checklist: it was never on the provisioning one either. The result is a tool holding real customer conversations, reached by passwords that live outside every control your organisation otherwise applies.
Single sign-on is the correction. Instead of each agent holding a separate password for chat, they reach the console through the identity provider your organisation already runs — and the account lifecycle moves to the place that already knows who works here.
What SSO actually changes
It is worth being precise, because SSO is often sold as a security feature in general terms and then disappoints people who expected something else.
- One credential, one set of rules. Your password policy, your session length, your multi-factor requirement. You stop maintaining a second, weaker copy of all of that inside a chat tool.
- Leaving actually means leaving. Disable the directory account and the chat door closes with every other door, at the same moment, without anyone remembering to do it.
- One place to look. When you need to answer who could read customer transcripts in March, the answer is derived from the directory rather than reconstructed from an invitation list.
What it does not change is just as important. SSO governs how your team reaches the console. It is not a visitor identity system, and it is worth saying plainly: a public chat widget is not an authentication channel, and something a visitor typed into chat is never proof of who they are. If you need to know that the person in the conversation is really the account holder, that verification has to happen somewhere else.
OpenID Connect, and why not SAML
MyLiveChat implements OpenID Connect rather than SAML. In practice this is a smaller decision than it sounds, because every major identity provider — Okta, Microsoft Entra ID, Google Workspace, Auth0, JumpCloud, OneLogin, Ping — speaks OIDC alongside SAML. If your provider offers both, choose the OIDC application and the rest of the setup is the same.
The flow is the ordinary authorization-code exchange, run server side. Your agent is sent to your provider, signs in there, and comes back with a short-lived code. That code is exchanged directly with your provider over an authenticated connection, and the identity comes back on that channel rather than from anything the browser was allowed to hand over. It is a deliberately boring design, and boring is the correct ambition for an authentication path.
One consequence of that design shows up in setup: every endpoint you configure must be an https address. An http endpoint is refused outright rather than quietly accepted, because over http both the secrecy of the exchange and the trustworthiness of the answer are gone.
The rollout order that does not lock you out
The failure mode people fear with SSO is being unable to reach the tool that tells you SSO is broken. Sequence the rollout so that is never possible.
- Create the application in your provider first, and note the issuer, the authorize, token and userinfo endpoints, the client id and the client secret. You will need all of them and a half-filled configuration is worse than none.
- Fill the configuration in completely, then enable. A partly configured connection should never produce a partly working sign-in, and MyLiveChat will not attempt the flow until every field is present.
- Restrict which email domains may sign in. A domain allowlist means a valid account at some other tenant of your provider cannot walk in through your door.
- Test with a second account, not your own. The person who configured it is the worst test subject, because their session is already established.
- Keep password sign-in working. Presenting SSO as the primary route is not the same as removing the alternative, and a provider outage should never be able to lock you out of your own console.
Roles are a separate decision
SSO decides who gets in. It does not decide what they can do once inside. Roles in MyLiveChat remain administrator and agent, and they are set in the product, not carried across from your directory. If your provider has a beautifully modelled group hierarchy, none of it arrives automatically.
This trips people up when they assume an identity project has also solved authorisation. Treat them as two pieces of work: connect the directory first, then decide separately and deliberately who among those people needs administrator rights. Most teams need far fewer administrators than they have.
Read the sign-in log, including the refusals
Every sign-in attempt is recorded with its outcome, and the refusals are the interesting half. A successful sign-in tells you the system works. A run of refusals tells you something is wrong — a misconfigured endpoint, someone outside your allowed domains trying the door, an account that was disabled upstream but is still being used by someone who has not noticed.
Logs nobody reads are only half a control. Give someone the job of glancing at refusals monthly, and give them a rule for what is worth escalating, or you have built an archive rather than a safeguard. The administration settings are also where you should confirm that the list of people with access still matches the list of people who need it.
How MyLiveChat fits
SSO is configured per site from the dashboard, and it is not reserved for a particular plan tier. You supply your provider's endpoints, client id and client secret, optionally restrict sign-in to your own email domains, and turn it on. The connection carries only what it needs: the standard identity claims, over the authenticated channel described above.
Provisioning is a separate and complementary mechanism — if you want joiners and leavers handled automatically rather than by hand, that is what SCIM does, and it is worth reading about before you decide how much of this to automate.
What to measure
- Share of sign-ins arriving through SSO. If it plateaus well below your headcount, some people never made the switch and are still using passwords.
- Refused attempts per month, split by reason. A steady trickle from outside your allowed domains is normal; a spike is worth reading properly.
- Time from a leaver's directory account being disabled to their chat access ending. With SSO this should be effectively immediate, and if it is not, something is still holding a local password.
- Number of administrators. Not a security metric on its own, but a number that only ever grows unless somebody looks at it.
- Accounts in chat with no matching directory account. Ideally zero. Anything else is an account that outlived its owner's employment.
Before you switch any of this on for the team, run the checks: testing your single sign-on setup walks through what the configuration test proves, and the one result that looks like a pass but only means we could not tell.