Single sign-on and SAML basics

Single sign-on means a user authenticates once, with their organization's identity provider (Okta, Azure AD, Google Workspace), and every downstream application trusts that authentication instead of running its own login. Your app becomes a service provider (SP): it never sees a password, never runs a login form for these users, and instead accepts a signed assertion from the identity provider (IdP) saying "this is alice@company.com, and I've verified it." The value proposition for the enterprise buyer isn't convenience — it's centralized control: IT can disable one account in Okta and instantly lose that employee's access to every connected app at once.

SAML (Security Assertion Markup Language) predates modern token-based auth — it's XML-based, and its core artifact is a signed assertion, not a JWT:

The IdP signs this XML document with a private key; your app verifies it against the IdP's public certificate, exchanged once during setup as part of "metadata." The assertion typically arrives via the browser as a form POST (base64-encoded XML in a hidden field), not a redirect with a token in the URL.

OAuth2/OIDC and SAML solve overlapping problems but come from different eras and different assumptions. OIDC is JSON-based, built for the web and mobile apps, and is what you'd choose building integrations from scratch today. SAML is XML-based, older, and remains the protocol enterprise IT teams standardize on because their identity infrastructure (Active Directory Federation Services, Okta, PingFederate) was built around it — asking a Fortune 500 IT department to support OIDC instead of SAML because it's newer is rarely a winning argument. In practice, B2B SaaS products end up supporting both: OIDC for smaller customers and modern IdPs, SAML because a handful of large enterprise deals require it.

SP-initiated: a user goes to your app first, clicks "Log in with SSO," your app redirects them to their IdP, they authenticate there, and the IdP posts the assertion back to your app's Assertion Consumer Service (ACS) URL.

IdP-initiated: a user starts at their IdP's app dashboard (e.g., Okta's homepage) and clicks a tile for your app — the assertion arrives at your ACS URL with no preceding request from your side. This flow is more convenient but strictly less safe: because your app never initiated the request, it can't verify a RelayState/request ID it generated itself, which is exactly the kind of missing correlation that makes CSRF-style assertion replay attacks possible. Support it if enterprise customers demand it, but treat SP-initiated as the default.

Nearly every production SAML bug is one of the same handful of things: clock skew between IdP and SP causing valid assertions to be rejected as expired, a certificate rotation on the IdP side that nobody told you about, attribute mapping mismatches (the IdP sends department but your app expects dept), and — the most serious — failing to validate the XML signature against the exact expected certificate and issuer, which opens the door to signature-wrapping attacks where an attacker crafts a technically-valid-looking assertion for a different, attacker-controlled identity.