What is Single Sign-On (SSO)?
Single Sign-On (SSO) is an authentication method that allows users to log in once with a single set of credentials and gain access to multiple applications or systems without re-entering their password for each one. SSO works by establishing a trusted relationship between a central identity provider (IdP) and multiple service providers (SPs), using protocols like SAML or OpenID Connect to securely pass authentication assertions between them.
SSO has become a foundational component of enterprise identity management, reducing password fatigue and improving both security and user experience. By centralizing authentication, organizations gain a single control point for enforcing policies like Multi-Factor Authentication and can instantly revoke access across all connected applications when an employee leaves.
Modern SSO implementations support both web-based and native applications, spanning on-premises and cloud environments. The rise of cloud-first strategies has accelerated SSO adoption, with platforms like Okta, Microsoft Entra ID, and Ping Identity providing SSO as a core capability of their identity platforms.
How Single Sign-On Works
The SSO authentication flow varies slightly depending on the protocol used, but the general process follows these steps:
- User accesses a service provider -- The user navigates to an application (e.g., a corporate CRM) that requires authentication.
- Redirect to identity provider -- The SP detects the user has no valid session and redirects the browser to the IdP with an authentication request.
- User authenticates -- If the user has no active session at the IdP, they are prompted to log in (potentially with MFA). If they already have an active IdP session, this step is skipped.
- IdP issues assertion -- Upon successful authentication, the IdP generates a security token or assertion (a SAML assertion or an OIDC ID token) containing the user's identity and attributes.
- Assertion delivered to SP -- The assertion is sent to the SP, typically via a browser redirect.
- SP validates and grants access -- The SP validates the assertion's signature and expiration, then creates a local session for the user.
- Subsequent apps skip login -- When the user accesses another SP, the IdP recognizes the existing session and issues a new assertion without prompting for credentials again.
Single Sign-On in Practice
Most enterprises deploy SSO through commercial identity platforms. Microsoft Entra ID (formerly Azure AD) provides SSO for Microsoft 365 and thousands of third-party SaaS applications. Okta and Ping Identity serve as vendor-neutral IdPs connecting disparate applications. Google Workspace offers SSO for organizations in the Google ecosystem. These platforms typically support both SAML for legacy enterprise apps and OpenID Connect for modern web and mobile applications.
In a typical enterprise deployment, IT teams configure SSO connections between the IdP and each application by exchanging metadata -- the IdP's signing certificate and endpoints, and the SP's callback URLs and entity IDs. Many SaaS vendors now offer pre-built SSO integrations, reducing setup from days to minutes.
SSO is often paired with RBAC policies and Zero Trust architectures to ensure that authentication is not just convenient but also tightly controlled. Step-up authentication flows can require additional verification for sensitive applications even within an SSO session.
Common Misconceptions
"SSO means one password for everything, so it's less secure." In reality, SSO improves security by reducing the number of credentials users must manage, which decreases password reuse and phishing risk. Combined with MFA at the IdP, SSO raises the security bar across all connected applications. "SSO and password managers are the same thing." Password managers store multiple credentials that are auto-filled into login forms. SSO eliminates the need for separate credentials entirely by using federated protocols to assert identity. They solve different problems and can complement each other. "If SSO goes down, users are locked out of everything." While the IdP is a critical dependency, enterprise SSO platforms are built for high availability with multi-region failover. Many SPs also offer emergency bypass or local authentication as a fallback.Key Standards & RFCs
- SAML 2.0 (OASIS Standard) -- The most widely used protocol for enterprise SSO, defining XML-based assertions exchanged between IdPs and SPs.
- OpenID Connect Core 1.0 -- A modern, JSON-based identity layer on top of OAuth 2.0 used for SSO in web and mobile apps.
- RFC 7642, 7643, 7644 (SCIM) -- Standards for provisioning user accounts across SSO-connected systems.
- NIST SP 800-63B -- Digital identity guidelines covering authentication assurance levels relevant to SSO deployments.
Frequently Asked Questions
What is Single Sign-On?
Single Sign-On (SSO) is an authentication method that lets users log in once and access multiple applications without needing to authenticate again for each one.
How does SSO work?
SSO works by centralizing authentication at an identity provider that issues security tokens. When a user accesses an application, it redirects to the IdP. If the user already has an active session, the IdP issues a token without requiring another login.
What is SSO used for?
SSO is used in enterprises and consumer platforms to simplify access to multiple applications, reduce password fatigue, improve security posture, and centralize authentication policy enforcement.
What are the benefits of SSO?
Key benefits include reduced password fatigue, fewer help desk password-reset tickets, stronger security through centralized MFA enforcement, improved user experience, and simplified offboarding by revoking access from a single point.
SSO vs Federated Identity?
SSO refers to the user experience of logging in once, while federated identity is the underlying trust architecture that enables SSO across organizational boundaries. Federation is the mechanism; SSO is the outcome.