SAML vs OAuth vs OIDC: Differences and When to Use

SAML vs OAuth vs OIDC

Three protocols dominate sign-in and access delegation on the web, and they are constantly confused. SAML 2.0 is an XML-based standard for single sign-on: an identity provider tells an application, in a signed assertion, who the user is. OAuth 2.0 is a framework for delegated authorization: it lets an application obtain an access token to call an API on a user's behalf — it says nothing, by itself, about who the user is. OpenID Connect (OIDC) is an identity layer built on OAuth 2.0: it adds an ID token and standard user information, making OAuth's flows usable for login.

Short verdict: use OIDC for authentication in new web, mobile, and single-page applications. Use OAuth 2.0 access tokens to authorize API calls. Support SAML when enterprise customers require it for SSO with their identity provider — which, for B2B SaaS, is often. Many products implement all three: OIDC for their own login, SAML and OIDC as enterprise SSO options, and OAuth for their API.

TL;DR

SAML: authentication and SSO via signed XML assertions, delivered through the browser; enterprise heritage.
OAuth 2.0: authorization — access tokens for APIs; not a login protocol on its own.
OIDC: authentication on top of OAuth — an ID token (a JWT) plus a userinfo endpoint and discovery.
SAML is browser-centric; OIDC and OAuth work well for SPAs, mobile apps, and APIs.
Most enterprise identity providers — Entra ID, Okta, Google Workspace — support both SAML and OIDC.
Each has classic pitfalls: XML signature handling in SAML, misuse of access tokens for login in OAuth, and skipped token validation in OIDC.

Quick Example

An OIDC login starts with a browser redirect to the identity provider using the authorization code flow with PKCE:

After exchanging the code, the application validates the ID token — a signed JWT — and reads claims like these:

The SAML equivalent is an XML assertion, signed by the identity provider and posted to the application's assertion consumer service:

Both answer the same question — "who is this user, according to an identity provider I trust?" — in very different formats.

Core Concepts

Head-to-Head

SAML in Brief

The service provider (your app) redirects the user to the identity provider with an authentication request. The identity provider authenticates the user and returns a signed assertion through the browser, usually as an HTTP POST. The service provider validates the signature, issuer, audience, timestamps, and request correlation, then creates its own session. Configuration is exchanged as metadata documents containing endpoints and signing certificates.

OAuth 2.0 in Brief

OAuth lets a client obtain an access token from an authorization server to call a resource server (an API) with limited scopes. Modern flows are the authorization code flow with PKCE for user-facing apps, client credentials for service-to-service calls, and the device authorization flow for TVs and CLIs. An access token is meant for the API, not for the client to learn who the user is. See OAuth and OAuth Authorization Code with PKCE.

OIDC in Brief

OIDC adds the openid scope, an ID token describing the authentication event and user, a userinfo endpoint, standard claims, discovery, and key publication through JWKS. The client validates the ID token's signature, issuer, audience, expiry, and nonce. Because it reuses OAuth's flows, the same login can also yield access tokens for APIs. See OpenID Connect.

How They Combine

B2B SaaS: your app uses OIDC with its own identity service; each enterprise customer connects their identity provider via SAML or OIDC for SSO, and SCIM for user provisioning.
Consumer apps: "Sign in with Google or Apple" uses OIDC; your API uses OAuth access tokens issued by your authorization server.
APIs and integrations: third-party apps use OAuth to access user data with scopes the user approves.
Identity brokers — Entra ID, Okta, Auth0, Keycloak, Cognito — translate between protocols, so an application may speak only OIDC while customers connect via SAML.

See Single Sign-On and Identity Lifecycle Management.

Choosing a Protocol

Best Practices

Use Maintained Libraries and Providers

Never parse SAML XML or validate JWTs with hand-written code. Use well-maintained libraries or identity providers, and keep them updated.

Validate Everything

For SAML: signature over the assertion, issuer, audience, recipient, InResponseTo, and time conditions. For OIDC: signature with keys from JWKS, iss, aud, exp, and nonce. Allow only small clock skew.

Keep Tokens in Their Lanes

ID tokens are for the client to learn who logged in; access tokens are for APIs. Do not send ID tokens to APIs as credentials or treat access tokens as proof of identity in the client.

Plan for Key Rotation

Identity providers rotate signing keys. Fetch JWKS dynamically for OIDC, refresh SAML metadata on a schedule, and monitor certificate expiry.

Common Mistakes

Using OAuth Alone for Login

Weak SAML Signature Validation

Skipping Audience and Nonce Checks

FAQ

What is the difference between OAuth and OIDC?

OAuth 2.0 is for authorization: it issues access tokens that let applications call APIs. OIDC is built on OAuth and adds authentication: an ID token and standard claims that tell the application who the user is.

Is SAML outdated?

It is older and XML-based, but still widely deployed and required by many enterprises for SSO. New applications usually prefer OIDC, while B2B products typically support SAML for customers who need it.

Can I use SAML for mobile apps or APIs?

It is awkward. SAML is designed around browser redirects and posts. Mobile apps, SPAs, and APIs are much better served by OIDC and OAuth with PKCE and access tokens.

Is a JWT the same as OAuth?

No. JWT is a token format. OIDC ID tokens are always JWTs, and many OAuth access tokens are JWTs, but OAuth does not require any particular token format.

Do I need to implement all three?

Not usually by hand. Many products use an identity provider or broker that supports SAML, OIDC, and OAuth, and integrate with it through OIDC alone.