What Is Single Sign-On (SSO)?

People use a lot of applications to do their jobs. Requiring a separate username and password for every application creates more credentials to remember and more opportunities for weak or reused passwords.

SSO centralizes authentication, veering away from each connected application handling the user's credentials independently.SSO authentication happens through a trusted identity provider (IdP), making access easier for users while giving organizations a central place to apply authentication controls.

Some of the more common benefits of SSO include:

• Fewer passwords to manage. Users authenticate through one central service instead of maintaining separate credentials for every connected application.
• Less password reuse. Reducing the number of passwords users need can limit reliance on repeated or weak credentials.
• Centralized authentication controls. Organizations can apply policies, such as multi-factor authentication (MFA), through the identity provider.
• Simpler access administration. IT and security teams have a central point for managing authentication and responding when access needs to change.
• Fewer repeated login prompts. Once authenticated, users can move among connected services without signing in separately each time.

Centralization also makes the SSO account and identity provider important security controls. If an attacker compromises a user's SSO credentials or authenticated session, they may be able to reach multiple connected applications. Organizations therefore commonly pair SSO withMFA and other identity security controls.

How single sign-on works

SSO relies on a trust relationship between an identity provider and the applications a user wants to access. Rather than asking the user to authenticate independently, a connected application trusts authentication information supplied by the IdP.

A typical SSO flow works like this:

1. The user requests an application. They open a connected application or service.
2. The application directs authentication to the IdP. If the user doesn’t already have an authenticated session, the application sends them to the organization's identity provider.
3. The IdP authenticates the user. The user proves their identity using the authentication methods required by the organization, which may include a password and MFA.
4. The IdP provides authentication information. After successful authentication, the IdP issues an assertion or token that communicates the user's authenticated identity.
5. The application validates the information. The service provider accepts and validates the assertion or token according to the established trust relationship.
6. The user gets access. The application creates a session for the user. Other applications connected to the same SSO environment can recognize the authenticated identity without requiring another independent login.

The exact exchange differs depending on the protocol and implementation, but the central idea remains the same: Connected applications rely on a trusted identity service rather than each app independently authenticating the user's credentials.

Key components and protocols of SSO

An SSO environment combines identity systems, applications, and standards that allow authentication information to move securely between them.

Identity provider and service provider

The IdP authenticates the user and supplies trusted identity information. The service provider (SP) is the application or service the user wants to access.

The IdP and SP establish a trust relationship so the application can accept authentication information from the IdP.

Authentication assertions, tokens, and sessions

After authentication, the IdP communicates information that allows a connected application to recognize the user's identity. Depending on the protocol, this can take the form of an assertion or token.

Once the application validates that information, it typically establishes a session. That session lets the user continue using the application without authenticating for every request.

SAML, OIDC, and OAuth

Several standards can be involved in SSO implementations:

• Security Assertion Markup Language (SAML) exchanges authentication and authorization information between an identity provider and service provider, and is widely associated with enterprise SSO.
• OpenID Connect (OIDC) is an identity layer built on OAuth 2.0. It allows applications to verify a user's identity and receive basic identity information.
• OAuth 2.0 is primarily an authorization framework that allows an application to obtain limited access to resources without requiring a user to give that application their password. OAuth can support identity architectures, but isn’t itself the same thing as SSO or an authentication protocol.

Keeping these concepts separate matters because authentication answers who a user is, while authorization determines what that user can access or do.

Single sign-on examples and use cases

Workforce applications

An employee signs into their organization's identity provider at the start of the workday. They can then access connected email, collaboration, HR, and business applications without entering a separate password for each service.

Cloud and SaaS applications

Organizations often connect cloud applications to a central IdP. Instead of every SaaS provider maintaining an independent authentication process for the workforce, the organization can use SSO to centralize authentication.

Customer-facing services

SSO can also connect related customer services: A user may authenticate once and then move among connected applications or websites without being prompted to sign in again.

In each case, SSO reduces repeated authentication, but that doesn’t necessarily mean every user receives the same access. Applications and access controls still determine what an authenticated identity is authorized to do.

How SSO fits into identity security

SSO is one part of a broader identity security strategy. It helps centralize authentication, but organizations still need controls for verifying identities, assigning access, governing accounts, and monitoring how identities are used. Several adjacent disciplines address different parts of that problem:

• MFA strengthens authentication. SSO centralizes the login experience, while MFA requires additional evidence that the person attempting to sign in is the legitimate user.
• Access control determines permissions. Approaches such as role-based access control (RBAC) determine what authenticated users can access based on assigned roles.
• Identity governance manages access over time. Identity governance and administration (IGA) helps organizations manage identity lifecycles, access policies, provisioning, and reviews.
• Privileged access requires additional protection. Privileged access management (PAM) focuses on accounts and credentials with elevated permissions.

SSO answers the authentication problem of letting one verified identity access connected services without repeatedly signing in, but doesn’t replace authorization, governance, privileged access controls, or ongoing monitoring.