OAuth, OpenID Connect and SAML compared

OAuth 2.0, OpenID Connect and SAML 2.0 are often listed as alternatives. Only two of them are. OAuth is for authorization: letting a client call an API. OpenID Connect and SAML are both for federated authentication: letting an application sign a user in on the strength of an identity provider's login. Most organizations run all three at once, usually through the same identity provider.

Each in one line

OAuth 2.0

A framework for issuing access tokens that let a client call an API on a user's (or its own) behalf. RFC 6749 (2012), secured by RFC 9700 (2025). See OAuth 2.0.

OpenID Connect

An identity layer on OAuth: the client also receives a signed ID token saying who signed in, when and how. OpenID Foundation, Core 1.0 (2014, errata set 2 in 2023). See OpenID Connect.

SAML 2.0

An XML-based standard in which an identity provider sends a signed assertion through the browser to a service provider. OASIS (2005, with approved errata). See SAML 2.0.

Side by side

Logout deserves a caution in all three: each application has its own session, and "single" logout only works if every participant implements it and the messages actually reach them. Treat it as best effort, and keep application sessions reasonably short.

When to use which

• A new web, mobile or single-page application needs users to sign in: OpenID Connect with the authorization code flow and PKCE. It works natively in mobile apps and SPAs, uses JSON and JWTs that every platform handles, and gives you an access token for your own API from the same flow.
• An application needs to call an API on a user's behalf, or a service needs to call another service: OAuth 2.0 (authorization code + PKCE for users, client credentials for services). Add OpenID Connect only if the client also needs to know who the user is.
• A SaaS product or enterprise application only offers SAML: use SAML for it. It is mature, well supported by enterprise identity providers, and there is no security reason to avoid it if the SP validates correctly.
• You are building a product that enterprises will connect to their IdP: support OpenID Connect, and SAML as well if your customers ask for it; many enterprise IdPs are configured around SAML.
• A device with no browser: the OAuth device authorization grant, with OIDC scopes if you need identity.

How they coexist in federation

In practice the identity provider is the hub. The user signs in once at the IdP, with whatever authentication strength its policy requires, and the IdP issues whichever artifact each application understands: a SAML assertion for the SaaS app, an ID token for the new web app, an access token for the API that web app calls. The protocols differ, but the authentication event behind them is the same, so policy decisions (MFA, device posture, session length) belong at the IdP, not in each protocol.

Some patterns that follow:

• Protocol translation. An IdP or federation proxy can accept SAML from an upstream partner IdP and issue OIDC to internal apps, or the reverse. NIST SP 800-63C-4 calls such components federation proxies ("sometimes referred to as brokers"). It notes that they can translate between federation protocols, that all subscriber information flows through them (so an attacker who compromises the proxy gets subscriber attributes and activity without targeting the IdP or RP), and that the FAL seen by the downstream RP is the lowest FAL along the whole path, which the proxy SHALL represent accurately (§3.3.3).
• Same assurance rules for both assertion formats. SP 800-63C-4 treats the OIDC ID token and the SAML assertion as examples of the same thing, an assertion, and applies the same federation assurance levels to both. At every FAL the RP SHALL validate the assertion, the IdP SHALL sign it, and it SHALL be audience-restricted with replay protection. At FAL2 the assertion is restricted to a single RP and the transaction SHALL be initiated by the RP, which rules out IdP-initiated SAML at that level.
• Account keys. Whatever the protocol, key federated accounts on the issuer plus its stable subject identifier: (iss, sub) in OIDC, (IdP entity ID, persistent NameID) in SAML. Never on email alone.
• Tokens do not cross protocols by themselves. A SAML assertion is not an OAuth access token, and an ID token is not either. If an API must trust a login that happened via SAML, the IdP or a token service issues a proper access token for that API.

Federation assurance at a glance

From NIST SP 800-63C-4 Table 1, which applies equally to OIDC and SAML:

See assurance levels for how FAL relates to AAL and IAL.

Practical guidance

• Default to OpenID Connect for new sign-in integrations and OAuth for API access; keep SAML for applications that need it.
• Run all three from one identity provider so authentication policy is enforced in one place.
• Prefer SP- or RP-initiated flows; they are required at FAL2 and above.
• Validate artifacts fully: ID token validation, SAML response validation, access token validation.
• Key accounts on issuer plus stable subject, never on email.
• Do not use ID tokens or SAML assertions as API credentials; issue access tokens.
• Inventory every federated application and its protocol, and review it alongside your access reviews.

Sources

1. RFC 6749: The OAuth 2.0 Authorization Framework, IETF. IETF Trust Legal Provisions (brief quotations with attribution).
2. OpenID Connect Core 1.0 incorporating errata set 2, OpenID Foundation. OpenID Foundation specification (cited, brief quotations).
3. Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS. OASIS specification (cited, brief quotations).
4. NIST SP 800-63C-4: Digital Identity Guidelines, Federation and Assertions, NIST. Public domain (U.S. government work).
5. RFC 9700: Best Current Practice for OAuth 2.0 Security, IETF. IETF Trust Legal Provisions (brief quotations with attribution).
6. SAML V2.0 Errata 05, OASIS. OASIS specification (cited, brief quotations).