OAuth vs SAML: What's the Difference? (2026)

The Deal That Wanted a Word I Didn’t Know

Somewhere around 2024 I was chasing my first real B2B customer — a mid-sized company that actually replied to my emails, actually got on a call, actually seemed like they’d pay. I was floating. Then their IT person sent over a security questionnaire, and buried in it was one line: “Does your product support SAML-based SSO with our Okta?”

I remember reading it three times. I had built “Sign in with Google.” I thought that was SSO. I’d wired it up in an afternoon, felt clever, moved on. So I typed back something confident and vague — and then spent the next two nights realizing “Sign in with Google” and “SAML SSO with our Okta” are not the same thing, are not even the same shape of thing, and that the gap between them was exactly the gap between a hobby project and something a company with an IT department would buy.

That’s what this post is. The two words get thrown in the same sentence — OAuth and SAML — because both do the thing where you log in with an identity you already have somewhere else. But they come from different decades, speak different languages, and solve subtly different problems. Let me untangle them the way I wish someone had untangled them for me before I embarrassed myself on that call.

---

What OAuth Actually Is (and Isn’t)

Here’s the single most important thing, and almost every “OAuth login” tutorial gets it wrong: OAuth is not a login protocol. It’s an authorization protocol.

OAuth 2.0 was designed to answer one question: “Can this app do this thing on my behalf, without me handing it my password?” Think of the classic case — an app wants to read your Google Calendar. In the bad old days you’d give the app your Google password and pray. OAuth killed that. Instead, Google shows you a consent screen (“SaaSTurf wants to view your calendar”), you approve, and the app gets a scoped access token — a valet key that opens the calendar and nothing else. It never sees your password. You can revoke it later. That’s OAuth: delegated access to resources.

Notice what’s missing: OAuth never actually tells the app who you are. It hands over a token that says “the bearer of this may read a calendar,” and nothing reliable about your identity. People bolted login onto it anyway — grab the token, call the “get my profile” endpoint, call that proof of identity — and it mostly worked, which is exactly why it was dangerous. That hack is where a lot of early “Sign in with X” security bugs came from.

So OAuth is brilliant at what it’s for: API access, third-party integrations, machine-to-machine tokens, letting your app pull data from someone else’s service. It is not, by itself, a way to know who just logged in.

---

OIDC: The Login Layer OAuth Was Missing

Because everyone kept abusing OAuth for login, the industry did the sensible thing and standardized the abuse. That standard is OpenID Connect (OIDC), and it’s the piece that actually matters for you as a founder.

OIDC is a thin identity layer built on top of OAuth 2.0. It reuses all the OAuth machinery but adds one crucial new thing: an ID token, which is a JWT — a compact, signed, Base64-encoded chunk of JSON that says, in a verifiable way, “this is who the user is.” Email, a user ID, when they authenticated, who vouched for them. You can paste a JWT into a decoder and read it; it’s human-legible JSON, a few hundred bytes.

This is what’s really happening behind “Sign in with Google,” “Sign in with Apple,” “Continue with Microsoft.” It’s OAuth doing the handshake and OIDC handing your app a trustworthy answer to who is this person. When a tutorial says “add OAuth login,” what they almost always mean is OIDC. So the honest framing:

• OAuth 2.0 = authorization. What are you allowed to access?
• OIDC = authentication, built on OAuth. Who are you?

Both are modern, both speak REST and JSON over HTTPS, both work natively on mobile apps, SPAs, CLIs — anything, not just browsers. The recommended flow in 2026 for basically every client type is Authorization Code with PKCE, and you don’t need to memorize that; your auth provider does it for you. (AWS’s own provider, Cognito, does both OAuth and SAML — I broke down its MAU-based pricing and why founders often skip it.) Just know: this whole family is the modern, developer-friendly, consumer-facing side of the identity world.

---

What SAML Is (the XML Grandpa Enterprises Trust)

Now cross the street into the other neighborhood. SAML — Security Assertion Markup Language — is older, from the mid-2000s, governed by OASIS. And unlike OAuth, SAML does authentication and authorization in one shot. It was built for a very specific world: a corporation with hundreds of employees and dozens of internal apps, where IT wants every employee to log in once through a central system and get into everything.

That central system is called the Identity Provider (IdP) — in practice, Okta or Microsoft Entra ID (the thing formerly called Azure Active Directory). Your app is the Service Provider (SP). When an employee at BigCorp hits your login page, SAML bounces them to Okta, Okta checks they’re a real, current employee (and enforces whatever MFA and policies BigCorp mandates), and then sends your app a signed assertion: an XML document that says “yes, this is jane@bigcorp.com, she’s legit, here’s her department.” Your app trusts Okta’s signature and lets her in.

The critical detail is the format: it’s XML, signed with XML-DSig, and the whole dance routes through the browser as a courier passing documents back and forth. A SAML assertion is a chunky 2–8 KB signed XML blob. If you’ve ever debugged an XML canonicalization mismatch at 2 AM — a stray whitespace breaking a signature — you understand why SAML has a reputation for being brittle and unpleasant to hand-roll. It’s rock-solid in production, and it is not fun to implement.

