What Is Single Sign-On SSO?

Single sign-on (SSO) is an authentication method that allows users to access multiple applications or services with one set of login credentials.

What Is Single Sign-On?

Single sign-on is an identity federation pattern in which a user authenticates once with a trusted identity provider (IdP) and then receives cryptographically signed assertions or tokens that other applications (called service providers) accept as proof of identity. After the initial login, the IdP issues time-bounded credentials (e.g., SAML assertions or OpenID Connect ID tokens) that the browser or client presents to each application, which verifies the signature, audience, and expiration before establishing its own session.

Because trust is anchored in the IdP and conveyed through standards-based protocols, SSO lets independent systems share a consistent view of who the user is, what attributes they have, and how long their authentication should be considered valid.

Types of Single Sign-On

Below are the most common types you’ll encounter and what each one achieves.

SAML 2.0 Federation

Security Assertion Markup Language (SAML) is an XML-based standard widely used for browser SSO into enterprise SaaS. After authenticating at the Identity Provider (IdP), the user’s browser receives a signed SAML assertion that the Service Provider (SP) validates to establish a session.

SAML is mature, excels at enterprise attribute release (roles, groups), and is common for HRIS-to-SaaS and ADFS-to-cloud integrations.

OpenID Connect (OIDC)

OIDC sits on top of OAuth 2.0 and uses JSON Web Tokens (JWTs) for identity. After authenticating with the IdP, the client obtains an ID token (who you are) and often an access token (what you can call).

OIDC is lighter than SAML, mobile- and API-friendly, and ideal for modern web and mobile apps, single page applications (SPAs), and microservices that need standardized, compact tokens.

Kerberos/Integrated Windows Authentication (IWA)

In Kerberos-based SSO (e.g., with Active Directory), the OS acquires a ticket from a Key Distribution Center and transparently presents it to services, enabling “silent” SSO on corporate networks. It’s fast, mutual-auth capable, and great for on-prem apps and intranets, because modern setups often bridge Kerberos identities to cloud via federation.

OAuth 2.0–Backed SSO (Token-Based Access)

OAuth itself is an authorization framework, not an identity protocol, but many SSO deployments pair it with OIDC or custom identity endpoints to let users sign in once and obtain access tokens for APIs. The result is SSO across web and service layers with short-lived tokens, scopes, and refresh flows suited to zero-trust designs.

WS-Federation (WS-Fed)

An older, SOAP-oriented Microsoft federation protocol still present in legacy ADFS and SharePoint scenarios. It enables browser SSO similar to SAML but is less common in greenfield projects. Instead, organizations often migrate WS-Fed apps to OIDC/SAML as part of cloud modernization.

CAS (Central Authentication Service)

This is a simple, ticket-granting protocol popular in higher education. Users authenticate to a central CAS server, which issues service tickets that applications validate. CAS is straightforward to operate and extend but lacks the richer claim and token ecosystems of SAML/OIDC.

Reverse-Proxy/Header-Based SSO

A gateway authenticates users (via Kerberos, SAML, OIDC, or MFA) and injects identity headers (e.g., X-Remote-User) to backend apps that don’t speak federation protocols. It’s useful for retrofitting legacy apps, but security depends on strictly trusting only the proxy and hardening direct app access.

Password Vaulting/Form-Fill SSO

As a last-resort method for apps without federation support, an access gateway securely stores per-user credentials and programmatically logs them in. It improves convenience but doesn’t provide true federation, and tasks like credential rotation, MFA enforcement, and auditing become more complex than with standards-based SSO.

How Does Single Sign-On Work?

SSO lets a user authenticate once with a trusted identity provider and reuse that proof to access many applications (service providers, SPs) securely. Here is exactly how it works:

1. Initiation and IdP discovery. The user tries to open an app. The app (SP) detects no local session and redirects the user (often via SAML/OIDC metadata) to the correct IdP, establishing where trust and login will occur.
2. User authentication at the IdP. The IdP validates identity using configured methods, such as a password and MFA, passkeys or device posture checks, creating a fresh authentication context with a precise timestamp and assurance level.
3. Token/assertion issuance. Upon success, the IdP issues a signed, time-bounded credential (e.g., SAML assertion, OIDC ID token and access token) containing the user’s identifier and claims/attributes.
4. Secure delivery back to the app. The browser or client returns to the SP carrying the credential via a secure binding (POST/redirect front-channel or back-channel token exchange), preserving integrity and preventing tampering or replay.
5. Verification and session creation. The SP validates the signature, audience, issuer, nonce, and expiration. If checks pass, it establishes an app session (cookie or token) and applies authorization based on roles or claims.
6. Token refresh and step-up (as needed). As sessions age or access sensitivity increases, the client uses refresh or re-auth flows to obtain new tokens or step-up MFA, keeping access continuous without repeated full logins.
7. Logout and revocation. When the user signs out or risk is detected, the SP ends its session. Optionally, Single Logout (SLO) or back-channel revocation at the IdP propagates sign-out to other apps to close remaining sessions.

What Is an Example of an SSO?

