SAML vs OIDC: Which SSO Protocol to Use

Which single sign-on protocol should a new app use — the one every enterprise already runs, or the one built for the phone in your pocket? If you've integrated "Log in with your work account" and "Sign in with Google" and noticed they feel like different worlds, that's because they are: the first is almost certainly SAML, the second is OIDC. They chase the same goal from opposite ends of two decades, and picking the wrong one for your situation means fighting the protocol the whole way.

So let's line them up on the axes that actually decide it, then get to a verdict.

What they have in common

Both SAML and OpenID Connect solve federated single sign-on: instead of each app storing its own passwords, users authenticate once with a trusted identity provider (IdP), and each app — the service provider or relying party — trusts a signed statement from that IdP saying "this is who just logged in." One login, many apps, no password shared with each app. That shared shape is why they're rivals at all.

The differences are everything else: what that signed statement looks like, how it travels, and which world each was designed for.

The VHS-and-streaming picture

A useful way to hold the two apart: SAML is the VHS tape and OIDC is the streaming service. VHS was a heavyweight, physical, rock-solid standard that an entire industry standardized on — bulky, but it worked everywhere that had the right player, and enormous libraries of it still exist. Streaming came later, built for devices VHS never imagined, lightweight and network-native. Nobody rips out their whole VHS archive overnight, but nothing new gets shipped on tape.

SAML is that tape: from 2005, built for the browser-and-desktop enterprise, heavy but battle-proven, still running enormous amounts of corporate login. OIDC is the stream: from 2014, built for mobile apps, single-page apps, and APIs, lightweight and JSON-native. The analogy even predicts the migration pattern — new builds start on OIDC, but the SAML archive is far too large and too embedded to disappear.

Format: XML assertions vs a JSON token

The most concrete difference is what crosses the wire. SAML exchanges an assertion: a signed XML document, often several kilobytes, describing the user and how they authenticated. It rides between IdP and app over browser redirects and auto-submitting HTML form POSTs. XML brings XML's baggage — namespaces, canonicalization, and XML Digital Signatures, whose complexity has produced a long line of signature-wrapping vulnerabilities over the years.

OIDC exchanges a JSON Web Token. Its signature addition over plain OAuth is the ID token, a compact signed JWT carrying the user's identity as claims. Because it's a JWT, it's small enough to sit in an HTTP header, trivial to parse in any language, and you can paste one into the JWT Decoder to read its claims or check its lifetime with the JWT Expiration Checker. That compactness is precisely why OIDC works where SAML struggles — a native mobile app handling multi-kilobyte XML redirects is miserable; handling a JWT is routine.

Foundation: standalone vs built on OAuth

SAML is self-contained — it defines its own request/response flow, bindings, and metadata format, owing nothing to anything else. OIDC took the opposite route: it's a thin identity layer bolted onto OAuth 2.0, reusing OAuth's authorization-code flow, endpoints, and tokens, then adding the ID token, a userinfo endpoint, and a discovery document on top. The full story of that layering is in what is OpenID Connect.

This matters practically. Because OIDC sits on OAuth, the same flow that logs a user in also hands your app an access token for calling APIs on their behalf — identity and API authorization in one motion, with the access token traveling as a bearer credential you'd pull apart with the Bearer Token Parser. SAML only does authentication; API authorization is a separate problem it never tried to solve. If your app is fundamentally an API client, that integration is a real advantage for OIDC.

Security: same failure mode, different bugs

Neither protocol is inherently safer — both stand on signatures, and both fall the same way, by trusting a statement nobody fully validated. SAML's XML signatures are powerful but intricate, and signature-wrapping attacks (slipping an attacker-controlled assertion past a validator that checked the wrong element) have bitten many implementations. OIDC's JWTs have their own traps: the classic alg: none and algorithm-confusion attacks, and apps that read an ID token's claims without verifying its signature at all.

In both cases the rule is the same: verify the signature against the IdP's published keys, then confirm the issuer, the audience (that the assertion or token was minted for your app), and the expiry before trusting a single claim. Decoding is not verifying — a decoder shows you the contents, but your server still has to check them. And whichever protocol you run, that IdP-issued token is a different animal from a static API key, an app-level secret with no user identity attached that you'd mint with the API Key Generator; don't confuse a login assertion with a service credential.

The verdict

Choose by ecosystem, not by age. Reach for SAML when you're integrating with enterprise identity providers that already speak it — corporate SSO, B2B apps selling into large organizations, anywhere the buyer's IT department hands you SAML metadata and expects you to consume it. Reach for OIDC for essentially everything new: consumer login, mobile and single-page apps, microservices, and any system where the login also needs to authorize API calls. If you're building greenfield with no enterprise constraint, default to OIDC and don't look back.

And when both worlds show up — a modern product that also has to sell into SAML-only enterprises — you don't pick one. Run an IdP that speaks both, or bridge OIDC to a SAML backend, and let each client use the protocol built for it. The tape and the stream can share a library; they just play in different rooms.