TechTarget.com/searchsecurity

https://www.techtarget.com/searchsecurity/definition/single-sign-on

What is Single Sign-On (SSO)? Definition, How It Works & Benefits

By Kinza Yasar

What is single sign-on (SSO)?

Single sign-on (SSO) is a session and user authentication service that lets users access multiple applications or systems with a single set of login credentials. By eliminating the need to remember and manage separate usernames and passwords for each service, SSO improves user convenience, reduces password fatigue and enhances security through centralized identity management.

How does single sign-on work?

Single sign-on is a federated identity management arrangement that operates through a centralized authentication system, known as an identity provider (IdP). The use of such a system is sometimes called identity federation.

When a user attempts to access an application, also known as the service provider (SP), it redirects them to the IdP for authentication. Upon successful login, the identity provider issues an authentication token, granting the user access to the application without needing to log in again.

In a basic web SSO service, an agent module on the application server retrieves the specific authentication credentials for an individual user from a dedicated SSO policy server, while authenticating the user against a user repository, such as a Lightweight Directory Access Protocol (LDAP) directory. The service authenticates the end user for all the applications the user has been given rights to and eliminates future password prompts for individual applications during the same session.

The following is a step-by-step description of how SSO works:

1. Access request. The user attempts to access a protected application or a website. The application or the SP checks if the user is already authenticated with the ldP.
2. Redirect to IdP. If the SP detects the user isn't authenticated, it redirects the browser to the IdP for authentication.
3. User authentication. The IdP prompts the user to enter credentials, such as their username and password for authentication.
4. Token generation. If the credentials are valid, the IdP authenticates the user and generates a security token. This token is typically stored in the user's browser session, often as a secure cookie.
5. Redirection back to the SP. The IdP redirects the user back to the original SP or the app, passing the authentication token along.
6. Token validation. The SP verifies the token's authenticity and integrity, ensuring it was issued by a trusted IdP.
7. Access granted. If the token is valid, the SP grants the user access to the requested application and the user remains authenticated across all connected applications during the session, reducing the need for multiple logins.
8. Seamless access to other applications. For any subsequent applications within the same SSO ecosystem, access is streamlined. When a user attempts to access a new application, the service provider checks with the IdP, detects a valid authentication token and grants access immediately.

Common SSO protocols

The SSO systems' efficiency and security are built upon different protocols that govern how identity information is exchanged. The most commonly used SSO protocols and frameworks include the following:

• Kerberos. This is a network authentication protocol designed to provide authentication for client-server applications using secret-key cryptography. In a Kerberos-based setup, once user credentials are provided, a ticket-granting ticket is issued. The TGT fetches service tickets for other applications the user wants to access, without asking the user to reenter credentials.
• Security Assertion Markup Language. SAML is an Extensible Markup Language standard that facilitates the exchange of user authentication and authorization data across secure domains. SAML-based SSO services involve communications among the user, an identity provider that maintains a user directory and a service provider.
• Open Authorization. OAuth is a framework that enables third-party services, such as Facebook, to use end user's account information without exposing the user's password. It acts as an intermediary on behalf of the end user by providing the service with an access token that authorizes specific account information to be shared. When a user attempts to access an application from the SP, the SP sends a request to the identity provider for authentication. The SP then verifies the authentication and logs the user in.
• OpenID Connect. OIDC is an identity layer built on top of OAuth 2.0, which is a more comprehensive and flexible successor to OAuth 1.0. It provides a standardized method for verifying the identity of end users and obtaining basic profile information through an authorization server. After a user authenticates with an OIDC-compliant IdP, which also functions as an OAuth 2.0 authorization server, the IdP issues an ID token, such as a JSON Web Token, in addition to an OAuth 2.0 access token. The ID Token contains verifiable information about the user's identity, letting the client application confirm who the user is.

Types of SSO configurations

SSO can be configured in various ways depending on the authentication method and system requirements. The main types of SSO configurations include the following:

Social SSO

This is a type of SSO that enables users to access a third-party website or application using their existing credentials from a major social media or consumer account, such as Google, Facebook, Apple, LinkedIn or X.

Many security professionals recommend end users refrain from using social SSO services because, once attackers gain control of a user's SSO credentials, they can access all other applications that use the same credentials.

Enterprise SSO

Enterprise single sign-on (eSSO) software and services are password managers with client and server components that log a user on to target applications by replaying user credentials. These credentials are almost always a username and a password.

Target applications don't need to be modified to work with the eSSO system.

Web-based or federated SSO

Web-based SSO uses identity federation protocols, such as SAML, OAuth and OIDC, to authenticate users across multiple websites and applications. This approach is commonly used in enterprise environments where employees need seamless access to various cloud services.

Cloud-based SSO

Cloud-based SSO lets users authenticate across cloud applications using providers, such as Microsoft Azure AD, Okta and Google Workspace. This SSO type is common in businesses adopting software-as-a-service applications that require streamlined access management.