An example of an SSO is when an employee browses Salesforce without a local session, so Salesforce redirects them to Okta (the organization’s Identity Provider). The user completes Okta’s login and MFA, and Okta issues a signed, short-lived SAML assertion containing the user’s ID and roles.

The browser posts this assertion back to Salesforce, which verifies the signature, audience, and expiration, then creates its own session and applies the user’s permissions, so no separate Salesforce password needed. Subsequent logins to other connected apps (e.g., ServiceNow, Box) reuse the Okta session, giving seamless access across apps with centralized policy and audit.

What Are the Benefits and Disadvantages of Single Sign-On?

Single sign-on streamlines access by letting users authenticate once and reach many apps, improving user experience and centralizing security controls. However, concentrating authentication also raises risk and complexity: if the identity tier fails or is misconfigured, many apps are affected at once. For this reason, careful design is needed to balance convenience with strong safeguards.

What Are the Benefits of Single Sign-On?

SSO improves user experience and centralizes control by federating authentication through a trusted identity provider. Here are its main benefits:

• Fewer passwords, better UX. Users sign in once and access all apps, reducing friction and login fatigue.
• Stronger security controls. Centralized MFA, passkeys, device posture checks, and conditional access apply uniformly across apps.
• Faster onboarding/offboarding. Granting or revoking access comes from one identity record, so changes propagate to all connected services.
• Lower support costs. Fewer password resets and account lockouts mean fewer help-desk tickets.
• Consistent governance. Roles, groups, and attribute-based policies are enforced the same way everywhere, supporting least privilege.
• Better visibility and audit. Central logs and standardized tokens simplify monitoring, incident response, and compliance reporting.
• Reduced phishing risk. Users recognize a single, hardened IdP login flow, so there are fewer app-specific passwords to steal.
• Modern app and API readiness. Standards (OIDC/SAML/OAuth) enable secure access for web, mobile, and microservices with short-lived tokens.
• Safer change management. Token lifetimes, session policies, and step-up auth let you raise assurance for sensitive actions without new logins.
• Improved productivity. Seamless cross-app access shortens context switches and accelerates workflows.

What Are the Disadvantages of Single Sign-On?

Centralizing authentication brings real benefits, but it also creates technical and operational risks you must manage. Here are the main challenges:

• Single point of failure and blast radius. If the IdP is down or misconfigured, many apps become inaccessible at once.
• Misconfiguration risk. Weak token validation (audience/issuer/nonce), long expirations, or permissive attribute release can open doors to impersonation and privilege creep.
• Session and token hygiene. Balancing convenience with security (such as managing idle and absolute timeouts, refresh tokens, step-up MFA) is tricky, and overly long sessions increase takeover risk.
• Certificate and key management. Rotating signing keys, handling metadata updates, and clock skew require disciplined ops or logins can fail silently.
• Logout complexity. Single logout (SLO) support is inconsistent and partial sign-outs leave residual app sessions.
• Legacy and edge cases. Non-federated apps force password vaulting or header injection, adding fragility and weaker security than true federation.
• Account linking and lifecycle. Mapping identities across directories and tenants, JIT provisioning, and timely deprovisioning are error-prone without clean HR and IAM sources.
• Access policy sprawl. Conditional access, device posture, and per-app exceptions can become hard to reason about, causing outages or gaps.
• Vendor and standards lock-in. Proprietary features or protocol quirks make migrations costly and multi-IdP strategies harder.
• Privacy and data minimization. Over-sharing attributes across apps increases exposure, so least-attribute release and consent controls are needed.
• Phishing and abuse concentration. A single hardened flow helps, but if attackers capture IdP credentials/session, they inherit broad access.

Single Sign-On FAQ

Here are the answers to the most commonly asked questions about single sign-on.

What Is the Difference Between SSO and AD?

Let’s examine the differences between single sign-on and Active Directory (AD) in more detail:

Is Single Sign-On Secure?

Yes, when implemented correctly, single sign-on is very secure because it centralizes strong controls (MFA/passkeys, conditional access, device posture checks) at a hardened identity provider and issues short-lived, signed tokens that each app verifies. The main risks stem from architecture rather than from SSO itself. An IdP outage or misconfiguration can affect many apps, and long-lived or weakly validated tokens increase takeover risk.

SSO should also be combined with least-privilege claims, strict token validation (issuer/audience/nonce/expiry), key rotation and clock sync, continuous monitoring with anomaly detection, step-up auth for sensitive actions, and resilient IdP architecture (redundancy, rate-limiting, DDoS protection). With these safeguards, SSO typically improves security over isolated, per-app logins.

Is Single Sign-On Worth It?

Yes, single sign-on is generally worth it for most organizations because it simplifies authentication while improving security and productivity. Centralized login reduces password fatigue, weak credential reuse, and help-desk overhead from password resets. It also enables consistent enforcement of policies like multi-factor authentication and conditional access across all connected apps.

The upfront setup effort and dependency on a reliable identity provider are real trade-offs, but the long-term benefits. Stronger security posture, faster onboarding and offboarding, better compliance visibility, and smoother user experience usually outweigh the complexity and cost of implementation.