What is Single Sign-On (SSO)?

What is Single Sign-On (SSO)?

Single Sign-On (SSO) is an authentication scheme where a user logs in once with a single set of credentials and gains access to multiple connected applications without having to log in again. Behind the scenes, an identity provider (IdP) — Okta, Microsoft Entra ID, Google Workspace, Auth0 — verifies the user, and a service provider (SP) — Slack, Salesforce, GitHub, your internal app — accepts the IdP's verification token instead of asking for a password.

SSO is dominant in the enterprise: a typical employee touches 10-30 SaaS apps in a day, and asking them to log in to each separately is a productivity disaster + a password-reuse security disaster. With SSO, the user signs in to the IdP once at the start of the workday; every connected app accepts that authentication for the rest of the session.

How SSO actually works

The big-picture flow is the same across protocols, even though the implementation details differ:

1. User clicks "Sign in" on the SP (the app they want to use).
2. SP redirects user to the IdP with a request: "please authenticate this user for me".
3. IdP authenticates the user — checks credentials, may also enforce MFA, conditional access policies ("only on managed devices"), session limits.
4. IdP issues a token — a cryptographically signed assertion that says "this user is authenticated, and here's their identity (email, name, group memberships)".
5. IdP redirects user back to SP with the token.
6. SP validates the token's signature using the IdP's public key, then trusts the user is who the IdP says they are. SP creates a local session.

The user usually experiences this as a single browser redirect — they click "Sign in with Okta", briefly see the IdP's page (or not, if already logged in), and land back in the app already authenticated. Total elapsed time: 1-2 seconds.

The 3 main SSO protocols (SAML, OIDC, OAuth)

SAML 2.0

The granddaddy of enterprise SSO, ratified in 2005. SAML uses XML-formatted assertions exchanged between IdP and SP, signed with X.509 certificates. It's verbose, complex to debug (multi-line base64-encoded XML in URL parameters or POST bodies), but rock-solid and ubiquitous in enterprise. If a SaaS app says "SSO supported", they almost certainly mean SAML 2.0. Slack, Salesforce, AWS, Workday — all SAML.

OpenID Connect (OIDC)

The modern successor, built on top of OAuth 2.0 and JSON Web Tokens (JWTs). OIDC is what powers "Sign in with Google", "Sign in with Apple", "Sign in with Microsoft". JSON-based, simpler to implement, well-supported in modern auth libraries. Newer SaaS products start with OIDC and add SAML later for enterprise customers who insist.

OAuth 2.0 (technically not SSO)

OAuth is an authorization framework — "can this app access this user's data?" — not strictly an authentication framework. But it's commonly conflated with SSO because the same redirect-based flow is used. "Sign in with GitHub" uses OAuth: the app gets a token to call GitHub's API as the user, and infers identity from that. OIDC adds standardized identity claims on top of OAuth, which is what makes it actual SSO.

Service Provider Initiated vs Identity Provider Initiated

SSO logins start in one of two places:

• SP-initiated: User goes to https://app.example.com first, hits Sign In, gets redirected to the IdP, comes back. This is the vast majority of real-world flows.
• IdP-initiated: User starts in the IdP's app launcher (e.g. Okta dashboard), clicks the SP's tile. The IdP generates an unsolicited assertion and POSTs it to the SP, which logs the user in directly. Convenient but more complex from a security standpoint — an SP must accept assertions it didn't request.

Most SAML SaaS apps support both. OIDC is essentially SP-initiated only by design.

Why SSO improves security (counter-intuitively)

It feels like "one login for everything" should make the blast radius of a stolen credential larger. In practice, the opposite is true:

• Centralized MFA enforcement. Enforcing MFA across 30 individual apps is impossible — some apps don't support it, others have weak implementations. With SSO, you enforce strong MFA at the IdP, and every connected app benefits.
• One place to revoke access. When an employee leaves, you disable their IdP account once and they immediately lose access to every connected app. Without SSO, you'd be deleting accounts in 30 places (and missing some).
• No more password reuse. Users with separate passwords for 30 apps reuse them. SSO eliminates the reuse problem at the source — the user only has one password to manage.
• Audit trail in one place. Login activity, MFA challenges, failed attempts — all visible in the IdP's logs. Without SSO, audit data is fragmented across 30 vendors.

