Single Sign-On (SSO): How It Works and Security Implications

Single Sign-On (SSO) is an authentication architecture that permits a user to authenticate once and gain access to multiple independent applications or services without re-entering credentials for each. SSO is deployed across enterprise environments, government systems, and consumer platforms, and its configuration decisions carry direct consequences for identity security posture, regulatory compliance, and attack surface exposure. This page covers SSO's technical mechanism, protocol variants, deployment scenarios, and the security tradeoffs that govern implementation decisions.

Definition and scope

SSO is a centralized authentication pattern in which a single authentication event establishes a trusted session that downstream applications accept without requiring independent credential verification. The scope of that trust — which applications accept it, for how long, and under what conditions — defines the security boundary of any SSO deployment.

SSO is not a single protocol. It is a functional outcome achievable through at least 3 distinct protocol families:

SAML protocol and identity and OAuth and OpenID Connect each carry distinct trust models, token lifetimes, and attack surfaces that must be evaluated separately.

NIST SP 800-63C (NIST Digital Identity Guidelines, Federation and Assertions) governs federation assurance levels (FAL1 through FAL3) applicable to US federal agency SSO deployments and serves as a baseline reference for non-federal security architects.

How it works

SSO authentication proceeds through a structured exchange between three parties: the user agent (browser or application client), the Identity Provider (IdP), and the Service Provider (SP) or relying party. The sequence below reflects the SAML 2.0 Web Browser SSO Profile, the most widely deployed enterprise variant:

  1. Access request — The user attempts to access a protected resource at the SP without an active session.
  2. Redirect to IdP — The SP detects no valid session and redirects the user agent to the configured IdP with an authentication request (AuthnRequest).
  3. User authentication — The IdP presents a login interface. The user supplies credentials; the IdP may enforce multi-factor authentication at this step.
  4. Assertion generation — Upon successful authentication, the IdP generates a signed SAML Assertion containing identity attributes and an authentication statement, time-stamped with a validity window (typically 5 minutes for the assertion itself, separate from the session lifetime).
  5. Assertion delivery — The assertion is delivered to the SP via the user agent (POST binding) or directly (artifact binding).
  6. Session establishment — The SP validates the assertion signature against the IdP's public certificate, checks the validity window, and creates a local application session.
  7. Access granted — Subsequent resource requests within the same SP session do not require re-authentication until the session expires or is terminated.

In OAuth 2.0 / OIDC flows, the equivalent exchange involves authorization codes, access tokens, and ID tokens rather than XML assertions. The IdP is referred to as the Authorization Server; identity claims are encoded in a JSON Web Token (JWT). IETF RFC 6749 defines the OAuth 2.0 framework, and RFC 8414 defines Authorization Server metadata discovery.

Session token security is a critical control point. Token signing algorithms, expiration windows, and revocation mechanisms directly govern how quickly a compromised session can be contained — a central concern in credential theft and account takeover scenarios.

Common scenarios

Enterprise workforce SSO — Organizations deploy SSO across internal SaaS applications, on-premises systems, and cloud platforms, routing all authentication through a central IdP such as an LDAP-integrated directory or a cloud identity platform. This architecture intersects with identity and access management (IAM) and directory services and Active Directory.

Federated cross-organization SSO — Two or more independent organizations establish a trust relationship allowing users from one domain to authenticate into another domain's resources. This is the model used in federal agency partnerships under FedRAMP authorization boundaries and in higher education through the InCommon Federation, operated by Internet2, which as of 2023 connected more than 1,000 US higher education and research institutions (Internet2 InCommon).

Consumer-facing social login — Applications delegate authentication to a third-party identity provider (Google, Apple, or similar) using OIDC. While this reduces credential management overhead, it introduces dependency on an external provider's security controls and account recovery policies.

Hybrid identity environments — Enterprises running both on-premises Active Directory and cloud directories implement SSO through synchronization or pass-through authentication, a configuration addressed in hybrid identity environments. Directory synchronization introduces replication latency and potential attribute mismatch risks.

Privileged access SSO — SSO extended to administrative and privileged accounts requires additional controls, as a single compromised SSO session can expose administrative access across multiple systems simultaneously. Privileged access management (PAM) frameworks typically mandate session recording and just-in-time provisioning for privileged SSO pathways.

Decision boundaries

The security calculus for SSO centers on the blast radius of IdP compromise. Centralizing authentication creates a high-value target: an attacker who compromises the IdP — or steals a valid session token — gains access to every SP that trusts that IdP without triggering additional authentication challenges. This is the structural risk that zero trust identity model architectures are designed to constrain by requiring continuous verification rather than relying on session persistence.

Key decision boundaries include:

SSO scope limitation — Not all applications should participate in the same SSO domain. Segmenting SSO boundaries by risk classification (e.g., separating administrative tools from productivity applications) limits lateral movement following token theft.

Session lifetime configuration — NIST SP 800-63B (NIST Digital Identity Guidelines, Authentication and Lifecycle Management) specifies that reauthentication should occur at intervals no longer than 12 hours for standard sessions and 30 minutes for high-assurance sessions, regardless of user activity.

MFA binding — SSO without MFA at the IdP transfers all authentication risk to a single factor. Binding strong MFA to IdP authentication before assertion issuance is a baseline control under FedRAMP High and HIPAA technical safeguard requirements (45 C.F.R. § 164.312(d)).

Token revocation infrastructure — Passive token validation (signature check only) does not support real-time revocation. Active revocation requires token introspection endpoints or short-lived token windows paired with refresh token rotation, as defined in IETF RFC 7009 (OAuth 2.0 Token Revocation).

SAML vs. OIDC selection — SAML 2.0 is suited to enterprise-to-enterprise federation with established XML tooling; OIDC is suited to API-first and mobile-native environments. SAML is susceptible to XML signature wrapping attacks when parser configurations are incorrect; OIDC JWT implementations are susceptible to algorithm confusion attacks when alg header validation is not enforced. Neither protocol is categorically more secure — implementation correctness determines exposure.

Regulatory frameworks governing SSO decisions include NIST SP 800-63C for federal systems, FedRAMP security controls baseline (FedRAMP Authorization Act, 44 U.S.C. § 3614), and HIPAA Security Rule technical safeguards for healthcare environments. Identity security compliance (US) maps these frameworks to specific control requirements.

Identity governance and administration practices govern how SSO access entitlements are provisioned, reviewed, and deprovisioned across the user lifecycle — a process that becomes structurally complex when SSO federates access across dozens of service providers.

References

📜 4 regulatory citations referenced  ·  🔍 Monitored by ANA Regulatory Watch  ·  View update log

Explore This Site

Regulations & Safety Regulatory References Tools & Calculators Password Strength Calculator