Single Sign-On (SSO) Explained Simply

Single sign-on (SSO) is an authentication method that lets you use one set of login credentials to access multiple applications or websites. Instead of entering a username and password for each service, you log in once to a central identity provider, and that provider automatically authenticates you to all other connected services. This article explains what SSO is, how it works, the technology behind it, common use cases, and its benefits and drawbacks.

Formula

The calculator estimates the time saved by using SSO compared to traditional per-app logins. The formula is:

Time saved per year (hours) = ((N × P – N × 2) / 3600) × 250

Where:

• N = number of applications (apps)
• P = average time to log in to each app (seconds)
• 2 = assumed time per SSO login (seconds)
• 3600 = seconds per hour
• 250 = assumed working days per year

The second output, resets avoided, estimates the number of password resets you avoid per year, assuming each app has a 50% chance of needing a reset annually.

Worked Example

Using the default values: 10 applications, 30 seconds per login, and 20 minutes per reset.

Time saved per login = 30 – 2 = 28 seconds. For 10 apps, that’s 280 seconds per day. Over 250 working days: 280 × 250 = 70,000 seconds. Divide by 3600 to get hours: 70,000 / 3600 ≈ 19.44 hours per year.

The calculator shows 19.4 hours. Resets avoided: 10 × 0.5 = 5 resets per year.

What Is Single Sign-On?

Single sign-on is an authentication process that allows a user to access multiple independent applications with a single set of credentials. The term “single sign-on” is standard in the IT industry, used in official documentation, academic papers, and product specifications. It is not slang or informal; it’s a technical term with a clear definition.

The concept originated in the 1990s with the proliferation of enterprise software. Early implementations used Kerberos, a network authentication protocol developed at MIT in the 1980s. Kerberos allowed users to authenticate once and then obtain tickets for various services without re-entering passwords. Later, web-based SSO standards like SAML (Security Assertion Markup Language) and OAuth emerged to handle browser-based authentication.

In a sentence: “Our company uses single sign-on so employees only need to remember one password for all their work applications.”

How SSO Works

The core of SSO is a central identity provider (IdP) that authenticates the user once and then shares that authentication with other services. The most common protocols are:

• SAML (Security Assertion Markup Language): An XML-based standard that exchanges authentication and authorization data between an identity provider and a service provider.
• OAuth 2.0: An authorization framework that allows third-party apps to access user data without exposing passwords. Often used with OpenID Connect for authentication.
• OpenID Connect (OIDC): An authentication layer built on top of OAuth 2.0 that verifies the user’s identity and obtains basic profile information.

The typical flow is:

1. User tries to access an application (service provider).
2. The app redirects the user to the identity provider’s login page.
3. User enters credentials (or uses a session cookie if already logged in).
4. The IdP authenticates the user and sends a token or assertion back to the app.
5. The app validates the token and grants access.
6. For subsequent apps, the user is already authenticated, so the process is seamless.

This is why you can click “Sign in with Google” on a new website and be logged in immediately if you already have a Google session.

Why Use SSO?

The primary benefits of SSO are convenience and security. Users no longer need to remember dozens of passwords, which reduces password fatigue and the tendency to reuse weak passwords. IT departments can enforce stronger password policies and enable multi-factor authentication (MFA) centrally, improving overall security.

For organizations, SSO simplifies user provisioning and deprovisioning. When an employee leaves, disabling their access in the identity provider automatically blocks access to all connected apps. This reduces the risk of orphaned accounts.

However, SSO has a single point of failure: if the identity provider goes down, users cannot access any connected service. Also, if an attacker compromises the SSO credentials, they gain access to all apps. This is why MFA is strongly recommended with SSO.

Common SSO Protocols and Standards

There are several standards that enable SSO, each with its own strengths and use cases.

• SAML: Mature and widely used in enterprise environments, especially for web applications. It uses XML and is often used for B2B integrations.
• OAuth 2.0: Primarily an authorization protocol, but it can be used for SSO when combined with OpenID Connect. It is the basis for most social logins.
• OpenID Connect: Built on OAuth 2.0, it provides user authentication and is popular for modern web and mobile apps due to its simplicity and JSON-based tokens.
• Kerberos: Used in Windows Active Directory environments. It relies on a trusted third-party ticket-granting service.
• LDAP: Not a full SSO solution, but a directory protocol that can be used to store and verify credentials. Often used in conjunction with SSO systems.

Choosing the right protocol depends on your existing infrastructure, the types of apps you use, and your security requirements.

Potential Drawbacks and Misconceptions

One common misconception is that SSO eliminates the need for passwords entirely. In reality, SSO still requires at least one password (or other authentication factor) to log in. It just centralizes the process.

Another issue is the “all eggs in one basket” problem. If a user’s SSO credentials are stolen, the attacker has access to every connected service. This risk can be mitigated with multi-factor authentication, but it’s a trade-off between convenience and security.

SSO can also create a dependency on a third-party identity provider. If that provider experiences an outage or goes out of business, you could lose access to all your apps. It’s wise to have a backup plan, such as local fallback authentication.

Finally, not all applications support standard SSO protocols. Some older or specialized apps may require custom integration or may not support SSO at all, leaving gaps in the system.

Frequently Asked Questions

Is SSO the same as a password manager?

No. A password manager stores your passwords and auto-fills them, but you still log in to each site individually. SSO authenticates you once and passes that authentication to other apps, so you don’t enter a password for each one.

Can SSO work without a password?

Yes, SSO can use other factors like biometrics (fingerprint, face recognition), smart cards, or hardware tokens. Many modern SSO systems support passwordless authentication, but password-based SSO is still common.

Is SSO safe for banking or financial apps?

SSO can be safe if implemented with strong security measures like MFA and strict session controls. However, financial institutions often prefer separate authentication for high-risk transactions due to the single point of failure risk.

What is the difference between SSO and federated identity?

Federated identity is a broader concept that includes SSO. It allows users to access multiple systems across different organizations or domains using a shared set of credentials. SSO is typically within one organization or a group of trusted partners.

How do I set up SSO for my small business?

You can use a cloud-based identity provider like Okta, Azure AD, or Google Workspace. These services offer pre-built integrations for many popular apps. You’ll need to configure the identity provider and then connect each application using SAML or OIDC. Most providers offer step-by-step guides.

Does SSO slow down login?

No, SSO usually speeds up login because you only authenticate once. Subsequent app accesses are automatic. The initial login might take a few seconds longer due to the redirect, but overall time is reduced.

Related

• Skype Versions Supported on OS X
• Voltage Nest Hello: Compatibility and Power Explained
• Powerline Networking vs Ham Radio Interference

in t | Number of applications | apps | 10 | 1 | 100
in p | Password time per login | seconds | 30 | 5 | 600
in r | Password reset time per year | minutes | 20 | 0 | 240
out total_time | Time saved per year (SSO) | hours | ((t * p * 1 - t * 2) / 3600) * 250 | 1
out resets_saved | Password resets avoided | resets | t * 0.5 | 0