What Is Single Sign-On (SSO)?

Single sign-on is an authentication scheme that lets a user log in once to access many separate applications without re-entering credentials. Single sign-on, abbreviated SSO, replaces a separate password for every service with one authenticated session managed by a central identity provider. A user who signs in once reaches email, document storage, and internal tools without a second login.

This article defines single sign-on, explains how the identity provider and tokens operate, describes the SAML, OAuth, and OpenID Connect protocols, lists the “log in with Google” and “log in with Apple” examples, states the benefits of fewer passwords and central control, examines the single point of failure risk and its mitigation, and separates single sign-on from a password manager. The Security Assertion Markup Language standard, the OAuth 2.0 framework, and the OpenID Connect specification supply the references used here. Each section answers one question about single sign-on and connects to the next.

What Is Single Sign-On?

Single sign-on is an authentication scheme that 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. Single sign-on separates the act of proving identity from the individual applications.

The applications, called service providers or relying parties, delegate authentication to the identity provider rather than storing and checking passwords directly. A single authenticated session covers every application that trusts the same identity provider.

How Does Single Sign-On Work?

Single sign-on works by redirecting the user to an identity provider that authenticates the user once and returns a signed token to each application. The token proves the user already authenticated. The list below states the operating sequence.

1. The user requests an application, and the application redirects the user to the identity provider.
2. The identity provider authenticates the user with a password, a passkey, or another factor.
3. The identity provider issues a signed token or assertion that confirms the authenticated identity.
4. The application validates the token signature and grants access without a separate password.
5. Later applications accept the existing session, so the user reaches each one without re-entering credentials.

The token carries a cryptographic signature that the application verifies against the identity provider. This delegation of identity rests on the broader process explained in the overview of how authentication verifies a claimed identity, which single sign-on centralizes rather than removes.

What Protocols Does Single Sign-On Use?

Single sign-on uses SAML, OAuth 2.0, and OpenID Connect as its primary protocols. Each protocol fills a defined role in identity and access. The list below names the standards.

• Security Assertion Markup Language, SAML, exchanges XML-based authentication assertions and dominates enterprise single sign-on.
• OAuth 2.0 authorizes access to resources by issuing access tokens, though OAuth handles authorization rather than authentication on its own.
• OpenID Connect adds an identity layer on top of OAuth 2.0 and issues an ID token that confirms who the user is.
• WS-Federation supports single sign-on in some Microsoft enterprise environments alongside SAML.

SAML serves browser-based enterprise applications, while OpenID Connect serves modern web and mobile applications built on OAuth 2.0. The distinction between proving identity and granting permission appears in the comparison of how authentication differs from authorization.

What Is an Identity Provider?

An identity provider is the system that authenticates users and issues the tokens that applications trust. The identity provider, abbreviated IdP, holds the central credential store and the authentication logic. The list below states the identity provider functions.

• Authentication confirms the user identity through passwords, passkeys, or multi-factor methods.
• Token issuance produces signed assertions that connected applications accept as proof of identity.
• Session management tracks the active login so subsequent applications skip a second authentication.
• Account control centralizes provisioning and 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 protects every connected application at once.

What Are Examples of Single Sign-On?

Common examples of single sign-on include “log in with Google,” “log in with Apple,” and enterprise portals that open many internal tools. These social and enterprise patterns share the same delegation model. The list below states the primary examples.

• “Log in with Google” uses OpenID Connect to authenticate a user to third-party sites through a Google account.
• “Log in with Apple” authenticates through an Apple ID and supports a private email relay to limit data sharing.
• Microsoft 365 signs a user into Outlook, Teams, and SharePoint through one Entra ID login.
• University and corporate portals open email, learning systems, and payroll through a single institutional login.

Social login and enterprise single sign-on use the same underlying tokens. The difference lies in who operates the identity provider, a consumer platform or an internal directory.

What Are the Benefits of Single Sign-On?