Mobile SSO

This SSO type uses mobile authentication mechanisms, such as biometrics and device-based authentication, to grant access to multiple applications. Mobile SSO is often integrated with mobile identity providers, such as Apple ID or Google Sign-In.

Smart card-based SSO

Smart card-based SSO integrates physical smart cards with digital systems to enhance authentication security. It asks an end user to use a card holding the sign-in credentials for the first login. Once the card is used, the user doesn't need to reenter usernames or passwords. SSO smart cards store either certificates or passwords. This method is used in high-security environments, such as government agencies and healthcare institutions.

SSO security risks

Although single sign-on is a convenience for users, it also introduces risks to enterprise security. The following are the main security risks associated with SSO:

• Single point of failure. SSO consolidates access to multiple applications under one set of credentials. If these credentials are compromised, attackers can gain access to all linked systems or applications, potentially leading to a widespread data breach. For example, an attacker who gains control over a user's SSO credentials is granted access to every application the user has rights to, increasing the amount of potential damage. To avoid malicious access, SSO should be coupled with identity governance. Organizations can also use two-factor authentication or multifactor authentication (MFA) with SSO to improve security.
• Credential theft. Phishing campaigns targeting SSO credentials can be effective, as a single set of compromised credentials grants access to all connected applications. This makes the effects of such attacks severe. To combat phishing and credential theft, organizations should enforce strong password policies, adaptive MFA and phishing-resistant mechanisms.
• Lack of granular security controls. SSO centralizes authentication and often applies uniform security measures across all connected systems. This can be a drawback because it might not align with the varying sensitivity levels or compliance requirements of individual applications. For instance, highly sensitive applications handling critical data might require stricter authentication protocols or additional security layers that a standard SSO tool might not support by default. This uniformity can inadvertently lead to security gaps where an application's unique risk profile demands stronger protection than the centralized SSO provides.
• Session hijacking and token theft. Once a user successfully authenticates with the IdP, an authentication token is issued. If this token is intercepted by attackers through cross-site scripting, malicious browser extensions, or network sniffing, they can hijack the active session or impersonate the user without needing their credentials. To mitigate these risks, organizations should use encrypted tokens and enforce session timeouts and strong endpoint security measures.
• SSO misconfigurations. Misconfigurations in SSO settings, such as improper certificate validation, weak token signing or allocating overly broad permissions, can create significant vulnerabilities. Even subtle errors can lead to authentication bypasses or unauthorized data access, exposing sensitive data. To prevent these configuration issues, organizations should perform regular audits, conduct thorough access reviews and strictly adhere to the principle of least privilege.
• Supply chain risk. If a third-party SSO provider, such as Okta or Azure AD, experiences a breach or a significant vulnerability in its core service, it can potentially affect all its customers. This phenomenon is known as supply chain risk, and it shows how an organization's security posture is dependent on the security of its external vendors. Organizations must conduct due diligence when selecting an SSO provider, including reviewing their security certifications, incident response plans and historical security performance.
• Compliance and regulatory challenges. Some industries have stringent authentication and data privacy requirements that might limit SSO adoption. To prevent this from happening, organizations should align with regulatory frameworks such as the General Data Protection Regulation (GDPR), the Health Insurance Portability and Accountability Act (HIPAA) and the National Institute of Standards and Technology's security guidelines.

SSO implementation

Before implementing SSO, organizations must ask the right questions to ensure alignment with their goals and requirements. The following key questions should be considered:

• What are the primary goals for implementing SSO?
• Which applications and systems should be integrated?
• Which authentication protocols are required?
• Should user management be centralized or decentralized?
• How will the SSO system be secured?
• Does the SSO tool comply with the relevant regulations?
• What is the total cost of ownership?
• Should the organization build an in-house application or purchase one from a vendor?

Implementing SSO requires careful planning and integration across an organization's applications. The following is a structured deployment approach that organizations typically adhere to:

• Select an authentication protocol. To implement SSO, organizations must first choose the right authentication protocol based on system compatibility. SAML is ideal for enterprise environments, while OAuth 2.0 suits web and mobile applications, and OIDC works best for API-based authentication. This decision ensures secure and efficient authentication across integrated platforms.
• Set up an identity provider. To set up an IdP for SSO, organizations deploy platforms such as Okta, OneLogin or Ping Identity to manage authentication. The IdP integrates with directory services, such as Active Directory or LDAP, ensuring users can access multiple applications with a single set of credentials while maintaining centralized security controls.
• Configure service providers. To configure service providers for SSO, organizations establish trusted relationships between their applications and the IdP. This involves defining authentication workflows that use secure tokens or session management, ensuring seamless access across multiple systems without requiring users to log in separately for each application.
• Secure the implementation. To secure an SSO implementation, organizations enforce MFA to strengthen authentication and prevent unauthorized access. They establish role-based access controls to ensure users only have the necessary permissions and the logging and monitoring mechanisms track authentication events for security oversight. These measures help protect user identities and maintain system integrity.
• Test and deploy. Before deploying SSO, organizations conduct integration testing across applications to ensure seamless functionality. They provide users with clear onboarding instructions and continuously monitor the system for potential security vulnerabilities. This proactive approach helps maintain efficiency while safeguarding user access.

