What is Single Sign-On (SSO)?

What is Single Sign-On (SSO)?

Single sign-on (SSO) lets a person log in once and use several connected applications without logging in again. An identity provider (IdP), such as Okta, Microsoft Entra ID, Google Workspace or Auth0, verifies the user. Each application, called a service provider (SP), trusts the IdP's signed confirmation instead of asking for its own password. SSO is common in companies because it replaces many separate passwords with one managed login.

How SSO works

The flow is similar across protocols:

1. The user clicks "Sign in" on the application.
2. The application redirects the browser to the IdP with an authentication request.
3. The IdP authenticates the user: password, MFA, device or location policies.
4. The IdP issues a signed token (an assertion or ID token) that states who the user is, often with email, name and group memberships.
5. The browser returns to the application with the token.
6. The application checks the signature with the IdP's public key and opens its own session.

To the user this is a couple of redirects. If they already have an IdP session, they may not see a login page at all.

The main SSO protocols: SAML, OIDC and OAuth

SAML 2.0

An XML-based standard that OASIS announced in March 2005. Assertions are signed with X.509 certificates. It is verbose and harder to debug than newer options, but widely supported in enterprise software. See what is SAML for details.

OpenID Connect (OIDC)

A thin identity layer on top of OAuth 2.0. The application receives an ID Token, a signed JSON Web Token, that carries identity claims. It is JSON-based and easier to implement, which is why many newer products start with it.

OAuth 2.0

OAuth is an authorization framework: it answers "may this app access this data?", not "who is this user?". It is often confused with SSO because the redirects look alike. OIDC adds the standardized identity layer that turns the flow into real authentication. The access tokens OAuth issues are usually sent as bearer tokens.

SP-initiated vs IdP-initiated login

• SP-initiated: the user opens the application first, is redirected to the IdP, and comes back. This is the most common flow.
• IdP-initiated: the user starts from the IdP's app launcher and clicks the application's tile; the IdP sends an assertion the application never requested. It is convenient, but the application must accept an unsolicited assertion, so it needs extra care.

Why SSO can improve security

• Central MFA. Enforce strong authentication once at the IdP instead of in every app.
• One place to revoke access. Disabling a leaver's IdP account cuts access to every connected app at once.
• Less password reuse. One managed login replaces many separate passwords.
• One audit trail. Sign-ins and failed attempts show up in the IdP's logs.

The trade-off is concentration: the IdP becomes a critical dependency and an attractive target, so protect it with MFA and keep an emergency admin path outside SSO. SSO also does not decide what a user may do; that is authorization, handled by roles in the application (see role-based access control and identity and access management).

Common SSO mistakes

• Clock skew. SAML assertions have NotBefore and NotOnOrAfter timestamps; if IdP and SP clocks drift beyond the allowed skew, logins fail. Sync both with NTP.
• Expired signing certificates. SAML certificates expire. Track the date and rotate before it passes.
• Wrong group mapping. If IdP groups are not mapped to application roles, users land with the wrong permissions after a migration.
• No provisioning plan. Without just-in-time provisioning or SCIM, an admin must create each user by hand, and leavers keep stale accounts.
• Assuming single logout works. Logging out of one app often does not end the IdP session or other apps' sessions.
• Mismatched session lifetimes. A long IdP session next to a short app session means users are re-prompted constantly.

SSO vs federated identity vs OAuth

• SSO is the user experience: one login, many apps. It does not say how it is built.
• Federated identity is the trust arrangement that lets an IdP and an SP in different organizations accept each other's identities.
• OAuth 2.0 delegates access to data; on its own it does not establish who the user is.
• OIDC adds an ID token with identity claims on top of OAuth.

FAQ: Single Sign-On (SSO)

What is the difference between SSO and a password manager?

A password manager stores a separate credential for each app and fills it in. SSO removes the per-app password: the app trusts the IdP's verification instead. SSO needs support from every app; a password manager works with any login form.

Should I use SAML or OIDC?

For a new integration, OIDC is usually simpler to build and debug. Many enterprise customers and identity providers still ask for SAML, so products that sell to larger organizations often support both.

What is the SSO tax?

It is the practice of vendors charging much more for a plan that includes SSO. The site sso.tax tracks which vendors do this.

What is SCIM and how does it relate to SSO?

SCIM (System for Cross-domain Identity Management) automates creating, updating and removing user accounts between the IdP and applications. SSO handles sign-in; SCIM handles the account lifecycle.

What happens if the identity provider is down?

Users cannot sign in to apps that depend on it, unless they already hold a valid session. Keep at least one local emergency admin account that does not use SSO for critical apps.

Load testing an app behind SSO

LoadFocus itself does not offer SAML or OIDC single sign-on: you sign in with email and password or with Google, and invite teammates with full or read-only access. SSO matters for the app you test. A real SSO login bounces through the identity provider's browser pages, which a load test should not hammer. A common pattern is to obtain a token once from a test client, for example with the OAuth client credentials flow on a test tenant, and send it as an Authorization header. See OAuth 2.0 load testing and testing OAuth-secured apps with JMeter; the tests themselves run from LoadFocus load testing, including JMeter scripts.