Browse learn

What Is Single Sign-On?

Learn how single sign-on establishes sessions across applications, how federation protocols carry identity, and where LDAP directories fit.

Type
Concept
Level
Beginner
Technologies
LDAP, SAML, OpenID Connect
On this page

Introduction: Why SSO Matters for Modern Authentication

In an environment where users interact with dozens of applications—cloud services, internal portals, and legacy systems—the friction and risk of managing separate credentials for each become untenable. Traditional logins, where users authenticate separately to each service (sometimes with reused passwords), slow productivity and increase both user frustration and the risk of compromise. Single Sign-On (SSO) has become a fundamental building block for organizations wanting to streamline access, reduce password fatigue, and centralize authentication. For developers and engineers working with LDAP, Active Directory, or directory-backed systems, understanding how SSO differs from—and integrates with—existing directory authentication is crucial for making secure, maintainable architectural decisions.

What Is Single Sign-On (SSO)?

Single Sign-On (SSO) is an authentication framework that allows users to access multiple, related (or even unrelated) applications with a single set of credentials and a single authentication event. After the initial login, subsequent applications trust the user's identity—without requiring repeated credential input—using authentication assertions or tokens from a trusted authority called an Identity Provider (IdP).

SSO is distinct from simple directory authentication (such as an LDAP bind), where each application independently verifies user credentials—often against the same backend directory, but requiring new logins for each system. SSO, by contrast, separates the act of authentication (performed once at the IdP) from the repeated act of session creation or resource access (which uses issued tokens/assertions). SSO is also a subset of federated identity, where this trust relationship sometimes spans organizational boundaries.

How SSO Works: The Technical Workflow

The typical SSO authentication process involves multiple actors:

  • Identity Provider (IdP): Authenticates users and issues tokens.
  • Service Provider (SP): The application or service a user wants to access.
  • User Agent: Typically a browser or client app making authentication requests.

The technical workflow is:

  1. User requests access to a protected resource at a Service Provider (SP).
  2. SP redirects the user agent to an Identity Provider (IdP) for authentication.
  3. User authenticates once with the IdP—using credentials, which may be stored in an LDAP directory, for example.
  4. IdP generates a token or assertion (format depends on protocol: SAML assertion, OIDC ID token, etc.) containing verified claims about the user's identity.
  5. User agent presents this token to the SP.
  6. SP validates the token (checks cryptographic signatures, expiry, intended audience, etc.), trusts the identity claims, and grants access—typically establishing a local session.

The result is that after the first login, any other SP that trusts the same IdP can immediately authenticate the user via a similar token exchange. No new password prompts or directory lookups are necessary for subsequent applications—just token verification.

Examples:

  • In SAML-based web SSO, the IdP returns a signed XML assertion via the user's browser, which the SP consumes to establish the session.
  • In OpenID Connect, after a redirect and login, the IdP issues a JWT-based ID token, which the SP verifies to log the user in.

SSO Protocols: SAML and OpenID Connect Demystified

The interoperability and security of SSO depend on standardized protocols that define how identity assertions are issued, transmitted, and validated:

  • SAML (Security Assertion Markup Language):
    XML-based, widely used for web SSO in enterprise settings. Describes the structure and semantics of assertions about user identity and how those are exchanged between IdPs and SPs. SAML assertions are typically delivered via browser redirects and POSTs.

  • OpenID Connect (OIDC):
    Built on top of OAuth 2.0. Uses signed JSON Web Tokens (JWTs) to carry authentication claims (“ID tokens”). OIDC is now dominant for modern SaaS, APIs, and mobile applications given its JSON format and RESTful design.

  • OAuth 2.0:
    Primarily an authorization protocol. While not an SSO protocol in itself, it underpins OpenID Connect and is sometimes (incorrectly) conflated with federated authentication.

These protocols formalize how authentication is decoupled from the initial credential check, enabling SSO across applications regardless of stack or vendor. Protocol-level integration—such as SAML via the Simple Authentication and Security Layer (SASL) or GSS-API, or OpenID via similar mechanisms—ensures standardized flows between directories, IdPs, and applications.

SSO vs. Traditional Directory Authentication

Traditional directory authentication (for example, an LDAP “bind”) requires each application to directly handle user credentials (typically username/password) and verify them against a directory like LDAP or Active Directory. Each service independently manages sessions, usually storing credentials or session cookies.

Key differences:

  • Authentication locus: SSO centralizes authentication at the IdP; directory authentication is decentralized.
  • Token vs. credential: SSO propagates temporary, signed tokens/assertions; directory authentication requires direct password checks each time.
  • Password exposure: SSO reduces the number of places credentials are transmitted and stored; directory authentication spreads credential handling across multiple apps.
  • Session scope: SSO session can span application boundaries; directory authentication sessions are app-specific.

