What Is Single Sign-On (SSO)? How It Works & Its Limits (2026)

You sign in once in the morning and suddenly your email, calendar, chat and a dozen other tools are all open - no more logins. That is single sign-on, or SSO. It is one of the most common authentication systems in workplaces, and increasingly online with "Sign in with Google" buttons. This guide explains what SSO is, how it works, and its honest limits.

SSO is strongest when paired with multi-factor authentication.

The short answer

Single sign-on lets you log in once and access many connected apps without re-entering your password. You authenticate with one trusted service, and it confirms your identity to the other apps for you. One login, many services. It saves time and cuts down on the pile of passwords you would otherwise juggle.

How SSO works

Behind the convenience is a central identity provider - the service you actually log in to. When you sign in, it issues each app a secure token that says "this person is verified." The apps trust the token, so they never ask for your password and never see it. You experience one login; the apps quietly accept the proof in the background. The "Sign in with Google" button is SSO you have probably used already.

The real benefits

SSO is popular for good reasons. You handle far fewer passwords, which means fewer weak or reused ones. Logging in is faster, especially across many work tools. And because everything flows through one identity provider, security can be centralised - strong authentication and two-factor login enforced in one place instead of app by app. For companies, it also makes adding and removing access much simpler.

The honest limits

There is a catch, and it matters. SSO turns your main account into a single key: if someone breaks into it, every connected app is exposed at once. That makes protecting the SSO account critical - a strong, unique password and two-factor authentication are non-negotiable. SSO also does not cover everything; plenty of accounts you use have no SSO option at all, so it never fully replaces good password habits.

SSO vs a password manager

People sometimes treat these as rivals; they are partners. SSO gives you one identity for a set of connected apps. A password manager gives you a unique password for every account, including all the ones SSO does not reach. SSO reduces how often you log in; a password manager makes sure each remaining login is strong. Use SSO where it is offered, and a password manager for everything else.

SSO protocols explained simply (SAML, OAuth, OIDC)

You never have to configure these yourself, but knowing the three names helps you understand what is happening when you click "Sign in with Google." They are open standards that let apps trust an identity provider without ever sharing your password.

• SAML (Security Assertion Markup Language) is the older standard, common in workplaces and schools. After you log in to the identity provider, it sends the app a signed XML "assertion" that says who you are. It is built for authentication - proving identity - and is the engine behind most corporate SSO portals.
• OAuth 2.0 is not really a login standard at all; it is an authorisation framework. It lets one app act on your behalf in another - for example, granting a calendar app permission to read your Google Calendar - by handing it a limited access token instead of your password.
• OIDC (OpenID Connect) is a thin identity layer built on top of OAuth 2.0. It adds the missing "who is this person" piece, returning an ID token (a signed JWT) alongside the access token. The consumer "Sign in with Google / Apple / Microsoft" buttons you see online almost always use OIDC.

The practical takeaway: SAML and OIDC handle who you are, OAuth handles what an app is allowed to do. In all three, the app receives a short-lived signed token, never your actual credentials - which is exactly why a phished SSO password is so dangerous and why the next section matters.

The single-point-of-failure risk (and how to limit it)

The convenience of SSO has a sharp edge: your identity provider account is a master key. Compromise it and an attacker inherits every connected app at once, no further passwords required. There are two distinct risks worth separating.

The first is account takeover - someone phishes or guesses your IdP login. This is why the SSO account itself must carry your strongest defences: a long unique password and a phishing-resistant second factor like a hardware key or passkey, never SMS alone. The second is availability - if the identity provider has an outage, you can be locked out of everything that depends on it until it recovers. Real-world IdP outages have done exactly this to entire companies.

You cannot remove these risks, but you can blunt them: protect the IdP account harder than any single app, enable MFA on it, keep recovery codes somewhere safe and offline, and store unique passwords for your non-SSO accounts in a password manager so a single IdP failure never leaves you completely shut out.

Frequently asked questions

Is "Sign in with Google" the same as SSO?

Yes. The consumer "Sign in with Google / Apple / Facebook" buttons are SSO built on the OpenID Connect standard. You authenticate once with the provider, and it vouches for you to the third-party site, which never sees or stores a password for you.

Does SSO mean I have no password at all?

No. You still have one password - the one for your identity provider account. SSO simply means you stop creating a separate password for every connected app. That is why protecting the single remaining password (and adding MFA to it) is so important.

Can I use SSO for my personal accounts, not just work?

Often, yes. Many consumer sites let you sign in with a Google, Apple, or Microsoft account. The trade-off is that those accounts then become central to your online life, so they deserve the strongest possible protection. For sites that offer no SSO option, a password manager remains essential.

What happens if my SSO provider goes down?

You may temporarily lose access to every app that relies on it until the service is restored. This availability risk is one reason to keep backup recovery codes and to ensure your most critical accounts - and any non-SSO accounts - have their own unique passwords stored safely.

The bottom line

Single sign-on lets you log in once and move freely between connected apps, with fewer passwords and centralised security. Under the hood it runs on open standards - SAML, OAuth, and OIDC - that let apps trust an identity provider without ever seeing your password. The trade-off is that the SSO account becomes a single point of failure, so it must be locked down hard with a strong password and phishing-resistant MFA. And because it never covers every account, it works best paired with a password manager - SSO for the connected apps, unique passwords for the rest.