Chapter 2: From OpenID to OpenID Connect — How the Industry Got This One Right

This is Part 2 of a chapter-by-chapter walkthrough of my book OpenID: Modern Identity for Developers and Architects. In the previous chapter we argued that identity is a trust problem first and a technology problem second — and that the password era's mental model is still contaminating how modern systems reason about login. Chapter 2 takes that argument and turns it into a history lesson.

The story of how we got to OpenID Connect is not a clean progression. It's a story of false starts, abandoned standards, and one crucial conceptual mistake — conflating authentication with authorization — that the industry had to make at scale before anyone could see clearly enough to fix it.

The standard that quietly took over the internet

Every "Sign in with Google / Apple / GitHub / Microsoft" button you've ever clicked is powered by the same protocol. That protocol is OpenID Connect, published in early 2014. It did not arrive out of nowhere. It is the synthesis of roughly a decade of failed experiments, and it succeeded for one simple reason: it was the first protocol that got the separation of concerns right.

Chapter 2 traces how we got there — through the original OpenID, through SAML, and through OAuth 2.0 — and why none of those predecessors could carry the modern web on their own.

2.1 — Early OpenID: A Beautiful Idea That Users Rejected

The original OpenID protocol, released in the mid-2000s, had an engineer's kind of elegance. Your identity was a URL. Instead of registering a new account on every service, you'd type in something like https://yourname.myopenidprovider.com/, and the service would contact that URL to verify you.

It was decentralized. It was clever. It was also incomprehensible to normal users. People don't reason about themselves as URLs. Service providers also couldn't get reliable information out of it — email, display name, profile picture were all optional extensions that different providers implemented differently, so relying parties couldn't build a consistent experience. Add in some real security problems in the protocol itself, and OpenID 1.x never made it out of niche adoption. By the early 2010s it was effectively dead.

But its lessons directly shaped what came next: users need a simple mental model, services need standardized identity claims, and the protocol has to be hard to implement incorrectly.

2.2 — Why First-Generation Federation Couldn't Scale to the Public Internet

OpenID wasn't alone. SAML, especially in its 1.x and early 2.0 incarnations, ran into the same ceiling from a different direction. SAML is genuinely powerful — it is still the backbone of enterprise SSO today — but it was designed for a world where the identity provider and the relying party already know each other. Pre-configured relationships. XML signatures and assertions. Server-side applications behind enterprise networks.

None of those assumptions hold on the open internet. Consumer providers like Google need to work with millions of apps they've never met. JavaScript SPAs and mobile apps can't safely hold long-term secrets. And the first-generation protocols consistently blurred authentication and authorization into the same message, which made them awkward to extend in either direction.

2.3 — OAuth 2.0: The Right Answer to a Different Question

OAuth 2.0 was not trying to solve login. It was trying to solve something much narrower and, it turns out, much more important: delegated access.

The canonical example is the photo editor. You have photos on Flickr. You want a third-party editing service to access them. You absolutely do not want to give that service your Flickr password. OAuth 2.0 lets you authorize the service to receive a token — a scoped, revocable credential — that grants access to exactly the resources you approved, and nothing more.

OAuth 2.0 succeeded because it matched the grain of the modern internet. It assumed browser redirects, not back-channel handshakes. It worked for clients that couldn't keep secrets. It was simple enough that developers could ship it correctly without being security experts. Within a few years, every major service was using it.

2.4 — Why OpenID Connect Changed Everything

OpenID Connect arrived in early 2014 with one key insight: authentication and authorization are different problems, but they don't have to use different protocols. OIDC takes OAuth 2.0 — already deployed everywhere — and adds an authentication layer on top.

The central addition is the ID Token. Where OAuth 2.0 hands you an access token (for reaching resources), OIDC also hands you an ID Token: a cryptographically-signed JWT that makes standardized claims about the user — sub, email, name, and more — and is explicitly not a bearer key for APIs. It is an identity assertion. It is signed. It expires in minutes. It is verified by the relying party.

Combined with the standardized /userinfo endpoint and consistent claim names, this single design choice is what made "Sign in with X" work across providers without custom code per vendor. Chapter 2 walks through the specific constraints OIDC added on top of OAuth 2.0 to keep it secure — transport, token lifetimes, back-channel exchange — and why each one exists.

2.5 — When to Use SAML vs. OAuth 2.0 vs. OpenID Connect

If OIDC is so good, why do SAML and OAuth 2.0 still exist? Because they were designed for different problems, and that hasn't changed.

Chapter 2 works through this as a decision matrix, but the short version is: reach for SAML when you're integrating with enterprise IT that already speaks SAML (you don't get a vote — their IdP does); reach for OAuth 2.0 when you're delegating access to resources and authentication is somebody else's job; reach for OpenID Connect when you're building login on the modern web, especially for consumer or mixed audiences. Real systems often support both OIDC and SAML simultaneously, and that's not a design failure — it's the industry telling you that no single protocol owns every context yet.

2.6 — Today's Identity Landscape

The 2026 landscape is OpenID Connect plus OAuth 2.0 in front, SAML still anchored deep in enterprise, and a growing layer of hardening conventions on top: PKCE for public clients, strict HTTPS, additional defenses against state injection and redirect abuse. Passkeys, "Sign in with Apple," and privacy regulations like GDPR and CCPA are all evolving on top of or alongside OIDC rather than replacing it — which is, itself, a sign that OIDC got the bones right.

The chapter closes by noting that the move from centralized, password-based authentication to federated, standards-based identity is now entrenched — but the ecosystem is fragmenting around proprietary extensions, implementations keep producing new CVEs, and the threat model (token theft, account takeover, session hijack) keeps shifting. Understanding how we got here is what makes the rest of the book possible.

What Chapter 2 Sets Up

By the end of Chapter 2 you should be able to explain, in one minute, why OpenID Connect exists, what OAuth 2.0 does and does not do, and why SAML is still in the picture. You should also never again confuse "the user presented a valid access token" with "the user is authenticated." That distinction is the hinge everything else in the book swings on.

Next up — Chapter 3: Core Concepts. Now that we've traced the history, we slow down and install the vocabulary: Identity Providers and Clients, claims and tokens, consent, sessions vs. tokens, and the boundaries of responsibility between the parties. If Chapter 2 is the story, Chapter 3 is the map you'll use to navigate the rest of the book.