Coder Legion - Recent posts tagged oidc

SAML vs OIDC vs OAuth: The 60-Second B2B Playbook

Thu, 23 Apr 2026 05:29:52 +0000

SAML vs OIDC vs OAuth: The 60-Second B2B Playbook

TL;DR (read this first): OAuth 2.0 is authorization (a valet key for APIs). OIDC is authentication built on top of OAuth 2.0 (modern login for web, mobile, and SPAs). SAML 2.0 is a separate, XML-based protocol designed for enterprise Single Sign-On. If you are building a B2B SaaS in 2026, you will end up shipping all three — not picking one. The only real question is whether you build that plumbing yourself or front-end it with an identity broker like SSOJet.

Most "SAML vs OIDC vs OAuth" articles treat the three protocols as competitors. They are not. They solve different problems, were designed in different decades, and, in a real B2B product, they coexist.

This playbook gives you the 60-second decision tree, the 12 differences that actually matter in production, and the migration path enterprise customers will eventually force you down.

The 60-Second Decision Tree

Before we go deep, here is the decision your engineering team actually has to make. Read it out loud once and you will never confuse these protocols again.

Do you need to let a third-party app call an API on behalf of a user? → OAuth 2.0 (authorization).
Do you need to know who the user is so you can log them into your app? → OIDC (authentication, built on OAuth 2.0).
Is the customer a Fortune 500 buying your SaaS, and their IT team just emailed you an XML metadata file? → SAML 2.0 (enterprise SSO, non-negotiable).
All three of the above in the same product? → Welcome to B2B SaaS. You need a protocol-agnostic identity layer.

If you want a short mnemonic engineers actually remember: AuthN is SAML and OIDC. AuthZ is OAuth. OIDC is the one that speaks JSON.

Quick-Answer Comparison Table

Dimension	SAML 2.0	OIDC	OAuth 2.0
Purpose	Enterprise SSO / federation	User authentication	Delegated authorization
Year standardized	2005 (OASIS)	2014 (OpenID Foundation)	2012 (IETF, RFC 6749)
Token format	XML assertions	JSON Web Tokens (JWT)	Opaque strings or JWTs
Message signing	XML-DSig / XML-Enc	JOSE (JWS / JWE)	JOSE when JWTs are used
Transport	Browser redirects (HTTP-POST / Redirect / Artifact)	REST + JSON over HTTPS	REST + JSON over HTTPS
Discovery	Static XML metadata file	`/.well-known/openid-configuration` + JWKS URI	Manual or via OIDC discovery
Mobile / native app fit	Poor (designed for browsers)	Excellent	Excellent
Typical buyer	Enterprise IT / CISO	Developers / product teams	API / platform teams
Session & logout	Formal SLO spec (brittle in practice)	Front-channel / back-channel logout	Not defined (token revocation only)
Provisioning pair	Usually paired with SCIM	Usually paired with SCIM	N/A
Recommended flow (2026)	Web Browser SSO Profile	Authorization Code + PKCE	Authorization Code + PKCE / Client Credentials
Ease of debugging	Painful (XML signature errors)	Moderate (JWT is inspectable)	Moderate

Keep that table bookmarked. The rest of this playbook is just the "why" behind each row.

1. Protocol Origins: Why Each One Exists

Understanding the design goals of each protocol is the fastest way to stop confusing them.

SAML 2.0 was ratified by OASIS in March 2005, consolidating several earlier federation specs (Shibboleth, Liberty Alliance). It was built for a world where enterprises needed to bridge on-prem Active Directory with external web apps over a browser. Its design is optimized for heavy, attribute-rich assertions between two organizations that have a formal, pre-established trust relationship.

OAuth 2.0 was published as RFC 6749 in October 2012 by the IETF OAuth Working Group. Its explicit goal was not authentication. It answered the question: "How can a user let App A read their data in App B without handing App A their App B password?" Think of the first "Sign in with Twitter to post to Facebook" flows — that is the problem OAuth was invented for.

OpenID Connect (OIDC) launched on February 26, 2014, published by the OpenID Foundation. Developers were misusing OAuth 2.0 as a login protocol (because it was easier than SAML), and doing it badly and insecurely. OIDC standardized the pattern: it adds a signed ID Token (a JWT) on top of OAuth 2.0 so an app can reliably know who the user is.

So the lineage is simple: OAuth gave us delegation, OIDC added identity, SAML was already doing both for enterprises a decade earlier — just in XML.

2. Token Formats: XML Verbosity vs JWT Portability

This is where the protocols feel most different in day-to-day engineering.

A SAML assertion is a signed XML document — typically 2–8 KB, sometimes much larger once attribute statements and certificates are included. Signing uses XML-DSig, and if you have ever debugged an "XML Signature Wrapping" attack or a canonicalization mismatch, you know why SAML has a reputation for being brittle.

