What is SAML SSO?

Where SAML came from

OASIS published SAML 1.0 in 2002 to standardize how separate web applications could share authentication. SAML 2.0 followed in 2005 and is the version essentially every modern deployment uses. The protocol was designed for a world of enterprise web applications behind a corporate firewall, federated to a single identity provider — exactly the use case Microsoft Active Directory Federation Services, IBM Tivoli, and later Okta built businesses around.

The SP-IdP dance

Two actors and one user. The Service Provider (SP) is the application the user is trying to reach — your SaaS, a vendor portal, a corporate intranet. The Identity Provider (IdP) is the system that authenticates users — Okta, Entra ID, Google Workspace, Ping, ADFS. When the user tries to access the SP, the SP redirects the browser to the IdP with an authentication request. The IdP authenticates the user (password, MFA, hardware key) and responds with a SAML assertion — a signed XML document that says "this is alice@company.com, here are her group memberships, this assertion is valid for the next hour." The SP verifies the signature, trusts the assertion, and lets the user in.

What SAML actually buys an enterprise

Three things. Single sign-on — users log in once per day, not once per app. Centralized lifecycle — when an employee leaves, deprovisioning their identity at the IdP cuts off access to every connected SP simultaneously, instead of hunting through forty SaaS admin panels. Centralized policy — MFA requirements, conditional access, device posture checks all live at the IdP and apply consistently across every connected app. Without SAML, every SaaS gets its own password and its own offboarding ritual, and "Sarah left two months ago" becomes a phrase that ruins someone's morning.

SAML vs OIDC

OpenID Connect (OIDC), built on top of OAuth 2, is the modern alternative. OIDC uses JSON and JWTs instead of XML, plays much better with mobile and single-page-app frontends, and is dramatically simpler to implement correctly. For consumer products and modern SaaS, OIDC has essentially won. SAML remains entrenched in enterprise IT because the existing IdP installations, the procurement workflows, and the muscle memory of corporate security teams are all built around it — and large enterprises specifically request SAML in their procurement RFPs.

At QUANT LAB

Every SaaS platform we build for enterprise customers ships SAML SSO as part of the enterprise tier, even when the founders would rather support OIDC alone — because procurement teams ask for SAML and the deals stop without it. We typically use a managed provider (WorkOS, Stytch, Auth0 Enterprise, Clerk) on the implementation side rather than rolling raw XML signature verification, because SAML's edge cases (encrypted assertions, signed responses vs signed assertions, IdP-initiated flows) are a sharp surface to land on.

For internal apps and admin consoles, we federate to whatever IdP the client already runs — typically Google Workspace or Microsoft Entra. The wire protocol is sometimes SAML, sometimes OIDC, but the user experience is identical and the access is centrally governed. Read our IAM glossary entry for the broader picture, or book a call if you have an enterprise deal blocked on SSO.