Single Sign-On (SSO)

How SSO Works

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Single Sign-On solves the N-password problem in corporate environments. Without SSO, an employee uses separate credentials for Slack, Jira, Salesforce, GitHub, and 37 other SaaS tools — an IT and security nightmare. With SSO, the company runs a central Identity Provider (Okta, Azure AD, Google Workspace). The employee logs in once with their corporate credentials, and MFA is enforced at that single point. The IdP issues a signed identity token — a digital wristband. Service providers (Slack, Jira) verify the IdP's signature and grant access without needing separate credentials. Offboarding is instant: disable the Okta account and the employee loses access to every connected application simultaneously.

1 / 10.5×1×2×3×Playground

SSO login-once flow — user authenticates with IdP, gets token to access SP

In a corporate environment, employees access dozens of apps — Slack, Salesforce, Jira, Workday — each with its own login. Managing separate credentials for every service creates password fatigue: users reuse weak passwords, forget credentials, or store them insecurely. For IT, it's a security nightmare. When someone leaves the company, every account must be tracked down and disabled manually, and one missed account is a live credential waiting to be abused. Single Sign-On (SSO) solves this by letting a user authenticate once and gain access to all connected applications without logging in again.

The Key Players in SSO

SSO involves two parties on either side of every access request. The Service Provider (SP) is the application the user wants to reach — Slack, Zoom, GitHub. The Identity Provider (IdP) is the central authority that verifies who the user is — Okta, Auth0, Microsoft Entra, Google Workspace.

When a user attempts to access the SP, the SP redirects them to the IdP with a message that says it cannot verify their identity. The user authenticates with the IdP, which issues a signed token or assertion and sends the user back to the SP. The SP inspects that token, trusts the IdP's cryptographic signature, and grants access — no second login required.

SAML and OIDC

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

SSO uses one of two protocols to prove identity. SAML (Security Assertion Markup Language) is the legacy enterprise standard — the IdP generates a cryptographically signed XML document (SAML Assertion) containing the user's attributes. It's deeply embedded in large enterprises and highly secure, but the XML format is verbose and the setup requires manually exchanging certificates between systems. OIDC (OpenID Connect) is the modern standard — it's built on top of OAuth2 and uses compact JWTs instead of XML. If you've ever clicked "Log in with Google" or "Sign in with Apple", that's OIDC. OIDC is JSON-native, browser and mobile-friendly, and much simpler to implement. New SaaS products typically support OIDC first, adding SAML only when enterprise customers require it.

1 / 10.5×1×2×3×Playground

SAML vs OIDC protocol comparison — XML assertion vs JWT id_token

For the SP and IdP to exchange identity information, they need a shared protocol. The two dominant standards are SAML and OIDC.

SAML (Security Assertion Markup Language)

SAML is the established enterprise standard. When a user authenticates, the IdP generates an XML document called a SAML Assertion containing the user's email, group memberships, and a cryptographic signature proving the IdP issued it. SAML is highly secure and deeply embedded in large legacy enterprises with complex security configurations. The downside is that XML is bulky and difficult for modern web and mobile clients to parse, and initial setup requires manually exchanging public certificates between the SP and IdP, a process that is notoriously error-prone.

OIDC (OpenID Connect)

OIDC is the modern standard, built as an identity layer on top of OAuth2. Where OAuth2 handles authorization (what a user is allowed to do), OIDC handles authentication (who the user is). Instead of XML, OIDC issues a JSON Web Token (JWT) called an id_token that encodes the user's profile. JSON is native to web and mobile environments, making OIDC far simpler to implement than SAML — it's the protocol behind every "Log in with Google" or "Log in with Apple" button on the web. Its main friction point is adoption in enterprises with deep SAML infrastructure that have little incentive to migrate.

Why SSO Matters for Enterprise

If you are building a B2B SaaS product, SSO support is often what separates a deal from a lost sale with large customers — and it justifies a significant pricing premium.

Security and offboarding is the clearest value. When an employee leaves, IT disables their IdP account once, and that single action revokes access to every connected application instantly. Without SSO, IT must chase down accounts across dozens of systems — and every one they miss is an open door.

Password fatigue is reduced because users maintain a single strong credential at the IdP rather than juggling dozens of weak, reused passwords across every service.

Policy enforcement becomes centralized. Multi-factor authentication, session timeouts, and conditional access rules are configured once at the IdP and apply uniformly to every SP downstream. There is no need to replicate security policy in each individual application.

Summary

Single Sign-On (SSO) lets a user authenticate once with a central system and access multiple independent applications without re-entering credentials. The Identity Provider (IdP) — such as Okta or Microsoft Entra — owns authentication and issues signed tokens. The Service Provider (SP) — such as Slack or GitHub — consumes those tokens to grant access. SAML remains the dominant standard in legacy enterprises, using signed XML assertions. OIDC is the modern alternative built on OAuth2, using JWTs and favored by web and mobile applications. For enterprise customers, SSO is foundational: it centralizes access control, enforces security policy uniformly, and makes employee offboarding reliable.