An OIDC ID Token is a compact JWT — usually a few hundred bytes to 1 KB, Base64URL-encoded, signed via JWS (JSON Web Signatures) using the JOSE framework. You can paste it into jwt.io and read it. Your backend can verify it in one line of code in almost any language.

Why this matters in production:

JWTs are mobile- and SPA-friendly. SAML assertions are not.
JWTs can be passed in an Authorization: Bearer header. SAML assertions typically cannot.
XML parsing is CPU-intensive. At scale, the difference between parsing 50,000 SAML assertions/sec and 50,000 JWTs/sec is measurable in servers and dollars.
JWTs have well-known attack classes (alg: none, key confusion) but they are documented attack classes. SAML's attack surface includes XSLT injection, entity expansion, and signature wrapping — a deeper, scarier well.

When enterprise customers ask "why are you pushing OIDC?", the honest answer is: because JWTs are easier to get right.

3. Transport and Flows

SAML rides on the browser. The three SAML bindings you will actually see are HTTP-Redirect (for requests, because they are small), HTTP-POST (for responses, because assertions are large), and occasionally HTTP-Artifact (for back-channel retrieval when you cannot trust the browser). Every SAML SSO flow goes: user → SP → browser redirect → IdP → browser POST → SP's Assertion Consumer Service (ACS) endpoint.

OIDC and OAuth ride on REST. The recommended flow in 2026 for every client type — web, SPA, mobile, desktop — is Authorization Code with PKCE (Proof Key for Code Exchange, RFC 7636). For machine-to-machine calls, OAuth 2.0 provides the Client Credentials grant, which SAML has no real equivalent to.

The practical consequence: if your product has a mobile app, a CLI, or any non-browser client, SAML alone is insufficient. You will need OIDC or OAuth to cover those surfaces.

For a deeper look at how modern OAuth flows are evolving, our OAuth 2.1 security defaults and migration checklist explains what has been deprecated and why.

4. Discovery and Key Rotation: Where SAML Ages Badly

This is the section that quietly destroys SAML deployments at 3 AM.

SAML discovery is static. Each party publishes an EntityDescriptor XML metadata file that lists endpoints, supported bindings, and — critically — embeds X.509 certificates inside <KeyDescriptor> elements. You either exchange this file manually (over email, seriously) or host it at a stable URL your partner polls.

Certificate rotation is where SAML deployments fail. When your SAML signing cert expires, every downstream SP breaks at once unless you have published the new cert inside the metadata during an overlap window and every partner has actually refreshed their copy. If you run B2B SAML at any scale, you will eventually have a war story about a Monday morning where 40 enterprise tenants lost SSO because a cert rolled over and half of them had cached the old metadata.

OIDC discovery is dynamic. An OIDC provider publishes /.well-known/openid-configuration, and inside that document is a jwks_uri pointing to a live JSON Web Key Set. Keys rotate by simply publishing a new key at the JWKS endpoint with a new kid (key ID). Clients automatically pick up the rotation on their next token validation. No emails, no coordination, no outages.

For the full operational playbook on this topic, see our guide on enterprise federation and SAML metadata management.

5. Enterprise vs Consumer Fit

There is a reason large, regulated enterprises still demand SAML in 2026. It is not nostalgia — it is procurement.

SAML 2.0 has 20 years of deployment inside ADFS, Ping Identity, Shibboleth, and established federation networks like InCommon and eduGAIN. It has been audited into FedRAMP, HIPAA, and banking-sector compliance documents. Your customer's CISO does not care that JWTs are more modern; they care that their auditor already has a checklist for SAML.

OIDC, on the other hand, dominates modern CIAM (Customer Identity and Access Management), SPAs, mobile apps, and workforce SSO at companies founded after 2015. Entra ID, Okta, Auth0, Google Workspace, and every modern IdP support it natively, and it plays well with everything downstream.

The B2B SaaS reality: ship both. Your mid-market customers will ask for OIDC (or be happy with either). Your enterprise customers will hand you a SAML metadata XML file on day one of procurement and expect you to make it work. This is exactly the pattern our SSO protocol primer: SAML, OIDC and OAuth explained walks through in more detail.

6. Session Management and the Single Logout Nightmare

SAML has a formal Single Logout (SLO) specification. In practice, it is one of the most reliably broken features in enterprise identity.

SLO requires the IdP to notify every SP that the user's session ended. The front-channel version does this by redirecting the user's browser through every SP's logout URL sequentially — which fails the instant the user closes the tab, hits an ad blocker, or a popup blocker intervenes. The back-channel version uses server-to-server SOAP calls, which are more reliable but require every SP to be reachable from the IdP over a network that firewalls rarely permit. The SAML spec itself acknowledges "partial logout" as a valid outcome.

