What Is SSO?

SSO, or single sign-on, is an authentication approach that lets a user sign in once with a central identity system and then access multiple applications without entering separate credentials for each one. SSO reduces password sprawl, improves the user experience, and gives IT and security teams a central place to enforce authentication policies across cloud and on-prem systems.

How SSO works

At a high level, SSO shifts the login process away from each individual application and toward a central authority, usually called an identity provider or IdP.

Instead of every app validating usernames and passwords on its own, the app trusts the identity provider to do that job.

The basic flow

A typical SSO workflow looks like this:

1. A user tries to open an application.
2. The application checks whether the user is already authenticated.
3. If not, the user is redirected to the identity provider.
4. The identity provider verifies the user, often with MFA.
5. The identity provider sends a trusted assertion or token back to the application.
6. The application grants access based on that trusted identity.

To the user, this usually feels like “log in once, then open what you need.”

The main components

Most SSO deployments involve these parts:

• Identity provider (IdP): The central system that authenticates the user
• Service provider (SP): The application the user wants to access
• Authentication protocol: The standard used to exchange identity information

Common protocols include:

• SAML
• OpenID Connect (OIDC)
• OAuth 2.0 for delegated access scenarios

The exact protocol depends on the app and architecture, but the core idea is the same: the application relies on a central identity system instead of a separate password stored locally.

Why organizations use SSO

SSO usually improves both usability and control.

For users, it means:

• Fewer passwords to remember
• Less time lost to repeated sign-ins
• Fewer password reset requests

For administrators and security teams, it means:

• Centralized authentication policies
• Easier MFA enforcement
• Faster onboarding and offboarding
• Better visibility into access events
• More consistent access management across apps

If an employee leaves the company, disabling the central identity account can cut off access to many connected services at once.

For organizations trying to reduce unsafe password reuse, a password manager like 1Password can still be useful alongside SSO because not every service will always be integrated into the SSO platform.

What SSO does not do by itself

SSO does not automatically mean stronger security. It can reduce risky password habits, but it also concentrates risk around the identity layer.

If an attacker compromises the user’s primary identity account and MFA is weak or absent, that access may unlock multiple systems. That is why mature SSO deployments are usually paired with:

• Strong MFA or phishing-resistant authentication
• Conditional access policies
• Device trust checks
• Least privilege
• Session monitoring
• Rapid account disablement processes

SSO simplifies access. It does not remove the need for identity security.

If you are comparing stronger authentication methods, see what is fido2.

Common SSO protocols

Different applications support different federation and authentication standards. The most common are:

SAML

Security Assertion Markup Language is widely used for enterprise SSO, especially with older SaaS platforms and business applications. It passes identity assertions between the identity provider and the service provider.

OpenID Connect (OIDC)

OIDC is a modern identity layer built on top of OAuth 2.0. It is commonly used for web and mobile applications and is often easier to work with in newer app architectures.

OAuth 2.0

OAuth 2.0 is mainly an authorization framework rather than pure authentication, but it is often part of the same conversation because many modern sign-in flows rely on it under the hood.

When you’ll encounter SSO

SSO appears in almost every modern identity and SaaS discussion.

In cloud application access

Organizations commonly use SSO for business apps such as email, collaboration tools, HR platforms, CRM systems, ticketing systems, and developer services. If a company says users access many apps through one portal, that is typically SSO.

During IAM or identity projects

When teams roll out identity and access management improvements, SSO is often one of the first capabilities deployed. It provides a central control point for authentication and user access workflows.

For broader identity context, read what is iam.

In MFA rollout conversations

SSO and MFA are closely linked. Many organizations use SSO as the place where MFA is enforced, rather than configuring MFA separately in every application.

In merger, contractor, and offboarding planning

SSO matters whenever access changes quickly. Centralizing authentication makes it easier to grant access to the right users and remove it promptly when roles change or contracts end.

In zero trust discussions

SSO often comes up as part of a broader zero trust or identity-first security model. It helps centralize who is accessing what, but it is only one piece of the broader access-control design.

Operational benefits and tradeoffs

SSO usually reduces support burden, especially for password resets and access confusion. It also helps standardize logging and policy enforcement.

But there are tradeoffs:

• A central identity outage can affect many apps
• Misconfigured trust relationships can create access issues
• Overly broad SSO access can make privilege sprawl worse
• Identity compromise becomes more consequential

In other words, SSO is powerful because it centralizes access. That same centralization means the identity layer must be well protected and well governed.

Bottom line

SSO is a way to let users authenticate once and access multiple applications through a central identity system. Done well, it improves user experience, reduces password sprawl, and gives security teams a stronger control point for authentication and access policies. Done poorly, it can centralize risk just as efficiently as it centralizes convenience.