Common SSO gotchas

• Just-in-time (JIT) provisioning. Many SAML SaaS apps create user records on the first SSO login. If your IdP includes group memberships in the assertion, the SP can also assign roles automatically. Without JIT, an admin manually creates each user before they can log in — fine for small teams, painful at scale.
• Group claim mapping. The IdP usually sends group memberships in the assertion. The SP must map those groups to local roles. Misconfigured group mappings are the #1 source of "why am I not an admin?" tickets after an SSO migration.
• Clock skew. SAML assertions have NotBefore and NotOnOrAfter validity timestamps. If the IdP's clock and SP's clock differ by more than the configured skew (usually 60-300 seconds), authentication fails. NTP-sync everything.
• Certificate rotation. SAML signs assertions with X.509 certs that expire (typically every 1-3 years). Forgetting to rotate certs before they expire takes down SSO at 03:00 on a Tuesday. Calendar reminders are mandatory.
• SP-initiated logout vs single logout. Logging out of the SP doesn't necessarily log out of the IdP or other connected SPs. Single Logout (SLO) is messy in practice and many vendors don't fully implement it. In the enterprise, users often just close the browser.
• Session lifetime mismatches. If the IdP gives a 12-hour session but the SP enforces 1-hour sessions, users get re-prompted constantly even though they're "already logged in". Align lifetimes carefully.

SSO vs Federated Identity vs OAuth — what's what?

These three terms get tangled. Quick disambiguation:

• SSO (Single Sign-On): User experience pattern — one login, many apps. Says nothing about how it's implemented.
• Federated identity: The technical capability for an IdP and SP to trust each other across organizational boundaries. SSO usually requires federated identity; federated identity may also enable other things (e.g. user attribute sharing).
• OAuth 2.0: An authorization protocol (delegate access to data). Used as a building block for OIDC, but on its own it doesn't establish identity.
• OIDC: An authentication layer on top of OAuth. Adds an ID token with standardized identity claims.

FAQ: Single Sign-On (SSO)

What's the difference between SSO and password managers?

A password manager stores separate credentials for each app and auto-fills them — the user still has 30 different passwords, just typed automatically. SSO replaces the 30 passwords with one IdP login: every app trusts the IdP's verification, no per-app password exists. SSO is more secure (no password reuse possible) but requires every app to support an SSO protocol.

Can small teams use SSO without paying enterprise prices?

Yes — Google Workspace and Microsoft 365 include OIDC SSO for many SaaS apps at no extra cost. Auth0 has a free tier for under 7,000 users. Many open-source IdPs (Keycloak, Authentik) are free to self-host. The cost barriers to SSO have dropped dramatically since 2020.

Is SAML still relevant or should I just use OIDC?

For new integrations, OIDC if both sides support it — simpler, JSON-based, easier to debug. For enterprise SaaS, SAML is still required because most IdPs and most enterprise SaaS catalogs lead with SAML. Plan for both: implement OIDC for self-service signups and SAML for enterprise contracts.

What is the SSO Tax?

The "SSO tax" is the practice of SaaS vendors charging significantly more for SSO support — sometimes pushing customers to enterprise tiers solely to get SSO. There's an industry pushback (sso.tax tracks vendors who do this). Some vendors have responded by including SSO in lower tiers; many haven't.

What is SCIM and how does it relate to SSO?

SCIM (System for Cross-domain Identity Management) automates user provisioning and de-provisioning between IdP and SPs. SSO handles authentication; SCIM handles "create this user when they're added to the IdP, delete them when they're removed". Together, SSO + SCIM is the gold standard for managed enterprise SaaS.

What happens to SSO if the IdP goes down?

Users can't log in to anything. This is why IdP availability is critical. Most IdPs publish 99.99% SLAs; some enterprises run a backup IdP for failover. For super-critical apps, keep at least one local admin account that bypasses SSO for emergency access.

How LoadFocus integrates with SSO

LoadFocus supports SAML 2.0 and OIDC SSO on its Enterprise plans. Connect your IdP (Okta, Microsoft Entra ID, Google Workspace, Auth0) once; provision team members through your IdP's group membership; revoke access centrally when someone leaves. Configure SSO from your account settings — instructions per IdP are in the docs.