But here’s why it refuses to die: corporate IT departments trust it, mandate it, and have run their entire access model on it for twenty years. When an enterprise buyer says “SSO,” nine times out of ten they mean SAML into their Okta or Entra tenant. That questionnaire that ambushed me? That’s what it was asking.

---

Authn vs Authz: The Distinction That Untangles Everything

If you remember one framing from this whole post, make it this pair of ugly abbreviations, because they’re the real fault line:

• Authentication (authn) = who are you? Proving identity.
• Authorization (authz) = what are you allowed to do? Granting access.

Map the standards onto it and the fog lifts:

• OAuth 2.0 → authz only. Access to resources. (This is the one everyone miscategorizes.)
• OIDC → authn, riding on OAuth’s authz plumbing. This is your consumer login.
• SAML → both authn and authz in a single signed assertion. This is enterprise SSO.

Same underlying human need — “let me in using an identity I already have” — solved three ways by three specs from two different eras. Every confusing comparison table you’ve ever squinted at collapses into that.

	OAuth 2.0	OIDC	SAML
Really does	Authorization	Authentication	Authn + Authz
Era	2012	2014	mid-2000s
Format	Tokens (JSON)	JWT (JSON)	XML assertions
Feels like	API access	Consumer login	Corporate SSO
Non-browser (mobile/CLI)	Native	Native	Painful
Who asks for it	Developers	Developers	Enterprise IT

---

Which One Do Enterprise Buyers Actually Demand?

This is the part that decides what you build, so let me be blunt about the split I learned the hard way.

For consumers and small teams, nobody demands SAML. They want “Sign in with Google” or a magic link or email-and-password. That’s OIDC (plus regular auth), and it’s what you ship on day one. Building SAML for a product whose users are individuals is pure over-engineering — my favorite mistake, the one I’ve made in a dozen flavors.

For enterprise deals, SAML is frequently non-negotiable. The moment your buyer is a company with an IT or security team, “does it do SSO with our Okta/Entra?” shows up in the procurement checklist, and a “no” can kill the deal outright. It’s not because SAML is technically superior — OIDC would do the job fine, and plenty of modern IdPs support both — it’s because that’s what corporate IT standardized on and they won’t change for a startup. Some enterprises now accept OIDC-based SSO too, but SAML is still the safe, expected answer — and you’ll often get asked for SCIM (automatic provisioning) alongside it, so employees sync in and out with the customer’s directory.

So the real answer to “which one” isn’t either/or. It’s: OAuth/OIDC to get any users at all, SAML to close the ones who pay the most.

---

The Broken Engineer Take: You Add SAML the Day a Deal Needs It

Here’s where I save you my two bad nights. You do not implement OAuth, OIDC, or SAML from scratch. Not OIDC’s token validation, and definitely not SAML’s XML signature canonicalization — that path is a swamp with zero business upside, the same trap I walked into building Clickly’s database. (I made this exact argument about the auth mechanism in password vs passkey: you flip auth features on, you don’t build them.)

Your auth provider gives you the whole family behind one integration. As of 2026:

• WorkOS is purpose-built for this. Its AuthKit layer is free up to 1 million monthly active users (social login, email/password, MFA, the works), and then you pay per enterprise SSO connection — roughly $125/month per connection, dropping with volume. The pricing is deliberately shaped so your auth is free until you land an enterprise customer, and then that one customer’s contract easily covers the connection fee.
• Clerk has the smoothest drop-in components. Its Pro plan (about $25/mo) includes MFA and your first enterprise SSO connection, with each additional SAML/OIDC connection around $75/month, falling at volume.
• Auth0 has the most mature, most configurable API — reach for it if you want deep control and don’t mind wiring more yourself.

All three give you both worlds: modern OIDC social login for everyone, and SAML into Okta or Entra for the enterprise accounts — without you touching a line of XML. The founder move is boring and correct: ship OIDC login now, and the day a real deal’s questionnaire asks for SAML, you flip on a connection, charge that customer an “enterprise” tier that more than covers it, and get back to building. (Wire this into the rest of your stack sanely — auth is one chapter of the full SaaS deployment guide.)

That’s the whole trick: treat SAML as a sales unlock, not an engineering project.

---

The Bottom Line

OAuth is a valet key — it grants access to your stuff without revealing who you are. OIDC is the badge clipped to that key that says who you are, in clean JSON, and it’s what powers every “Sign in with Google” button you’ve ever clicked. SAML is the older, XML-heavy, enterprise standard that corporate IT built their whole access model on, and the word that shows up when a serious buyer asks about SSO.

You’ll build the first two on day one because you need users. You’ll add the third the afternoon an enterprise deal makes it worth money — through a provider, never by hand. If I’d understood that split back in 2024, that questionnaire wouldn’t have cost me two nights and a little dignity. Now it won’t cost you any.

This is the Broken Engineer Guide. I over-engineer everything, fail at business, and share the learnings so you win. Ship the login, sell the SSO, and don’t touch the XML.