OAuth vs OIDC vs SAML: What's the Difference?

OAuth 2.0, OpenID Connect (OIDC), and SAML are the three protocols behind nearly every “Sign in with…” button and corporate single sign-on portal — and they answer three different questions. OAuth answers “is this app allowed to access this resource?” OIDC answers “who is this user?” SAML answers the same identity question as OIDC, but in an older, XML-based dialect that enterprises standardized on a decade earlier. Confusing them is easy because they travel together, and because vendors use “OAuth login” loosely when they mean OIDC.

Here’s what each one actually does, and how to choose.

OAuth 2.0: delegated authorization

OAuth 2.0 lets a user grant one application limited access to their data on another service without sharing a password. The output is an access token — a scoped, short-lived credential the app presents to an API. What OAuth deliberately does not tell the client is who the user is; an access token is a capability, not an identity. That distinction matters: treating an access token as proof of identity is a classic security anti-pattern.

OAuth defines several grant types for different kinds of clients, but the shape is always the same — user consents, client gets a token, token unlocks an API.

OpenID Connect: authentication on top of OAuth

OIDC is a thin identity layer built directly on OAuth 2.0, published in 2014. It reuses the same flows and endpoints, and adds one crucial artifact: the ID token, a signed JWT containing claims about the user — a stable subject identifier, name, email, and when and how they authenticated. It also standardizes a userinfo endpoint and discovery documents so clients can configure themselves automatically.

When you click “Sign in with Google,” OIDC is doing the login and OAuth is doing the plumbing underneath. If your app needs to know who the user is, OIDC — not raw OAuth — is the protocol you’re looking for. Increasingly, the password step at the identity provider itself is being replaced by passkeys, but what your app receives afterward is unchanged: a signed ID token.

SAML: the enterprise veteran

SAML 2.0 (Security Assertion Markup Language) predates both, finalized in 2005. It exchanges XML documents called assertions between an identity provider (the system that knows who you are — Okta, Microsoft Entra ID, a university login) and a service provider (the app you’re trying to reach). The assertion is digitally signed XML, typically delivered by redirecting the browser and auto-submitting an HTML form.

SAML is verbose and famously fiddly to implement — XML signature validation has produced a long history of vulnerabilities — but it is deeply entrenched. Thousands of enterprise applications and every major identity provider support it, and B2B customers routinely require “SAML SSO” as a checkbox feature before they’ll buy software. It handles authentication and coarse authorization attributes, but it has no real story for API access; that’s OAuth’s territory.

The comparison

	OAuth 2.0	OIDC	SAML 2.0
Question answered	Can this app access this resource?	Who is this user?	Who is this user?
Category	Authorization	Authentication	Authentication (SSO)
Token format	Access token (often a JWT)	ID token (always a JWT)	XML assertion
Transport	HTTPS redirects + JSON APIs	HTTPS redirects + JSON APIs	Browser redirects + XML over HTTP POST
Typical use	Third-party API access	Consumer and app login	Enterprise workforce SSO
First released	2012	2014	2005

What SSO actually means

Single sign-on is an outcome, not a protocol: sign in once with an identity provider, and every connected application trusts that session instead of running its own login. Both SAML and OIDC deliver it — the identity provider keeps a session, and each app receives a signed assertion or ID token proving who you are. SSO is also the foundation that zero-trust security models build on, since verifying identity on every request only works when identity comes from one authoritative source.

The practical difference is vintage. SAML dominates workforce SSO because it got there first and enterprise IT built around it. OIDC dominates everything built since — it’s JSON instead of XML, mobile-friendly, and far simpler to implement correctly.

Which one should you use?

• Building login for a consumer app or SaaS product? Use OIDC. Every major identity provider supports it, libraries are mature, and it composes cleanly with the OAuth flows you’ll need for API access anyway.
• Selling to enterprises? Support OIDC first, and add SAML when customers ask — many corporate identity setups still speak SAML only. Most teams don’t hand-roll this; identity platforms and SSO middleware translate between the two.
• Calling APIs on a user’s behalf, or between services? That’s OAuth 2.0 proper — pick the right grant type and scope tokens tightly.
• Starting a system from scratch in 2026? There is no reason to introduce SAML voluntarily. Reach for it only when an integration partner requires it.

The three aren’t competitors so much as layers and generations: OAuth moves authorization tokens, OIDC layers identity on top of OAuth, and SAML is the previous generation’s answer to the same identity problem, still running much of the corporate world.

The takeaway

OAuth 2.0 is authorization — it gets an app permission to use an API. OIDC is authentication built on OAuth — it tells the app who the user is via a signed ID token. SAML is the older XML-based route to the same answer, still standard for enterprise SSO. For anything new: OIDC for login, OAuth for API access, and SAML only when a customer’s identity provider leaves you no choice.