OAuth 2.0 vs OIDC vs SAML

OAuth 2.0, OpenID Connect (OIDC), and SAML are three different protocols that people constantly mix up because they all involve logging in. The short version: OAuth 2.0 is for authorization (granting access to resources), OIDC adds authentication (proving who you are) on top of OAuth, and SAML does both but through XML-based enterprise federation. Pick based on what you actually need: an API delegation, a consumer login, or corporate single sign-on.

Authorization vs authentication vs federation: what each one does

These three words are the whole confusion, so start here. Authentication answers "who are you?" (proving identity). Authorization answers "what are you allowed to do?" (granting access to a resource). Federation is the arrangement where one system trusts another system's identity claims, so a user authenticated in one domain is accepted in another without a second login.

Map that onto the protocols:

• OAuth 2.0 is an authorization framework. It hands out access to resources. It was never designed to tell an app who the user is.
• OIDC is an authentication layer built on OAuth 2.0. It reuses OAuth's flows and adds a standard way to answer "who is this user?".
• SAML is a federation protocol that carries both authentication and authorization data between an identity provider and a service provider.

The single most expensive mistake in this space is treating an OAuth access token as proof of identity. It is not. Hold that thought.

OAuth 2.0: delegated authorization, and what it is NOT

OAuth 2.0 is a delegated authorization framework: it lets a user grant one application limited access to their data on another service without sharing a password. When you click "connect your Google Calendar" inside a scheduling app, OAuth is what lets that app read your calendar without you handing it your Google password. The app receives a scoped, time-limited access token, not your credentials.

The specification is OAuth 2.0 RFC 6749 (https://datatracker.ietf.org/doc/html/rfc6749). It defines four roles: the resource owner (the user), the client (the app requesting access), the authorization server (issues tokens), and the resource server (holds the protected data).

What OAuth 2.0 is NOT: an authentication protocol. The spec says nothing standardized about the user's identity. An access token means "the bearer may call these APIs with these scopes." It does not reliably mean "this specific human is present and just logged in." Apps that inspect an access token and treat it as a login are building on sand, because access tokens are meant for the resource server, not the client, and their format is not guaranteed.

Grant types (now called flows) worth knowing:

• Authorization Code with PKCE: the default for web apps, mobile apps, and single-page apps. The client gets a short code, then exchanges it server-to-server for tokens. PKCE (Proof Key for Code Exchange) protects public clients that cannot keep a secret.
• Client Credentials: no user at all. One service authenticates as itself to call another. This is the machine-to-machine flow.
• Refresh Token: not a login flow, but a grant used to get a new access token when the old one expires, without prompting the user again.
• Device Authorization: for input-constrained devices like TVs, where you enter a code on your phone.

The old Implicit and Resource Owner Password Credentials grants are effectively deprecated. Do not build new systems on them.

OIDC: the identity layer on top of OAuth 2.0

OpenID Connect is a thin authentication layer built directly on OAuth 2.0 that adds a standardized way to verify a user's identity. It uses the same Authorization Code flow, the same endpoints, and the same tokens, then adds one crucial thing: the ID token. The spec is OpenID Connect Core 1.0 (https://openid.net/specs/openid-connect-core-1_0.html).

The ID token is a JWT (JSON Web Token, RFC 7519, https://datatracker.ietf.org/doc/html/rfc7519) that the client is meant to read. It contains claims like sub (a stable unique user ID), iss (who issued it), aud (who it is for), iat and exp (issued-at and expiry times), and often email or name. The client validates the signature and those claims, and now it knows who logged in. That is the piece plain OAuth never gave you.

OIDC also standardizes a /userinfo endpoint (call it with the access token to fetch more profile claims) and a discovery document at /.well-known/openid-configuration that advertises all endpoints and keys. "Sign in with Google," "Sign in with Apple," and most modern consumer login buttons are OIDC under the hood. If you want authentication and you have a choice, OIDC is almost always the right modern answer over raw OAuth.

SAML: XML-based federation, the enterprise SSO incumbent

SAML 2.0 is an XML-based federation standard that enterprises use for single sign-on, and despite its age it remains the incumbent in corporate IT. It predates OAuth (SAML 2.0 was ratified in 2005) and it bundles authentication and authorization into signed XML documents called assertions. The specification is maintained by OASIS (https://docs.oasis-open.org/security/saml/v2.0/).

SAML has two main actors: the Identity Provider (IdP), such as Okta, Microsoft Entra ID, or Ping, which authenticates the user, and the Service Provider (SP), the app the user wants to reach. The common web SSO pattern is the SP-initiated flow with HTTP POST binding: the user hits the app, gets redirected to the IdP, authenticates there, and the IdP posts a signed SAML assertion back to the app's Assertion Consumer Service URL. The app validates the XML signature and logs the user in.

A SAML assertion carries three kinds of statements: authentication (how and when the user proved identity), attribute (email, groups, department), and sometimes authorization decision statements. Trust rests on XML digital signatures and pre-exchanged metadata between IdP and SP.

Why it persists: enterprise IT already runs SAML, auditors know it, and every serious IdP speaks it. If you are selling B2B software, buyers will ask for SAML by name. See Add SSO to Your B2B SaaS for the practical build.

Token types: what each one is for

The word "token" hides four very different objects. Confusing their audiences is the root of most bugs.

The rule that saves you: the access token is for the API, the ID token is for you. Never authenticate a user by reading their access token, and never send an ID token to an API as if it were an access token.

When to use which: the decision table

Match the scenario to the protocol, not the other way around. Most real systems combine two of these.

Practical default: build new consumer and mobile logins on OIDC, expose delegated API access with OAuth 2.0 scopes, and support SAML because enterprise procurement demands it. For a broader view of the vendor landscape, see Top IAM solutions and What Is CIAM.

The most common conflations and mistakes

Almost every error here comes from blurring the three words in section two. The worst offenders:

1. Using OAuth 2.0 as authentication. Reading an access token to identify the user. Access tokens are for the resource server and may be opaque or reassigned. Use OIDC and read the ID token instead. This is the "pseudo-authentication" antipattern that OIDC was literally created to fix.
2. Sending the ID token to an API. The ID token is for the client. APIs should receive the access token. Swapping them breaks audience validation and leaks identity data to the wrong party.
3. Thinking OIDC replaces SAML for enterprise. Technically OIDC can do enterprise SSO, but many corporate IdPs, auditors, and procurement checklists still require SAML by name. Support both.
4. Treating SAML as "old and therefore insecure." SAML is verbose XML and easy to implement wrong (signature-wrapping attacks are real), but the protocol itself is sound and dominant in the enterprise. The risk is in the implementation, not the standard.
5. Assuming a refresh token is a login. It is a grant to mint new access tokens silently. It says nothing about a human being present right now.
6. Believing you must choose one. You usually run OIDC for login, OAuth scopes for APIs, and SAML for enterprise customers, all at once. For deeper security context, see Application Security 101.