Single sign-on (SSO) is an authentication scheme that lets users log in once using a single set of credentials and access multiple applications during the same session.
Single sign-on simplifies user authentication, improves the user experience and when properly implemented and improves security. It’s often used to manage authentication and secure access to company intranets or extranets, student portals, public cloud services and other environments.
In these settings, users need to move between different applications to get their work done. It’s also used increasingly in customer-facing websites and apps, such as banking and e-commerce sites to combine applications from third-party providers into seamless, uninterrupted user experiences.
Join security leaders who rely on the Think Newsletter for curated news on AI, cybersecurity, data and automation. Learn fast from expert tutorials and explainers—delivered directly to your inbox twice weekly. See the IBM Privacy Statement.
Single sign-on is based on a digital trust relationship between service providers—applications, websites, services and an identity provider (IdP) or SSO solution. The SSO solution is often part of a larger identity and access management (IAM) solution.
In general, SSO authentication works as follows:
When a user logs in to one of the service providers or into a central portal (such as a company intranet or college student portal) with SSO login credentials.
When the user is successfully authenticated, the SSO solution generates a session authentication token containing specific information about the user’s identity—a username or an email address. This token is stored with the user’s web browser or in the SSO system.
When the user attempts to access another trusted service provider, the application checks with the SSO system to determine whether the user is already authenticated for the session. If so, the SSO solution validates the user by signing the authentication token with a digital certificate and the user is granted access to the application. If not, the user is prompted to reenter login credentials.
The SSO process described earlier—a single login and set of user credentials providing session access to multiple related applications—is sometimes called simple SSO or pure SSO. Other types of SSO include:
Adaptive SSO requires an initial set of login credentials, but it prompts for another authentication factors or a new login when other risks emerge. These risks can include situations such as a user logging in from a new device or attempting to access sensitive data or functionality.
Federated identity management (FIM) is a superset of SSO. While SSO is based on a digital trust relationship among applications within a single organization’s domain, FIM extends that relationship to trusted third parties, vendors and other providers outside the organization. For example, FIM might enable a logged-in employee to access third-party web applications (for example, Slack or Webex) without other login or with a simple username-only login.
Social login enables end users to authenticate with applications with the same credentials they use to authenticate with social media sites. For third-party application providers, social login can discourage undesirable behaviors (for example, false logins, shopping cart abandonment) and provide valuable information for improving their apps.
SSO can be implemented through any of several authentication protocols and services.
Security Assertion Markup Language (SAML) is the longest-standing open standard protocol for exchanging encrypted authentication and authorization data between an identity provider and multiple service providers. Because it provides greater control over security than other protocols, SAML is typically used to implement SSO within and between enterprise or government application domains.
Open Authorization (OAuth) is an open standard protocol that exchanges authorization data between applications without exposing the user’s password. OAuth enables the use of a single log‑in to streamline interactions between applications that would typically require separate logins to each. For example, OAuth makes it possible for LinkedIn to search your email contacts for potential new network members.
Another open standard protocol, OICD uses REST APIs and JSON authentication tokens to enable a website or application to grant users access by authenticating them through another service provider.
Layered on top of OAuth, OICD is used primarily to implement social logins to third-party applications, shopping carts and more. A lighter-weight implementation, OAuth/OIDC is often to SAML for implementing SSO across Software-as-a-Service (SaaS) and cloud applications, mobile apps and Internet of Things (IoT) devices.
A lightweight directory access protocol (LDAP) defines a directory for storing and updating user credentials. It also defines a process for authenticating users against that directory. Introduced in 1993, LDAP is still the authentication directory solution of choice for many organizations implementing SSO because LDAP lets them provide granular control over access to the directory.
Active Directory Federation Services (ADFS) runs on Microsoft Windows Server to enable federated identity management—including single sign-on—with on-premises and off-premises applications and services. ADFS uses Active Directory Domain Services (ADDS) as an identity provider.
SSO saves users time and trouble. For example, instead of logging in to multiple applications several times per day, corporate end users with SSO can log in to the corporate intranet once. That single login provides all‑day access to every application they need.
But by reducing significantly the number of passwords users need to remember and the number of user accounts administrators need to manage, SSO can provide several other benefits.
Users with lots of passwords to manage often lapse into the bad and risky habit of using the same short, weak passwords—or slight variations thereof—for every application. A hacker who cracks one of these passwords can easily gain access to multiple applications. SSO lets users consolidate multiple short weak passwords into one single, long, strong password that’s easier for users to remember and much more difficult for hackers to break.
According to the IBM X-Force® Threat Intelligence Index 2025 for the second straight year, hijacked valid account credentials were the most common initial cyberattack access vector. This year, that vector tied for first place with the exploitation of public‑facing applications.
SSO can reduce or eliminate the need for password managers, passwords stored in spreadsheets, passwords written on sticky notes and other memory aids. These practices create targets for hackers or make passwords easier for the wrong people to steal or stumble upon.
According to industry analyst Gartner, 20–50% of IT help desk calls are related to forgotten passwords or password resets. Most SSO solutions make it easy for users to reset passwords themselves, with help desk assistance.
An IBM Institute for Business Value study found that 52% of executives say that complexity is the biggest impediment to security operations. SSO gives administrators simpler, more centralized control over account provisioning and access permissions. When a user leaves the organization, administrators can remove permissions and decommission the user account in fewer steps.
SSO can make it easier to meet regulatory requirements around the protection of personally identifiable information (PII) and data access control. It can also help organizations comply with specific requirements in certain regulations—such as HIPAA—related to session timeouts.
The chief risk of SSO is that if a user’s credentials are compromised, they can grant an attacker access to all or most of the applications and resources on the network. But requiring users to create long and complex passwords—and carefully encrypting and protecting those passwords wherever they’re stored—goes a long way toward preventing this worst-case scenario.
In addition, most security experts recommend two-factor authentication (2FA) or multi-factor authentication (MFA) as part of any SSO implementation. 2FA and MFA require users to provide at least one authentication factor in addition to a password—for example, a code sent to a mobile phone, a fingerprint or an ID card. Because these additional credentials are ones that hackers can’t easily steal or spoof, MFA can dramatically reduce risks related to compromised credentials in SSO.
