What Is Single Sign-On (SSO)

Kerberos is a network authentication protocol commonly used in on-premises enterprise environments, particularly with Microsoft Active Directory in Windows domains.

Instead of transmitting passwords, Kerberos uses encrypted tickets to authenticate users. When a user logs in, the system issues a Ticket-Granting Ticket (TGT), which is used to request access to additional services within the network.

Web SSO refers to Single Sign-On implemented in web browsers. It relies on browser-based mechanisms such as HTTP redirects and cookies to exchange authentication data between systems.

Unlike desktop or native-application SSO, all authentication occurs through the browser using standard web protocols. Common examples include "Sign in with Google" or "Sign in with Microsoft."

Web SSO is typically implemented using SAML or OpenID Connect (OIDC). Because it depends on browser sessions and cookies, it introduces specific security considerations, including cookie protection and defenses against cross-site attacks.

SSO is important because it improves both security and usability. It reduces password-related risks, simplifies access management, and allows organizations to enforce consistent security controls across applications.

In traditional environments, users must manage multiple credentials, leading to password fatigue, frequent login interruptions, and reduced productivity.

SSO reduces this friction, allowing users to spend less time managing credentials and more time on their work—particularly in environments where organizations deploy large numbers of applications

SSO also improves organizational efficiency by simplifying how access is managed. Administrators can control user identities, permissions, and authentication policies from a central system rather than configuring each application separately.

User provisioning and deprovisioning can be automated, often using standards such as System for Cross-domain Identity Management (SCIM) protocol. When a user joins or leaves an organization, access to connected applications can be granted or revoked centrally.

SSO can reduce operational overhead by lowering the volume of password reset requests, easing the burden on IT teams while improving access control across systems.

SSO changes how authentication risk is managed by concentrating access through a single identity provider. While this reduces password sprawl and improves visibility, it also increases the impact of a compromise, making the identity layer a critical security control.

A common concern is the “one key for all doors” problem: if an attacker gains control of the identity provider or a valid authentication session, they may gain access to every connected application. This makes the identity layer a prime target for attacks such as credential stuffing, phishing, token theft, and session hijacking.

Multi-factor authentication (MFA) strengthens authentication by adding additional verification factors. When combined with controls such as short token lifetimes and anomaly detection, SSO can reduce overall risk; without them, it can amplify the impact of credential compromise.

The identity provider (IdP) becomes a critical dependency in SSO environments. If the IdP is compromised, misconfigured, or unavailable, access to all connected applications can be affected.

Attackers often target identity providers because of this expanded impact: a successful compromise can grant access to multiple systems at once. In July 2023, Microsoft disclosed that a threat actor (Storm-0558) obtained a signing key and used it to forge authentication tokens, gaining access to Exchange Online accounts across multiple organizations. A subsequent U.S. Cyber Safety Review Board investigation found the intrusion was preventable and highlighted weaknesses in centralized identity infrastructure.

Availability is also a risk. If the identity provider goes down, users may be unable to access critical applications, even if those applications remain operational.

To mitigate these risks, organizations should implement redundancy and failover at the identity layer, use geographically distributed infrastructure, and define “break-glass” access accounts to maintain limited access during outages.

Multi-factor authentication (MFA) is one of the most effective controls for securing SSO environments. Enforcing MFA at the identity provider significantly reduces the risk of credential-based attacks such as password reuse and credential stuffing. For protection against modern phishing, phishing-resistant methods such as FIDO2 security keys or passkeys provide stronger defense than codes or push notifications. NIST SP 800-63B-4 requires phishing-resistant authenticators for federated authentication at Assurance Level 2 (AAL2) or above.

SSO and MFA are designed to work together. MFA strengthens authentication at the identity provider, allowing organizations to enforce consistent security policies across all connected applications.

In high-security environments, SSO without MFA is generally considered insufficient. Additional authentication factors are essential to protect access to sensitive systems and data.

Authentication tokens and sessions are common targets in SSO environments. Attackers may attempt to steal them through techniques such as cross-site scripting (XSS), man-in-the-middle attacks, session cookie theft, and cross-site request forgery (CSRF).

To reduce these risks, organizations should enforce short token lifetimes, require HTTPS for authentication traffic, and validate tokens on the service provider side.

In browser-based SSO, secure session management is critical. Applications should use cookie protections such as HttpOnly (preventing JavaScript access), Secure (requiring HTTPS), and SameSite (limiting cross-site requests) to reduce the risk of session theft. Additional controls, such as binding sessions to devices or monitoring for anomalous behavior, can further limit session abuse.

SSO is implemented across enterprise, cloud, and consumer environments. While the core concept is consistent, implementations vary depending on infrastructure, application types, and security requirements.

In enterprise environments, SSO is commonly implemented within on-premise networks using directory services and domain-based authentication. Kerberos-based Windows Integrated Authentication allows users to access internal systems using their domain account, which serves as their primary credential.

Active Directory Federation Services (ADFS) is often used to extend this model beyond the internal network, enabling on-premise identities to be trusted by external or web-based applications. Many organizations are transitioning toward cloud-based identity providers as part of modernization efforts.

Enterprise SSO is increasingly deployed in hybrid environments, where on-premise directories integrate with cloud identity providers. In these setups, user accounts are synchronized and authentication policies are enforced consistently across both internal systems and cloud services.

In cloud and SaaS environments, SSO is provided by a cloud-based identity provider that integrates with applications using protocols such as SAML or OpenID Connect. These providers offer pre-built connectors that simplify application integration and often support user provisioning through standards such as SCIM.

An SSO portal, or dashboard, presents the applications a user is authorized to access in a single interface. From this portal, users can launch applications while administrators manage access and authentication policies across services.

Consumer-facing SSO is commonly implemented through social login options such as "Sign in with Google" or "Sign in with Apple." These allow users to authenticate using an existing identity instead of creating new credentials.

At the protocol level, consumer SSO typically relies on OpenID Connect (OIDC), built on OAuth 2.0, to authenticate users and share identity data with applications.

Unlike enterprise SSO, consumer SSO emphasizes user consent, privacy, and data minimization. Identity data is scoped and approved by the user, and authentication is tied to individual consumer accounts. The trade-off is that the security of the user’s identity provider account becomes a critical dependency—if it is compromised, all connected services may be exposed.

Implementing SSO involves selecting an identity provider, integrating applications and directories, and validating security and availability before deployment.

1. Select an identity provider (IdP). Choose an IdP that integrates with your user directories and supports required protocols.
2. Integrate user directories. Connect the IdP to systems such as LDAP, Active Directory, or cloud directories to centralize identity data.
3. Map applications for SSO integration. Configure trust relationships between the IdP and each application.
4. Choose authentication protocols. Use SAML for enterprise web applications and OpenID Connect (OIDC) for modern web, mobile, and API-based systems.
5. Test authentication flows and failover. Validate login flows, MFA enforcement, and recovery scenarios.
6. Roll out in phases. Start with a limited user group, then expand gradually to reduce operational risk.

Implementation effort increases with application count, legacy dependencies, and hybrid or multi-cloud environments.