In SSO architectures, LDAP/Active Directory often supplies the authoritative user database, but only the IdP interacts directly with it. Applications never see credentials; they simply trust the IdP’s assertion.

Benefits and Tradeoffs: Security, Convenience, and Risk

Benefits of SSO:

  • User convenience: One login enables seamless navigation across many services, reducing password fatigue.
  • Reduced attack surface on credentials: Fewer applications directly handle or store passwords.
  • Centralized access control: Administrators can disable access organization-wide by controlling a user’s account in one place.
  • Operational efficiency: Simplifies onboarding and offboarding, as access to a wide range of applications is tied to a single identity.

Tradeoffs and risks:

  • Single point of failure: If the IdP or SSO system is unavailable, all connected services may become inaccessible.
  • Expanded attack surface (IdP-focus): Compromise of the IdP account grants access to all connected applications.
  • Complexity: Requires rigorous token management, trust configuration, and monitoring.
  • Not a silver bullet: SSO does not itself address all authentication security needs; session hijacking, token replay, and improper SP configuration remain real risks.

Implementers must reinforce SSO deployments with additional controls, such as multi-factor authentication (MFA) and monitoring, and ensure the IdP is highly resilient.

Federated Identity and SSO Across Boundaries

Federated identity extends the SSO concept across organizational domains, allowing users in one domain to use their identity in another without creating separate accounts. Trust is established between identity providers from different organizations (via metadata, certificates, or contracts), so an assertion from “Org A” can be trusted by “Org B’s” applications.

SSO within a single company is a subset of federated identity. As SSO architectures scale, federation is vital for business-to-business, cloud, and cross-domain app ecosystems.

SSO in the Directory World: Integration Patterns

SSO and directory services are symbiotic, not synonymous:

  • Directory-backed SSO: The IdP performs the actual credential validation against an LDAP or Active Directory backend, then issues SSO tokens to SPs. The directory remains the system of record, but applications only rely on SSO assertions.
  • Direct directory authentication: Some applications may offer “same sign-on,” authenticating each user by directly binding to LDAP on each login—this is not SSO, as no token is issued or recognized by other applications.

A typical integration: An organization’s IdP connects to their Active Directory via LDAP or Kerberos, authenticates credentials using directory protocols, and then issues SAML or OIDC tokens to applications—on-premises and in the cloud—that never touch the credentials directly.

Real-world Examples and Provider Types

Common SSO patterns include:

  • Enterprise SSO providers: Okta, Microsoft Entra ID (formerly Azure AD), Google Workspace, and OneLogin serve as IdPs orchestrating SSO tokens and directory integration for hundreds of applications.
  • SaaS SSO: Cloud applications (e.g., Salesforce, Slack) delegate authentication to enterprise IdPs via SAML or OIDC, enabling SSO across internal and external tools.
  • Custom SSO layers: Organizations may deploy internal SSO services that front legacy applications, integrating centrally with LDAP for credentialing but delivering modern SAML or OIDC assertions to more capable apps.

SSO protocols used—and depth of directory integration—vary by provider and deployment model.

Enhancing SSO: Multi-Factor Authentication and Compliance

SSO consolidates the authentication experience, but this magnifies the security importance of a user’s session. Multi-factor authentication (MFA) is commonly layered at the point of initial SSO login (at the IdP), requiring additional proof (such as a code or biometric) beyond just a password before issuing a valid authentication token.

Other security reinforcements include:

  • Session monitoring at the IdP and SPs
  • Token lifetime constraints
  • Centralized auditing and anomaly detection

For regulatory compliance, SSO architectures can facilitate better access reviews, ensure timely revocation, and enforce consistent authentication policies across disparate applications.

Summary: SSO as an Architecture, Not Just a Feature

Single Sign-On is not merely a checklist feature, but a fundamental architecture for modern identity and access management. SSO untangles the complexity of multi-application authentication by introducing a central identity provider, removing direct password handling from most applications, and standardizing authentication via protocols like SAML and OpenID Connect. For developers and identity engineers, SSO is an integration pattern—where directory services often act as the identity source, but protocol-based SSO assertions and careful trust relationships drive user authentication and session management.

Designing and deploying SSO requires not just protocol support, but robust security practices, careful attention to failure modes, and alignment between directory/IdP integration and overall access strategy. With this perspective, teams can implement SSO confidently—maximizing both security and convenience across their organization’s digital landscape.

Sources:

  • RFC 6595
  • RFC 6616
  • RFC 9560
  • RFC 3748

Sources

Related resources