OIDC defines front-channel, back-channel, and session management logout modes. None of them are perfect either, but they use modern transports (iframes, direct HTTP calls) and standardized JWTs for logout tokens. Failures are easier to debug.

Honest take: if you promise customers "one-click log out of everything," read the fine print of whichever spec you pick. SLO is hard in every protocol. Plan for session TTLs and step-up auth rather than relying on SLO to save you.

7. Provisioning: SCIM Is the Missing Piece

Neither SAML nor OIDC handles user lifecycle well on its own. Both can do Just-In-Time (JIT) provisioning — creating a user account in your app the first time they authenticate — but JIT has a fatal flaw: it does not handle deprovisioning.

When an enterprise fires an employee, the identity provider revokes access instantly. But if your app was relying on JIT, that user's account in your system still exists, with the last set of attributes it saw. Orphaned accounts are a compliance finding waiting to happen.

The fix is SCIM (System for Cross-domain Identity Management) — an out-of-band REST API the IdP calls to create, update, and deactivate users in your app in near real time. Modern B2B SSO is really a three-legged stool: SAML or OIDC for login + SCIM for lifecycle + MFA enforcement for compliance.

Most enterprise procurement checklists in 2026 require all three. If you implement only SSO, you will still fail security reviews.

8. Tooling and Developer Ecosystem

Okta, Auth0, Microsoft Entra ID, Google, and Ping all support SAML and OIDC. The libraries exist in every major language. But the quality of experience differs sharply.

OIDC libraries are generally first-class, actively maintained, and have sensible defaults. openid-client for Node, authlib for Python, Spring Security OAuth for Java.
SAML libraries tend to be older, less m

Understanding OAuth 2.0 and OpenID Connect: A Step-by-Step Guide

Thu, 03 Jul 2025 20:54:49 +0000

If you’ve ever clicked “Sign in with Google” or “Connect with Facebook” on a website or app, you’ve interacted with technologies called OAuth and OpenID Connect (OIDC). These two standards form the backbone of secure authentication and authorization on the web today.

This guide will walk you through everything you need to know, in simple language and step-by-step explanations. By the end, you’ll have a solid grasp of both protocols, their roles, and why they matter.

Authentication and Authorization

Before diving into OAuth and OIDC, it’s important to understand two key concepts:

Authentication → process of verifying who you are. For example, logging in with your username and password proves your identity.
Authorization → process of determining what you’re allowed to do. For instance, once logged in, determining if you have permission to access certain files or perform specific actions.

The Limitations of Password-Based Logins (and Why OAuth/OIDC Exist)

Most websites and apps still rely on the traditional method of logging in with a username and password. While simple, this approach has several serious drawbacks:

User Experience Challenges

Remembering multiple passwords is difficult.
Users face friction creating and managing separate accounts.

Security Threats

Phishing attacks trick users into handing over passwords.
Weak or reused passwords put accounts at risk.

Storage and Management Burdens

Storing passwords securely is challenging.

As we’ve seen, managing multiple usernames and passwords is both inconvenient and insecure. Single Sign-On (SSO) reduces password fatigue by letting you log in once to access multiple apps within the same organization.

However, SSO typically works only inside one organization or domain. Federated Login solves this by letting you use trusted providers like Google or Facebook to sign in across different websites. This builds cross-domain trust without needing separate passwords for every service.

OAuth 2.0 provides the framework for handling secure access to user data without sharing passwords. OpenID Connect (OIDC) builds on OAuth to add login and identity, making federated login possible across websites.

OAuth 2.0 Intuition

Think of OAuth like getting a signed access pass from City Hall so you can pick up someone else’s property from a secure warehouse.

Here’s how it works:

Your friend (Resource Owner) wants You (Client) to pick up their box from the Warehouse (Resource Server).
Your friend goes to City Hall (Authorization Server). At City Hall:
- They present their ID for identity verification (e.g., username/password).
- They explicitly state → “I want to authorize this person to collect my box”.
City Hall reviews and approves the request. They issue your friend an Authorization Letter.
Your friend gives You the authorization letter from City Hall, saying → “Take this back to City Hall to get your official access pass”.
You take the authorization letter back to City Hall :
- City Hall verifies the authorization letter by confirming that it’s legitimate and hasn’t expired.
- City Hall then issues you a signed access pass.
You take the signed access pass to the Warehouse (Resource Server):
- The Warehouse examines the pass, verifies City Hall’s signature to ensure it’s authentic.
- It checks who authorized it (your friend), whom it’s allowed for (you), what it allows (picking up the box), and expiry date.
- Once all details are validated, the Warehouse gives you the box on behalf of your friend.

