What Is Single Sign-On (SSO)?

What Is Single Sign-On?

Single sign-on lets a user authenticate once and then access multiple independent applications without logging in again. A central identity provider authenticates the user and issues a token that each connected application accepts as proof of identity. The key idea is separation: SSO splits the act of proving who you are from the individual applications that need to know it.

• The user proves their identity one time, to the identity provider, not to each app.
• The applications, called service providers or relying parties, delegate authentication to the identity provider instead of storing and checking passwords themselves.
• One session covers every application that trusts the same identity provider, until it expires or the user logs out.

SSO does not remove authentication; it centralizes it. The underlying act of verifying a claimed identity is covered in what authentication is, and SSO simply moves that act to one trusted place.

How Does Single Sign-On Work?

SSO works by redirecting you to an identity provider that authenticates you once and hands each application a signed token proving you already logged in. The first app you open triggers the login; every app after it rides the same session.

• You open an app. You request a service (the relying party), which sees no active session and redirects you to the identity provider.
• You authenticate once. The identity provider checks a factor, a password, a passkey, or multi-factor, against its records. This is the only time you type a credential.
• The identity provider issues a signed token. It mints a cryptographically signed assertion (SAML) or token (an OpenID Connect ID token) that states who you are and when you were verified.
• The app validates and grants access. The application checks the signature against the identity provider’s key and lets you in, without ever seeing your password.
• The next app trusts the same session. When you open another connected app, the identity provider recognizes your existing session and issues a fresh token, so you reach it without logging in again.

The signature is what makes this safe: the application trusts the token because only the identity provider could have signed it, not because it saw your password. Note that the login session at the identity provider and the local session at each app are separate things with separate lifetimes, which is why a stolen token can be limited by short session windows.

SAML vs OpenID Connect: Which Protocol Does SSO Use?

SSO is built mainly on three standards: SAML, OAuth 2.0, and OpenID Connect, and the practical choice for most logins comes down to SAML versus OpenID Connect. They do not compete so much as fit different eras and surfaces.

One point causes constant confusion: OAuth 2.0 on its own is an authorization framework, not an authentication protocol. It grants an app permission to access a resource (an access token), but it does not, by itself, prove who you are. OpenID Connect is the layer that adds identity to OAuth. The deeper split between proving identity and granting permission is covered in authentication vs authorization.

• SAML: XML assertions, browser-based, enterprise default. WS-Federation plays a similar role in some Microsoft estates.
• OAuth 2.0: authorization only, issues access tokens for delegated API access, not a login protocol on its own.
• OpenID Connect: authentication layer on OAuth 2.0, issues an ID token, the modern and consumer standard.

What Is an Identity Provider?

An identity provider (IdP) is the system that authenticates users and issues the tokens every connected application trusts. It holds the central credential store and the authentication logic, so it is the one place a user actually logs in.

• Authentication: confirms identity through passwords, passkeys, or multi-factor methods.
• Token issuance: produces signed assertions or tokens that connected applications accept as proof of identity.
• Session management: tracks the active login so later applications skip a second authentication.
• Account control: centralizes provisioning and, critically, deprovisioning across every connected application.

Named identity providers include Microsoft Entra ID, Okta, Google Workspace, and Ping Identity. Because the identity provider authenticates every login, hardening it with strong factors and access control policies protects every connected application at once.

What Are Examples of Single Sign-On?

The clearest everyday examples are the social buttons (Sign in with Google, Sign in with Apple) and enterprise portals that open many internal tools from one login. Both patterns use the same delegation model under the hood.

• Sign in with Google: uses OpenID Connect so a third-party site can authenticate you through your Google account, the most common form of consumer SSO.
• Sign in with Apple: authenticates through an Apple ID and can relay a private, masked email to limit what the site learns about you.
• Microsoft 365: one Entra ID login opens Outlook, Teams, and SharePoint without separate sign-ins.
• University and corporate portals: one institutional login opens email, learning systems, and payroll.

Social login and enterprise SSO use the same kind of tokens. The difference is who runs the identity provider, a consumer platform like Google in one case, an internal directory in the other.

What Are the Benefits of Single Sign-On?

SSO delivers fewer passwords, central access control, faster access, and a stronger single point to enforce multi-factor authentication. The gains land on both sides of the login: users juggle less, administrators control more.

• Fewer passwords: one credential replaces a separate password per app, which directly attacks reuse, the habit behind most account takeovers (NordPass reports 94 percent of passwords are reused).
• Central access control: administrators grant or revoke access to every connected app from one console.
• Faster access: repeated login prompts disappear within a session.
• Stronger authentication, once: multi-factor and phishing-resistant factors are enforced at the identity provider instead of unevenly across dozens of apps.

Central deprovisioning is the benefit administrators value most: disabling one identity provider account instantly removes access to every connected application, which closes the orphaned-account gap when an employee leaves. Organizations that moved to passwordless and federated login have reported password-reset support tickets falling by around 90 percent.

