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.

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.