Single sign-on (SSO) is an authentication process that allows a user to authenticate once with an identity provider and then access multiple applications or systems without re-entering credentials. As defined by NIST, SSO uses “one account and its authenticators to access multiple applications in a seamless manner, generally implemented with a federation protocol.”
How It Works
SSO relies on an identity federation trust relationship between an identity provider (IdP) and one or more service providers (SPs), also called relying parties (RPs). The two most common federation protocols underpinning modern SSO are SAML 2.0 and OpenID Connect (OIDC), with Kerberos still prevalent in on-premises Active Directory environments.
The general flow works like this:
- A user attempts to access a protected application (the SP).
- The SP redirects the user’s browser to the organization’s IdP.
- The IdP authenticates the user (via password, MFA, or another method) and issues a signed assertion or token, such as a SAML assertion or an OIDC ID token encoded as a JSON Web Token (JWT).
- The user’s browser delivers this assertion back to the SP.
- The SP validates the signature, checks conditions (audience, expiry, issuer) and establishes a local session.
When the user navigates to a second application that trusts the same IdP, the IdP recognizes the existing authenticated session and issues a new assertion without prompting for credentials again. This is the “single sign-on” experience.
How the assertion reaches the SP depends on the protocol. SAML 2.0 supports multiple binding types, including browser redirects, POST-based form submissions and an artifact model where only a reference token passes through the browser while the full assertion travels over a secure back channel. OIDC takes a different approach through the OAuth 2.0 Authorization Code Flow: the IdP returns an authorization code that the SP exchanges for tokens via a back-channel request, keeping token material out of the browser entirely.
Session management is a critical component because the IdP session defines how long the “single sign-on” experience persists. Default session lifetimes vary widely across providers, from 8 hours in AWS IAM Identity Center to a 90-day rolling window in Microsoft Entra ID, where admins enforce shorter intervals via Conditional Access policies. Google Cloud takes a stricter approach, enforcing reauthentication windows between 1 and 24 hours. When a user needs to end access across all applications at once, SAML defines a Single Logout (SLO) mechanism that terminates sessions at every participating SP and IdP in a single operation.
One distinction worth noting in any SSO implementation: OAuth 2.0 is an authorization framework, not an authentication protocol. OIDC adds the authentication layer on top of OAuth 2.0, issuing ID tokens that verify user identity. Conflating the two is a common source of implementation errors.
Why This Matters for Modern Enterprises
SSO remains a foundational control in enterprise identity architecture. By centralizing authentication at the IdP, organizations reduce password fatigue, shrink the credential attack surface and gain a single enforcement point for policies like MFA and conditional access.
All three major cloud providers treat SSO as a core identity service, though each emphasizes it differently. AWS IAM Identity Center positions itself as a single federation point for AWS access, supporting SAML 2.0, OIDC and OAuth 2.0 grant types including PKCE. Microsoft Entra ID recommends OIDC as the first-choice protocol for new applications and describes federation-based SSO as its richest integration mode. Google Cloud takes an external-IdP-first approach, redirecting users to their organization’s IdP and treating that provider as the system of record.
For enterprises deploying AI agents, automated pipelines and hybrid workloads, SSO plays an important but bounded role. It governs how human administrators and developers authenticate to management consoles, cloud portals and SaaS tools. The Cloud Security Alliance recommends integrating SSO with continuous monitoring and adaptive access policies that evaluate user behavior and device posture, positioning SSO as part of a broader zero-trust verification cycle rather than a standalone authentication event.
That boundary matters in practice. In most enterprise deployments, SSO is designed for interactive, human-initiated authentication. It relies on browser redirects, session cookies and user-present login flows. Non-human identities (workloads, services, scripts, CI/CD jobs) generally cannot open browsers, respond to MFA prompts, or maintain interactive sessions. For these entities, workload identity federation (WIF) applies identity federation principles to machine-to-machine authentication using short-lived tokens, cryptographic attestation and automated credential issuance.
Common Challenges With SSO
Centralizing authentication at a single IdP simplifies access but introduces its own risk surface.
Blast radius concentration. SSO changes the risk topology of an organization’s identity architecture. A compromised SSO session grants the attacker access to every application covered by that session. MFA can be socially engineered, and SSO concentrates trust so that a single compromised identity can escalate into a broader incident. Containing blast radius requires session binding, behavioral anomaly detection and privilege segmentation beyond MFA alone.
IdP as a high-value target. The identity provider becomes a tier-0 asset, equivalent in sensitivity to domain controllers. IdP compromise (whether through administrative account takeover, third-party support access, or supply chain attack) can expose every downstream application. SSO infrastructure, including IdP servers, SAML/OIDC libraries and federation proxies, requires rapid patching and continuous vulnerability monitoring. Recent vulnerabilities in SAML libraries underscore the risk.
Session and token theft. Per OWASP, “no matter how robust the authentication process is, it will not be a sufficient countermeasure for cookie theft.” Stolen session cookies or bearer tokens allow attackers to impersonate authenticated users for the session’s full lifetime. Mitigations include short session lifetimes with absolute expiry, HttpOnly and Secure cookie flags and server-side anomaly detection that triggers re-authentication.
SAML deployments face a protocol-specific risk in XML Signature Wrapping (XSW) attacks. Attackers can manipulate the XML structure of a SAML assertion to bypass signature validation while keeping the signature technically valid against a different element. The OWASP SAML Security Cheat Sheet requires schema validation on all XML documents before security use, along with absolute XPath expressions when locating signed elements.
Non-human identity gap. Classic enterprise SSO patterns are designed for interactive, browser-based user authentication. They are generally not suitable for authenticating workloads, services, or automated processes. Organizations that try to extend these patterns to non-human identities often resort to shared service accounts or long-lived API keys, creating secrets sprawl and undermining the security benefits SSO provides for human users.
IdP availability is another operational concern. If the IdP goes down, every SSO-dependent application becomes inaccessible. Organizations need redundant IdP infrastructure, tested failover procedures and break-glass accounts stored in a secure vault with documented recovery runbooks.
Finally, enterprises often run a mix of SAML 2.0, OIDC, WS-Federation and even Kerberos across legacy and modern applications. Each protocol has distinct metadata exchange, trust configuration and session behavior. Maintaining consistent security posture across all of them adds operational overhead.
FAQ
You Have Questions?
We Have Answers.
What is the difference between SSO and federated identity management?
SSO is a session management pattern that lets a user authenticate once and access multiple applications. Federated identity management (FIM) is the broader architectural framework that establishes trust relationships between separate administrative domains, defining how identity assertions are formatted, signed and validated across organizational boundaries. SSO is a use case of FIM. An organization can implement FIM for cross-domain authorization without necessarily providing an SSO experience, but enterprise SSO almost always depends on federated identity architecture to function across applications. NIST SP 800-63C formalizes this relationship through federation assurance levels (FALs) that set binding security requirements for federation transactions.
How does SSO relate to zero-trust architecture?
In a zero-trust model, SSO is a foundational input, and additional controls still evaluate access throughout the session. NIST SP 800-207 states that “authentication and authorization, both subject and device, are discrete functions performed before a session to an enterprise resource is established,” meaning an SSO token assertion alone does not satisfy zero-trust requirements. A policy enforcement point evaluates each resource access request independently, considering signals like device posture, location, risk score and session context. Microsoft Entra’s Conditional Access and Google’s BeyondCorp both implement this model, treating SSO as one input into continuous, adaptive access decisions.
What is a Golden SAML attack, and how can organizations defend against it?
A Golden SAML attack occurs when an attacker obtains the SAML signing certificate from an IdP, enabling them to forge valid SAML assertions for any user, to any application, with any permissions. Because the forged assertions are cryptographically valid, they bypass IdP authentication entirely and produce no failed-login signals. Defenses include protecting signing certificates with hardware security modules (HSMs), monitoring IdP configuration changes (key exports, certificate rotations) via SIEM, rotating signing certificates on a defined schedule and implementing post-authentication behavioral anomaly detection.
Can SSO be used to authenticate non-human identities like workloads or AI agents?
SSO is designed around an interactive human authentication event: browser redirects, session cookies and user-initiated login flows. Workloads, services, scripts and AI agents operate without a browser or human operator and must authenticate programmatically and continuously. For these non-human identities, workload identity federation (WIF) applies federation principles using short-lived tokens, cryptographic attestation (such as SPIFFE/SPIRE SVIDs) and automated credential issuance. Cloud providers implement WIF as a distinct primitive: Google Cloud WIF exchanges external IdP tokens for federated access tokens, and Microsoft Entra WIF enables secure resource access “without managing secrets.”