Blog
3 min read

What Is SSO (Single Sign-On)? How It Works and When Your App Needs It

Single sign-on lets people log in once with one company account — Google Workspace, Microsoft Entra, Okta — and get into many apps without separate passwords. How SSO works, SAML vs OpenID Connect, why business customers demand it, and how to add it to your own app.

Single sign-on (SSO) means logging in once and getting into many apps. At most companies, you sign in to your work account in the morning — Google Workspace, Microsoft, Okta — and then Slack, your CRM, your HR tool and dozens of others just let you in, no extra passwords.

How it works

There are three parties:

  • The user — an employee.
  • The identity provider (IdP) — the company's central login system, such as Microsoft Entra ID, Okta or Google Workspace. It knows who works there and enforces things like two-factor authentication.
  • The service provider (SP) — any app the employee uses, including yours.

The flow:

  1. The user opens your app and clicks "Log in with SSO" (or types their work email).
  2. Your app redirects them to their company's IdP.
  3. If they're already signed in there, the IdP immediately sends them back with a signed message saying "this is alice@company.com".
  4. Your app checks the signature and logs them in.

Your app never sees the user's password. The company stays in control of who can log in.

SAML vs OpenID Connect

SSO is built on one of two standards:

SAML OpenID Connect (OIDC)
Age 2000s 2014
Format XML JSON / JWTs
Common in Enterprise, older systems Modern apps, mobile
Built on Its own spec OAuth 2.0

Enterprise customers will often ask "do you support SAML?" Supporting both covers almost everyone.

Why businesses demand it

  • Security: one place to enforce strong passwords and 2FA.
  • Offboarding: disabling the central account blocks new sign-ins, but existing app sessions can remain active. Timely removal also needs session expiry or revocation, and often SCIM deprovisioning. OIDC back-channel logout can notify apps to end their sessions. (OpenID Connect logout specification)
  • Fewer passwords means fewer reused, weak or phished ones.
  • Compliance: audits often require central access control.

That's why "SSO" sits on the pricing page of so many SaaS products, often on the business tier. (How to Price Your SaaS)

SSO vs "Sign in with Google"

They look similar but serve different people. "Sign in with Google" is social login for individuals with any Google account. SSO is for organisations: the company decides which employees can log in, and enforces its policies. Under the hood, both can use OpenID Connect. (Sign in With Google Explained)

Big customers often ask for SCIM next. It lets their IdP automatically create, update and deactivate user accounts in your app, so IT doesn't have to do it by hand.

Adding SSO to your app

Don't build SAML parsing yourself — it's notoriously easy to get wrong in security-critical ways. Use an auth provider or library that supports enterprise SSO and handles the per-customer configuration. (Clerk vs Auth0 vs Supabase Auth)

The summary

  • SSO: log in once with a company account, get into many apps.
  • The identity provider vouches for the user; your app trusts its signed message.
  • SAML and OpenID Connect are the two standards. Business customers will ask for it.

EasySpawn gives your app a proper server-side backend for auth, so SSO callbacks, signing keys and sessions are handled where they belong — with Claude Code there to wire them up. See how it works or join the waitlist.

Related: Authentication vs Authorization · Role-Based Access Control · Passkeys Explained · Add Login to an AI-Built App

Keep reading