Single sign-on (SSO)
Single sign-on lets a user authenticate once with a central identity provider and then reach several separate applications without logging in again. The applications never see the password; they receive a signed assertion or token from the identity provider stating who the user is.
How the handoff works
The application redirects the user to the identity provider — Entra ID, Okta, Google Workspace. The provider authenticates them, possibly without any interaction because a session already exists, and sends them back with a signed assertion. The application validates the signature, reads the identity from it, and creates its own local session.
Two protocols dominate. SAML is XML-based, older, and still the default in enterprise procurement. OpenID Connect, built on OAuth 2.0 and using JWTs, is what most new integrations use and is far simpler to implement.
Why organisations insist on it
The value is not saving users a few logins. It is control. When an employee leaves, disabling one account in the identity provider closes access to every connected application at once, instead of hoping someone remembers each tool. Password policy, multi-factor requirements and conditional access are enforced in one place. And the audit log of who accessed what lives centrally.
Provisioning is often bundled in through SCIM, which creates and deactivates accounts in the application automatically as they change in the directory.
The distinctions people get wrong
"Sign in with Google" on a consumer app is social login, not enterprise SSO. The mechanics are similar — often literally OpenID Connect — but there is no organisational directory, no central deprovisioning and no admin control. Buyers asking for SSO usually mean the second thing, and answering with the first loses deals.
SSO is not the same as using the same password everywhere. Reusing one password across systems is the opposite of SSO: each system still stores a credential. With SSO only the identity provider holds one.
Logging out is harder than it looks. Ending the local session does not end the identity provider session, so clicking the login button again may sign the user straight back in. Single logout exists in both protocols and is inconsistently implemented.
The trade-off worth stating: SSO concentrates risk. A compromised identity provider account opens every connected application, which is exactly why strong second factors matter most there.
Frequently asked questions
Is "Sign in with Google" the same as SSO?
Technically it uses the same protocol, but in business conversations SSO means something more: an organisation-controlled identity provider with central account provisioning, deprovisioning, policy enforcement and audit logs. Social login gives the convenience without any of the administrative control.
Build it yourself
NorthernGo turns a plain-text description into a working web app with a database, login and a live URL. Local AI generation runs on your own GPU, is unlimited, and is free on every plan.