Single sign-on delivers fewer passwords, central access control, and reduced password fatigue. The benefits apply to users and to administrators. The list below states the primary advantages.

• Fewer passwords reduce the number of credentials a user must create and remember.
• Central control lets administrators grant or revoke access to every connected application from one place.
• Faster access removes repeated login prompts across applications in a single session.
• Stronger authentication concentrates multi-factor enforcement at the identity provider rather than at each application.

Central deprovisioning matters at scale, because disabling one identity provider account removes access to every connected application immediately. This control reduces the risk of orphaned accounts after an employee departs.

What Are the Risks of Single Sign-On?

Single sign-on creates a single point of failure, because a compromised identity provider account exposes every connected application. The concentration that delivers convenience also concentrates risk. The list below states the primary risks.

• Single point of failure means one stolen credential can unlock every connected application at once.
• Identity provider outage blocks access to all applications when the central service is unavailable.
• Session hijacking lets an attacker who steals an active token reach every application in the session.
• Phishing of the identity provider login targets the one credential that opens the entire account.

The concentration of risk raises the value of the identity provider credential to an attacker. Mitigation centers on protecting that single login, addressed in the next section.

How Is Single Sign-On Risk Mitigated?

Single sign-on risk is mitigated by enforcing multi-factor authentication at the identity provider and applying continuous session checks. The mitigation hardens the one credential that controls every application. The list below states the primary controls.

• Multi-factor authentication on the identity provider blocks access even when a password is stolen.
• Phishing-resistant factors such as passkeys remove the shared secret that phishing pages capture.
• Short session lifetimes and re-authentication limit the window an attacker can use a stolen token.
• Conditional access evaluates device, location, and risk signals before granting or continuing a session.

Adding a second factor at the identity provider is the highest-impact control. The methods that supply that second factor appear in the overview of how multi-factor authentication adds verification layers.

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

Single sign-on uses one authenticated session across applications, while a password manager stores a separate password for each application. The two tools reduce password burden through different mechanisms. The list below states the distinction.

• Single sign-on authenticates once at an identity provider and issues tokens to each application.
• A password manager stores and fills a distinct password for every separate account.
• Single sign-on requires the application to support a federation protocol such as SAML or OpenID Connect.
• A password manager works with any site, including those that do not support single sign-on.

A password manager complements single sign-on by handling accounts outside the federated set. The selection and use of such tools appear 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 operates within one trust domain, while federated identity extends single sign-on across separate organizations. The two concepts overlap but differ in scope. The list below states the distinction.

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

Federated identity uses the same tokens as single sign-on but spans organizations. A “log in with Google” button on a third-party site is federation, because the site and the identity provider belong to different organizations.

What Is Single Logout in Single Sign-On?

Single logout is the function that ends a user session across every application connected through single sign-on at once. Single logout reverses the single sign-on session. The list below states how single logout operates.

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

Single logout addresses the risk that a single sign-on session leaves multiple applications open after a user steps away. A complete logout reduces the exposure window on shared or public devices.

Key Takeaways

• Single sign-on lets a user authenticate once to reach many applications.
• An identity provider authenticates the user and issues signed tokens.
• SAML, OAuth 2.0, and OpenID Connect are the core protocols.
• “Log in with Google” and “log in with Apple” are consumer examples.
• Benefits include fewer passwords and central access control.
• A compromised identity provider account is a single point of failure.
• Multi-factor authentication at the identity provider mitigates the main risk.

Single Sign-On Protocol Comparison

The table below compares the primary single sign-on protocols across purpose, 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. The SAML, OAuth 2.0, and OpenID Connect protocols carry that trust, and consumer patterns such as “log in with Google” use the same model as enterprise portals. The convenience of fewer passwords and central control comes with a single point of failure, which multi-factor authentication and short sessions at the identity provider mitigate.

Single sign-on reduces password burden differently from a password manager and works alongside one. The hub on cybersecurity concepts and access defenses situates single sign-on within the broader field of identity and access management.