What Are the Risks of Single Sign-On?

The same concentration that makes SSO convenient also makes it a single point of failure: a compromised identity provider account or session can expose every connected application at once. The blast radius of one breach grows with the number of apps behind the login.

• Single point of failure: one stolen credential can unlock every connected application, turning a single account compromise into an organization-wide breach.
• Identity provider outage: if the central service is down, users may be unable to log in to anything that depends on it.
• Session hijacking: an attacker who steals an active token or session can reach every app it covers, without ever knowing the password.
• Targeted phishing: the identity provider login becomes the one credential worth attacking, and a breach of an identity vendor can ripple to its customers, as the 2023 Okta support-system incident showed.

How Is Single Sign-On Risk Mitigated?

You contain SSO risk by hardening the one credential that controls everything: enforce multi-factor authentication at the identity provider and keep sessions short and conditional. The goal is to make the central login extremely hard to steal and quick to expire.

• Multi-factor authentication on the identity provider: the highest-impact control, it blocks access even when a password is stolen. See multi-factor authentication.
• Phishing-resistant factors: passkeys and hardware security keys bind the login to the real site, so a fake page captures nothing reusable.
• Short sessions and re-authentication: tight session lifetimes shrink the window in which a stolen token is useful.
• Conditional access: device posture, location, and risk signals are evaluated before a session is granted or allowed to continue.

For the most sensitive systems, some organizations also keep a second, independent root of trust so that a breach of the SSO provider alone does not unlock everything. The single biggest lever, though, remains a phishing-resistant second factor on the identity provider.

How Does Single Sign-On Differ From a Password Manager?

SSO gives you one authenticated session across apps; a password manager keeps a separate password for each app and fills it for you. Both cut the password burden, but through opposite mechanisms, and they work well together.

• Single sign-on: authenticates once at an identity provider and issues tokens, so the app never sees a password at all.
• Password manager: stores and autofills a distinct, strong password for every separate account.
• Coverage: SSO needs the app to support a federation protocol such as SAML or OpenID Connect; a password manager works on any site, including ones that offer no SSO.
• Together: SSO handles the federated set, and the password manager covers everything outside it.

So they are complements, not rivals. The selection and use of a password manager appears in the guide on how to set up and use a password manager.

What Is the Difference Between SSO and Federated Identity?

Single sign-on usually operates within one trust domain, while federated identity extends that same model across separate organizations. The concepts overlap; the difference is scope.

• Single sign-on: one session across applications that trust a single identity provider, typically inside one organization.
• Federated identity: links identity providers across organizational boundaries through agreed trust relationships.
• The protocols are shared: SAML and OpenID Connect carry assertions between domains that do not share a directory.
• Cross-domain trust: lets a user from one company reach a partner application without a separate account there.

A Sign in with Google button on a third-party site is federation in action: the site and the identity provider belong to different organizations, yet the same token model carries the login across the boundary.

What Is Single Logout in Single Sign-On?

Single logout is the function that ends a user’s session across every connected application at once, reversing what single sign-on set up. Without it, logging out of one app could leave the others quietly open.

• Session termination: signals each connected application to end its local session when the user logs out.
• Identity provider coordination: propagates the logout from the identity provider out to every relying application.
• Token revocation: invalidates issued tokens so they cannot grant further access.
• Incomplete-logout risk: remains if an application fails to honor the logout signal, leaving one session open.

Single logout matters most on shared or public devices, where one missed session can hand the next person an open door. A complete logout shrinks that exposure window.

Single Sign-On Protocol Comparison

The table below compares the primary single sign-on protocols across purpose, token format, and typical use.

Last Thoughts on Single Sign-On

Single sign-on centralizes authentication so one login reaches every connected application through an identity provider and signed tokens. SAML carries that trust in enterprise web apps, while OpenID Connect, built on OAuth 2.0, carries it in modern and consumer logins such as Sign in with Google. The convenience of fewer passwords and one place to enforce strong authentication is real, but it arrives with a single point of failure, which multi-factor authentication, phishing-resistant passkeys, and short sessions at the identity provider exist to contain.

SSO reduces password burden differently from a password manager and works alongside one, covering the federated set while the manager handles the rest. The hub on cybersecurity situates single sign-on within the wider field of identity and access management.

Key Takeaways:

• Single sign-on lets a user authenticate once at an identity provider and reach many applications without logging in again.
• The identity provider issues a cryptographically signed token, so connected apps never handle your password.
• SAML (XML, enterprise) and OpenID Connect (JSON on OAuth 2.0, modern and consumer) are the protocols you meet most; OAuth alone is authorization, not authentication.
• Sign in with Google and Sign in with Apple are consumer SSO, and federated identity extends the same model across organizations.
• The main benefits are fewer reused passwords, central access control, and one place to enforce multi-factor authentication.
• SSO is a single point of failure, so phishing-resistant MFA and short sessions on the identity provider are what keep it safe.

Frequently Asked Questions (FAQs)