What is single sign-on (SSO)?

The problem SSO solves

Before SSO, every application a company used typically had its own login, its own password rules and its own account to manage. Employees ended up juggling dozens of credentials, which pushed them towards weak, reused passwords, and it left IT teams managing accounts across systems that didn’t talk to each other — someone who left the company might still have working logins on tools nobody remembered to revoke. SSO centralises that: one identity, managed in one place, that every connected application trusts.

How it works, at a beginner level

An identity provider (IdP) is the trusted authority that actually checks who you are — verifying your password, your MFA, or both. When you try to use a connected application, that application doesn’t check your credentials itself; it redirects you to the identity provider, and if you’re not already signed in there, you authenticate once. The identity provider then issues a signed token or assertion confirming your identity, and the application accepts that as proof without ever seeing your password.

Two standards do most of this work behind the scenes: SAML (Security Assertion Markup Language), an older XML-based standard common in enterprise software, and OpenID Connect, a newer, more web-friendly standard built on top of OAuth. You don’t need their protocol-level detail to use SSO — the takeaway is simply that a trusted third party vouches for you, using a signed, standardised message the receiving application can verify.

Why organisations adopt SSO

SSO delivers two benefits that reinforce each other. For users, it means signing in once instead of many times, with fewer passwords to remember and fewer login prompts interrupting the day. For the organisation, it means centralised control: administrators can enforce a single strong authentication policy (including multi-factor authentication) at the identity provider, and — crucially — deactivating one account there instantly cuts off access to every connected application, rather than requiring someone to remember and disable a dozen separate logins when an employee leaves.

SSO vs a password manager

It’s easy to conflate the two because both reduce how often you type a password, but they solve different problems. A password manager stores many separate passwords and autofills the right one for each site — you still technically have a unique account and credential per service, just retrieved for you. SSO removes the separate credentials entirely: connected applications don’t have their own password for you at all, only a trust relationship with the identity provider. A password manager helps you cope with many accounts; SSO reduces the number of accounts that exist in the first place.

SSO in the cloud

Enterprise identity providers such as Microsoft Entra ID are built around exactly this model — an organisation’s central directory of users, connected to Microsoft 365, countless third-party SaaS tools and custom internal apps, all authenticating through the one identity provider via SAML or OpenID Connect. This sits inside the broader discipline of identity and access management: SSO governs how you prove who you are, while IAM policies then govern what you’re allowed to do once you’re in.