Single sign-on is based on a digital trust relationship between a group of related, trusted applications, web sites and services, called service providers, and an SSO solution, called an identity provider. The SSO solution is often part of a larger IAM (identity and access management) solution. 

In general, SSO authentication works as follows:

1. A user logs into one of the trusted applications - or into a central portal connecting all the trusted applications (such as an employee portal or college student web site) - using SSO log in credentials.
2. When the user is successfully authenticated, the SSO solution generates a session authentication token containing specific information about the user's identity - a username, email address, etc. This token is stored with the user's web browser, or on the SSO or IAM server.
3. When the user attempts to access another of the trusted applications, the application checks with the SSO or IAM server to determine if 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 log in credentials.

The process can vary depending on several factors. For example, a user who has been idle for a specified period may need to log in when they attempt to access another app. Or, if an authenticated user attempts an app or service that deals with particularly sensitive information, the user may be prompted for an additional authentication factor, such as a code sent to the user's mobile phone or email (see 'Adaptive SSO' below).

Obviously, SSO saves users time and trouble. Take corporate users, for example: Instead of logging into multiple applications multiple times per day, with SSO they are often able be able to log into the corporate intranet or extranet just once for all-day access to every application they need.

But by dramatically reducing the number of passwords users need to remember and the number of user accounts administrators need to manage, SSO strengthens an organizations security posture. Specifically, SSO can

• Replace password fatigue with one strong password. Users with lots of passwords to manage often lapse into 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 can often reduce scores of short weak passwords to a single long, complex, strong password that's easier for users to remember - and much more difficult for hackers to break.
• Help prevent unsafe password storage habits. SSO can reduce or eliminate the need for password managers, passwords stored in spreadsheets, passwords written on sticky notes and other memory aids - all of which make passwords easier for the wrong people to steal or stumble upon.
• Reduce help desk calls - by a lot. According to industry analyst Gartner, 20 to 50 percent of IT help desk calls are related to forgotten passwords or password resets. Most SSO solutions make it easy for users to rest passwords themselves, with help desk assistance.
• Give hackers a smaller target. According to IBM's Cost of a Data Breach 2021 report, compromised credentials were the most frequent initial attack vector for a data breach, accounting for 20% of all data breaches - and breaches that began with compromised credentials cost their victims $4.31 million on average. Fewer passwords mean fewer potential attack vectors.
• Simplify management, provisioning and decommissioning of user accounts. With SSO, administrators have more centralized control over authentication requirements and access permissions. And when a user leaves the organization, administrators can remove permissions and decommission the user account in fewer steps.
• Help simplify regulatory compliance. SSO meets or makes it easier to meet regulatory requirements around protection of personal identity information (PII) and data access control, as well as specific requirements in some regulations - such as HIPAA - around session time-outs. 

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.

Requiring users to create long and complex passwords - and carefully encrypting and protecting them wherever they're stored - goes a long way toward preventing this worst-case scenario. But most security experts recommend implementing SSO with multi-factor authentication, or MFA. MFA requires users to provide at least one authentication factor in addition to a password - e.g., 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.

The SSO scheme describe above - a single log-in and set of user credentials providing session access to multiple related applications - is sometimes called simple or pure SSO. Other types of SSO - or authentication methods similar to SSO - include:

• Adaptive SSO initially requires a username and password at log-in, but subsequently requires additional authentication factors or a new log-in when additional risks emerge - such as when a user logs in from a new device or attempts to access particularly sensitive data or functionality.
• Federated SSO - more correctly called 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 service providers outside the organization. For example, FIM might enable a logged-in employees to access third-party web applications, such as Slack or WebEx, without an additional log-in, or with a simple username-only log-in.
• Social log-in lets users use the same credentials they use to access popular social media sites to access third-party applications. Social log-in simplifies life for users. For third-party application providers, it can discourage undesirable behaviors (e.g., false logins, shopping cart abandonment) and provide valuable information for improving their apps.

SSO may be implemented using any of several authentication protocols and services.

SAML/SAML 2.0

SAML (Security Assertion Markup Language) 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.

OAuth/OAuth 2.0

OAuth/OAuth 2.0 (Open Authorization) is an open standard protocol that exchanges authorization data between applications without exposing the user's password. OAuth enables using 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.

OpenID Connect (OIDC)

Another open standard protocol, OICD uses REST APIs and JSON authentication tokens to enable a web site 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 SaaS (software as a service) and cloud applications, mobile apps, and Internet of Things (IoT) devices.

LDAP

LDAP (lightweight directory access protocol) defines a directory for storing and updating user credentials, and a process for authenticating users against the 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 the directory.

ADFS

ADFS (Active Directory Federation Services) 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. 

'Zero trust' takes a 'never trust, always verify' approach to security: Any user, application, or device - whether outside the network, or already authenticated and inside the network - must verify its identity before accessing the next network resource it wants to access.

As networks become more distributed, spanning on-premises infrastructure and multiple private and public clouds, a zero-trust approach is essential for preventing threats that penetrate the network from gaining more access, and doing maximum damage.

SSO - and particularly SSO as part of an IAM solution - is viewed widely as a foundational technology for implementing a zero-trust approach. The fundamental challenge of zero-trust is to create a security architecture that can clamp down on attackers who penetrate the network - without hampering the ability of authorized end users to move freely about the network and get their work or business done. When combined with multi-factor authentication, access and permission controls, network micro-segmentation and other techniques and best practices, SSO can achieve help organizations achieve this balance.