What Is Single Sign-On (SSO)?

How SSO Works

SSO uses a centralized identity provider (IdP) — Microsoft Entra ID, Okta, Google Workspace — to authenticate users once and then issue authentication tokens that are accepted by all connected applications. The technical mechanism varies by protocol. SAML (Security Assertion Markup Language) is the standard for enterprise SSO with business applications. OAuth 2.0 and OpenID Connect (OIDC) are used for modern web and mobile applications. When a user attempts to access a connected application, the application redirects to the identity provider for authentication. The identity provider verifies the user's identity and issues a token asserting successful authentication, which the application accepts to grant access.

The Security Trade-Off

SSO creates a single point of authentication that, if secured effectively, provides comprehensive identity control across all connected applications. The security benefit is significant: consistent MFA enforcement, consistent conditional access policies, and centralized session management across all applications. The security risk is equally significant: if the SSO identity provider is compromised, all connected applications are simultaneously compromised. This is why identity provider security — phishing-resistant MFA for privileged accounts, robust conditional access, and continuous monitoring of authentication activity — is the highest-priority security investment in an SSO environment.

SSO and Shadow IT

Organizations that have deployed SSO for their known application portfolio frequently have a significant shadow IT problem: applications in use by employees that are not integrated with the corporate identity provider and therefore not subject to SSO security controls. A finance employee who signed up for a productivity tool using their corporate email address but without SSO integration has created an account that is not governed by corporate authentication policies, is not subject to MFA enforcement, and is not visible to the security team. Shadow IT creates authentication islands that are harder to inventory and govern than the known SSO application portfolio.

SSO in M&A Integration

Identity consolidation — migrating acquired company users to the acquiring organization's identity provider — is one of the most consequential post-close integration activities. The target company's users may have separate identity providers, separate application portfolios, and separate authentication policies. Integration requires mapping users, migrating application SSO configurations, and establishing access governance for the combined organization's application portfolio. Identity integration done poorly creates lasting access control problems — orphaned accounts with access to both environments, inconsistent MFA enforcement, and visibility gaps that persist long after the technical integration is nominally complete.

Related Reading

• What is Active Directory and Why Attackers Target It?
• What is Credential Stuffing?

What is single sign-on (SSO)?

Single Sign-On (SSO) is an authentication mechanism that allows users to access multiple applications with one set of credentials, authenticated once through a centralized identity provider. Rather than maintaining separate usernames and passwords for every application, users authenticate once to the identity provider and receive access to all connected applications for the duration of their session. SSO is the foundation of modern enterprise identity management.

How does SSO work technically?

SSO uses a centralized identity provider (IdP) — Microsoft Entra ID, Okta, Google Workspace — to authenticate users and issue authentication tokens that connected applications accept. When a user tries to access a connected application, the application redirects to the IdP for authentication. The IdP verifies the user's identity and issues a token asserting successful authentication; the application accepts the token and grants access. The protocols are SAML (enterprise applications), OAuth 2.0 (API authorization), and OpenID Connect (modern web and mobile).

What is the difference between SSO and SAML?

SSO is the user-facing capability — sign in once, access everything. SAML (Security Assertion Markup Language) is one of the technical protocols that implements SSO between an identity provider and a service provider. Most enterprise SSO deployments for SaaS applications use SAML. OAuth 2.0 and OpenID Connect are alternative protocols used for modern web applications and APIs. SSO is the experience; SAML is one way to build it.

What is the difference between SSO and federation?

SSO is a user experience — one login covers many applications. Federation is the technical relationship between identity systems that enables that experience across organizational boundaries. A federation relationship between Company A's identity provider and Company B's identity provider allows Company A's users to access Company B's applications without a separate account. SSO within a single organization uses federation between the IdP and each application; cross-organization SSO uses federation between identity providers.

Is SSO secure?

SSO concentrates authentication risk — a compromised identity provider exposes all connected applications simultaneously. This is the trade-off for SSO's benefits (consistent MFA enforcement, conditional access, centralized session management, fast deprovisioning). The security calculus is positive when the identity provider is hardened with phishing-resistant MFA for privileged accounts, conditional access policies, and continuous monitoring. The SolarWinds attackers' SAML token forgery technique demonstrates the risk profile: compromise the IdP's signing certificate and forge access to everything connected.

What identity providers offer SSO?

Microsoft Entra ID is the dominant enterprise identity provider, included in Microsoft 365 licensing. Okta is the leading independent identity platform. Google Workspace provides SSO for organizations on Google's productivity suite. Ping Identity, OneLogin, and Auth0 (now Okta) serve specialized use cases. JumpCloud targets SMB markets. For most mid-market organizations, the choice is between Entra ID (if Microsoft 365 is the platform) and Okta (for vendor-neutral identity).

How does SSO interact with shadow IT?

Applications signed up for outside the SSO governance — typically by employees using their corporate email but creating direct accounts — create authentication islands. These accounts are not subject to corporate MFA enforcement, are not visible to security teams, and are not deprovisioned automatically when employees leave. Effective SSO programs combine technical integration with policy enforcement and discovery tools (Microsoft Defender for Cloud Apps, Netskope, Zscaler) that identify unsanctioned application use.

Real-World Example: The SolarWinds SAML Forgery

The SolarWinds attackers' most sophisticated technique involved forging SAML authentication tokens — the authentication tokens that SSO systems use to grant access to connected applications. After compromising the ADFS (Active Directory Federation Services) token signing certificate at victim organizations, the attackers could generate SAML tokens that impersonated any user to any connected application. The SSO architecture that was supposed to centralize and secure authentication became the mechanism for universal access. The attack worked because SSO systems trust properly signed SAML tokens unconditionally — and the attackers had the signing certificate. This attack underscores the critical importance of monitoring for anomalous SSO authentication patterns, including token issuance without corresponding user sessions.