OAuth vs OIDC vs SAML: Which One Actually Solves Your Auth Problem

Three acronyms, one question underneath all of them: how does a user prove who they are, and how does your app get permission to act on their behalf. They get used interchangeably in casual conversation, and that’s where the trouble starts. Here’s the actual answer: OAuth handles authorization, OIDC adds identity to OAuth, and SAML is the older standard that does both in one XML-based package and still runs a large share of enterprise SSO.

OAuth 2.0: authorization, not identity

OAuth 2.0 solves a specific problem: letting an app get limited, revocable permission to act on a user’s behalf against some resource, without handing over the user’s password. When you click “connect your Google Calendar,” OAuth is the protocol negotiating that a calendar app gets read access to your events, and nothing more.

1. App redirects user to Google's authorization server
2. User logs in to Google and approves the requested scopes (e.g. calendar.readonly)
3. Google redirects back with an authorization code
4. App exchanges the code for an access token
5. App uses the access token to call Google's Calendar API

Notice what’s missing: at no point does this flow give the app a standardized, verifiable statement of who the user is. The access token proves the app has permission to call an API. It doesn’t inherently prove identity. Some early implementations used the presence of a working access token as a stand-in for “user is logged in,” which works until it doesn’t; access tokens aren’t guaranteed to be tied to a specific verifiable subject in a format every client can check, and treating an authorization protocol as an authentication protocol is where a lot of subtle security bugs have come from historically.

OpenID Connect: OAuth plus a real identity layer

OpenID Connect (OIDC) is built directly on top of OAuth 2.0. It doesn’t compete with OAuth, it completes it for the login use case by adding a second, standardized token: the ID token.

{
  "iss": "https://accounts.example.com",
  "sub": "110169484474386276334",
  "aud": "your-client-id",
  "exp": 1751500000,
  "iat": 1751496400,
  "email": "user@example.com",
  "email_verified": true
}

The ID token is a signed JWT. sub is the stable, unique identifier for the user. iss tells you which identity provider issued it, and your app verifies the signature against that provider’s published keys before trusting any of it. This is the piece that actually answers “who is this person,” in a format every OIDC-compliant client can parse and verify the same way.

For a typical web app, the flow you want is Authorization Code with PKCE (Proof Key for Code Exchange), which protects the code exchange step even for public clients like single-page apps or mobile apps that can’t keep a client secret truly secret:

// Simplified PKCE flow with a library like oidc-client-ts
const auth = new UserManager({
  authority: "https://accounts.example.com",
  client_id: "your-client-id",
  redirect_uri: "https://yourapp.com/callback",
  response_type: "code",
  scope: "openid profile email",
});

await auth.signinRedirect(); // starts the PKCE flow
// on callback:
const user = await auth.signinRedirectCallback();
console.log(user.profile.sub, user.profile.email);

If you’re building “log in with Google/Microsoft/Okta” into a new product today, this is the protocol you want. Almost every modern identity platform, Auth0, Clerk, Firebase Auth, Okta, Azure AD (Microsoft Entra ID), speaks OIDC as the default. For the implementation details of the PKCE flow itself, including token storage and refresh handling in a single-page app, see our OAuth 2.0 and PKCE guide.

SAML: older, XML-based, still everywhere in the enterprise

SAML (Security Assertion Markup Language) predates OAuth and OIDC by years and solves a similar problem through a completely different mechanism: XML-based assertions signed by an identity provider and posted to a service provider through the browser.

<saml:Assertion>
  <saml:Subject>
    <saml:NameID>user@example.com</saml:NameID>
  </saml:Subject>
  <saml:AttributeStatement>
    <saml:Attribute Name="Department">
      <saml:AttributeValue>Engineering</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

SAML is verbose, harder to debug (XML signature validation has a long history of implementation bugs across libraries), and has no native concept of mobile-friendly flows the way OIDC does with PKCE. None of that has displaced it, because a large share of the enterprise identity world, Okta, Azure AD, OneLogin, and countless internal identity providers, was built around SAML for SSO before OIDC existed or matured, and ripping out an established SSO integration is expensive and risky for the customer, not just for you.

The practical consequence: if you sell software to enterprises, you will eventually get a support ticket that includes a SAML metadata XML file and an expectation that you support it, regardless of how modern your own stack is.

Picking one

	OAuth 2.0	OIDC	SAML
Solves	Authorization (delegated access)	Authentication + authorization	Authentication (mostly SSO)
Format	Access tokens (often opaque or JWT)	ID token (JWT) + access token	XML assertions
Best fit	API access delegation (“connect your account”)	New app login, social login, mobile/SPA auth	Enterprise SSO integrations
Mobile/SPA friendly	Yes, with PKCE	Yes, with PKCE	Poor; built for browser-based enterprise flows
Still actively growing	Yes, as the base layer under OIDC	Yes, the modern default	Stable install base, not growing

For a new product: build on OIDC. It gives you standardized identity, works cleanly across web, mobile, and SPA clients, and has the strongest current library and platform support. Treat raw OAuth as what it is, an authorization mechanism, not a login mechanism, even though it’s the layer OIDC is built on. Add SAML only when a specific enterprise customer’s identity team requires it, and treat it as an integration you support on request rather than your primary auth architecture.

Whichever protocol you land on, the implementation details, token storage, session handling, and secret management around it matter as much as the protocol choice itself; a correct OIDC integration with tokens stored insecurely is still a vulnerability. If you’re auditing your current setup, our technical due diligence guide covers what a proper authentication review actually checks for beyond “does login work.”