Three layers that get conflated into one word
"OAuth" gets used as a catch-all in a way that hides three genuinely separate problems. OAuth2 is an authorization framework — it answers "can this application act on my behalf, with this specific scope of access," and by itself says nothing about who the user actually is. OIDC (OpenID Connect) is an authentication layer built directly on top of OAuth2, adding the piece OAuth2 deliberately left out: proof of identity. SAML is a separate, older standard that solves authentication and single sign-on a structurally different way, using signed XML instead of JWTs.
OAuth2: delegated authorization, not identity
When an app asks to "access your Google Contacts," that's OAuth2: the user grants a scoped, revocable permission, and the app receives an access token proving it holds that permission — typically the same kind of bearer JWT covered in the JWT & API auth module, though OAuth2 itself doesn't require any particular token format. The secure flow for this is the Authorization Code flow, and for any client that can't safely hold a secret (a mobile app, a single-page app), it's extended with PKCE (Proof Key for Code Exchange): the client generates a random secret locally and proves possession of it at the token-exchange step, so an attacker who intercepts the authorization code in transit still can't redeem it without that locally-held secret.
Critically, none of this tells the app who the user is — only what the app is now allowed to do. That gap is exactly what OIDC exists to close.
Practice
A mobile app implements OAuth2's Authorization Code flow but, as a public client, can't securely store a client secret. Which OAuth2 extension should it use so an intercepted authorization code can't be redeemed by an attacker?
OIDC: OAuth2 plus a signed proof of identity
OIDC adds exactly one new thing on top of OAuth2: the ID token, a JWT — always signed, always following the exact structure covered in the JWT & API auth module — carrying standardized identity claims (sub for the user's stable identifier, iss for who issued it, aud for who it's intended for, exp for expiry). Because it's a normal JWT, everything already covered about verifying signatures, reading (not trusting) the payload, and algorithm-confusion pitfalls applies directly here without needing to be re-explained.
Practice
An OIDC ID token is issued with iat (issued-at, Unix timestamp) = 1700000000 and a validity window of exactly 3600 seconds (1 hour). What is the exp claim's value?
SAML: the XML-based predecessor, still very much in production
SAML solves the same core problem as OIDC — proving a user's identity to a service they haven't directly authenticated with — but predates JWTs, and does it with signed XML assertions instead: an Identity Provider (IdP) produces a SAML assertion, cryptographically signed using XML-DSig, and the browser carries it to the Service Provider (SP) via a redirect or an auto-submitting form POST, rather than the bearer-token-in-a-header pattern OAuth2/OIDC use.
SAML hasn't disappeared — it remains the default for a large share of enterprise SSO, particularly for older or vendor-provided enterprise applications that were built against it long before OIDC existed, which is why identity providers like Okta and Azure AD support both protocols side by side rather than one replacing the other outright.
OIDC
- •Identity carried in a signed JWT (the ID token)
- •Built on OAuth2's redirect + token-exchange model
- •The modern default for consumer apps, mobile, and API-first architectures
SAML
- •Identity carried in a signed XML assertion (XML-DSig)
- •Uses browser redirects or auto-submitting form POSTs, not a token-exchange API call
- •Still the default for much legacy and vendor-provided enterprise SSO
Where a legacy system forces the choice
In practice the decision is often made for you by what the other side actually understands.
Practice
A company's legacy HR platform only understands XML-based SSO assertions signed with XML-DSig — it has no support for JSON-based tokens at all. Which protocol should the identity provider use to authenticate users into it: OAuth2, OIDC, or SAML?
Where FIDO and passkeys fit — a different layer entirely
It's worth being precise about what FIDO/WebAuthn (covered in the Passkeys module) actually replaces here, because it's easy to conflate with OIDC or SAML: FIDO solves how a user proves their identity to the identity provider in the first place — replacing a password with a signed challenge-response — while OIDC and SAML solve a separate problem, how that already-established identity gets propagated from the IdP to other applications. The two compose rather than compete: a user might log into Okta using a passkey, and Okta then issues an OIDC ID token (or a SAML assertion) to every downstream application that trusts it, without any of those downstream apps ever knowing or caring that a passkey was involved.