SSO advantages and disadvantages

Key benefits of SSO include the following:

• Enhanced user experience. With SSO, users need to remember and manage fewer passwords and usernames across applications. This streamlines the authentication process by eliminating repeated logins, thereby enhancing the overall user experience.
• Less credential theft. SSO reduces the number of successful phishing attacks. Instead of entering credentials across multiple application login pages -- each a potential phishing target -- users sign in once via a trusted IdP, minimizing opportunities for credential theft.
• Reduced IT overhead. With SSO, IT help desks see fewer complaints or tickets regarding passwords. SSO streamlines user provisioning and deprovisioning, resulting in cost savings and improved administrative efficiency.
• Decreased use of shadow IT. By providing easy access to approved applications, SSO encourages employees to use authorized tools rather than resorting to unapproved and potentially insecure applications.
• Improved auditing and compliance. Centralized logging of access attempts and user activity makes it easier for organizations to monitor security, detect anomalies and comply with regulatory requirements, such as GDPR and HIPAA.
• Scalability. SSO is designed to grow with an organization, enabling seamless integration of new applications and onboarding of additional users. This flexibility ensures that as business needs evolve, the authentication system can scale efficiently without requiring major infrastructure changes.

The disadvantages of SSO include the following:

• Access lockout. If apps that only allow SSO are unavailable, users become locked out. Since access to multiple services depends on a single authentication point, any disruption in the SSO service effectively cuts off user access across the entire connected ecosystem.
• Complex implementation. Implementing SSO can be complex, especially in organizations with a mix of legacy and modern applications, or those with unique integration requirements. Setting up SSO requires significant planning, technical expertise and ongoing maintenance.
• Vendor lock-in. When an organization becomes dependent on a specific vendor's SSO offering, it might face limitations in flexibility, especially if the provider's technology doesn't integrate well with certain applications or the company's evolving IT infrastructure. Additionally, vendor lock-in might restrict the organization's ability to adopt new technologies or customize security features, potentially hindering innovation and adaptability.
• Higher initial cost. The initial setup and ongoing costs of SSO can be a drawback, especially for smaller companies. Many vendors use tiered pricing, charging extra for essential features and per-user fees, which can lead to unexpected expenses. Additionally, the need for specialized technical expertise during implementation and maintenance adds to the cost, making SSO adoption financially challenging.

SSO vendors

Multiple vendors offer SSO products, services and features. According to Gartner reviews and Informa TechTarget's independent research, commonly used SSO vendors include the following:

• Rippling. This tool lets users sign into cloud applications from multiple devices and offers deep integration with its broader HR and IT management platform. Unlike standalone SSO vendors, Rippling uses employee data from its human resource information system to unify identity and access management (IAM). This approach enables more automated and intelligent user provisioning, access control and enhanced security.
• Avatier Identity Anywhere. This is a SSO option for Docker container-based platforms. It uses accepted protocols, such as SAML, OAuth and OIDC, to facilitate secure and seamless access to both cloud and on-premises applications. Organizations use this platform to enhance security, improve user experience and reduce administrative overhead by consolidating identity management into a unified system.
• OneLogin by One Identity. This cloud-based IAM platform supports SSO, offering smart MFA and risk-based authentication along with comprehensive application integrations. OneLogin is ideal for mid-sized to large organizations seeking a balance between usability and scalability.
• Okta. This enterprise tool with SSO functionality has more than 1,400 prebuilt integrations, adaptive MFA and user lifecycle management. Okta is ideal for enterprises requiring scalable and secure access management across diverse applications.
• Microsoft Azure AD. This is a cloud-based IAM service that integrates with Microsoft products and other third-party applications. Its key features include conditional access policies, self-service password reset and comprehensive reporting and monitoring.
• AuthO. Also part of the Okta umbrella, this tool is a developer-friendly identity management platform, offering customizable authentication and authorization services. This platform is geared toward developers due to its extensive application programming interfaces (APIs), software development kits and documentation. It's also suitable for startups and companies needing deeper customization options.
• Ping Identity. This is an enterprise-grade IAM tool focusing on secure access and identity governance. Its key features include federated identity management, API security and comprehensive access policies. Ping Identity is useful for large organizations with complex security and compliance requirements.

Identity and access management is evolving, requiring organizations to fundamentally shift their security strategies. Learn how to build an effective IAM framework tailored to today's dynamic technology landscape.