OAuth 2.0: The Authorization Framework

When a client app needs to act on a user’s behalf → like accessing their files, calendar, or other resources → it needs a way to request permission securely. OAuth 2.0 provides a standardized framework for this authorization, allowing users to grant limited access to the apps without sharing their passwords with them.

OAuth 2.0 focuses purely on what an app is allowed to do, not who the user is. That’s where OpenID Connect (OIDC) comes in, adding authentication on top of OAuth 2.0 to verify user identity.

Because OIDC is built on OAuth 2.0, understanding OAuth first makes everything else clearer. That’s why we’ll begin by exploring OAuth 2.0 in detail.

OAuth 2.0 Flow Types For Different Use Cases

OAuth 2.0 defines different flows to handle different scenarios securely. In each scenario, the actors and their capabilities can vary, which is why there are different flows tailored to specific use cases.

In this article, we’ll focus on the Authorization Code flow (non-PKCE) because it demonstrates the core OAuth concepts most clearly.

Authorization Code Flow

The Four Key Players

Resource Owner (Your Friend): The user who owns the protected resources.
Client (You): The application requesting access on the resource owner’s behalf.
Authorization Server (City Hall): Authenticates the resource owner, client and issues signed access tokens.
Resource Server (Warehouse): Hosts the protected resources and verifies access tokens before granting access.

Client Registration And End-To-End Flow

Before the OAuth flow can even start, the Client app must be registered with the Authorization Server (like Google, Microsoft, etc.). Think of this as the client obtaining an official ID that proves who it is whenever it requests authorization.

During registration, the Authorization Server issues:

Client ID: A public identifier for your app (like a username for the app).
Client Secret: A private key for server-side authentication (like a password for the app that must be kept secret).
Redirect URI: The specific URL on the client app where the Authorization Server will send the user after authorization (like telling the Authorization Server, “After login, send them back here”).

As explained in the example above, the Authorization Code flow has two key phases:

The resource owner authenticates with the authorization server and grants permission to the client app.

Phase 2: Client Authentication & Token Exchange

The client app authenticates itself and exchanges the authorization code for the access token.

The authorization code issued by the Authorization Server simply represents the authorization granted by the resource owner to the client app.

But there’s a key problem: The authorization code doesn’t tell the client who the resource owner actually is.

In other words, OAuth alone doesn’t help the client app verify that the person using it is really the resource owner who granted the permission.

Why does this matter? → Because the client is acting on behalf of the user and it needs to be sure that the person interacting with it is indeed the same resource owner who gave that authorization. Otherwise, the client might present or act on sensitive user data for the wrong person. This is the gap that OpenID Connect (OIDC) solves.

OpenID Connect (OIDC): Adding Identity to OAuth

OIDC is a simple identity layer built on top of OAuth 2.0. It extends the OAuth flow by returning an ID Token alongside the Access Token. This ID Token contains information about the authenticated user. In other words:

OAuth 2.0 → Authorization (what can the app do?)
OpenID Connect → Authentication + Authorization (who is the caller user, and what can the app do on their behalf?)

In the next article(s), we’ll dive into how access tokens are actually implemented in real-world systems.

If you have any feedback on the content, suggestions for improving the organization, or topics you’d like to see covered next, feel free to share → I’d love to hear your thoughts!

Coder Legion - Recent posts tagged oidc

SAML vs OIDC vs OAuth: The 60-Second B2B Playbook

SAML vs OIDC vs OAuth: The 60-Second B2B Playbook

The 60-Second Decision Tree

Quick-Answer Comparison Table

1. Protocol Origins: Why Each One Exists

2. Token Formats: XML Verbosity vs JWT Portability

3. Transport and Flows

4. Discovery and Key Rotation: Where SAML Ages Badly

5. Enterprise vs Consumer Fit

6. Session Management and the Single Logout Nightmare

7. Provisioning: SCIM Is the Missing Piece

8. Tooling and Developer Ecosystem

Understanding OAuth 2.0 and OpenID Connect: A Step-by-Step Guide

Authentication and Authorization

The Limitations of Password-Based Logins (and Why OAuth/OIDC Exist)

User Experience Challenges

Security Threats

Storage and Management Burdens

Single Sign-On and Federated Login to the Rescue

OAuth 2.0 Intuition

OAuth 2.0: The Authorization Framework

OAuth 2.0 Flow Types For Different Use Cases

Authorization Code Flow

The Four Key Players

Client Registration And End-To-End Flow

Phase 1: Resource Owner Authentication & Consent

Phase 2: Client Authentication & Token Exchange

OpenID Connect (OIDC): Adding Identity to OAuth