Chapter 3: Core Concepts — The Vocabulary of OpenID Connect

This is Part 3 of a chapter-by-chapter walkthrough of my book OpenID: Modern Identity for Developers and Architects. In the previous chapter we traced how the industry moved from the original OpenID and SAML through OAuth 2.0 to OpenID Connect — and why the access-token-vs.-ID-token distinction is the pivot the whole protocol swings on. Now we install the vocabulary.

Chapter 3 is the map. Before you can reason about flows, tokens, federation, or threat models, you need a clean mental picture of the actors, the artifacts they exchange, and the boundary of responsibility between them. Almost every identity bug I've investigated in the wild traces back to a misreading of one of these three things.

3.1 — The Three Actors: IdP, RP, and the User

OpenID Connect is built on a triangle. The Identity Provider (IdP) knows about users and can authenticate them — Google, Microsoft, Okta, your corporate IdP. The Relying Party (RP) is the application that wants to authenticate users — your website, your mobile app, your internal tool. The Resource Owner is the user themselves.

The trust arrows in this triangle matter. Users trust the IdP with their credentials. RPs trust the IdP's signed tokens — not the IdP as an entity, but the cryptographic proof on what it issues. And the IdP, critically, does not know what the user is allowed to do inside the RP. That's the RP's job. Keeping these roles cleanly separated is what prevents the most common class of identity bugs.

Confidential vs. Public Clients (and Why It's Not a Preference)

Inside the RP role, the spec further splits clients into two kinds. A confidential client is one that can keep a secret — a server-side app on infrastructure you control. A public client is one that cannot — a JavaScript SPA, a mobile app distributed to thousands of devices. Any "secret" shipped inside a public client is not a secret.

This classification decides which OAuth 2.0 flows are even available to you. Picking the wrong one isn't a style choice; it's a vulnerability. Chapter 3 walks through the decision and Chapters 7–9 apply it to real apps.

3.2 — Claims, Tokens, and the JWT

A claim is a single piece of information about a user — email, name, sub (the user's unique identifier at the IdP), and so on. Claims do not travel alone. They are packaged into tokens, and in OpenID Connect the packaging format is the JSON Web Token (JWT).

A JWT is three dot-separated parts: a header that names the signing algorithm, a payload of claims, and a signature over the first two. The signature is what makes a JWT trustworthy — it proves the token came from whoever holds the matching key (the IdP) and that nobody has modified it since.

OpenID Connect uses three token types, and the most important thing a developer can learn in this chapter is which is which:

• ID Token — a signed JWT about who the user is. Intended for the RP to read and verify. Not a bearer key for APIs. Short-lived.
• Access Token — a credential for what the holder can do, used against resource servers and the UserInfo endpoint. Often an opaque string, not a JWT — and that's by design.
• Refresh Token — a long-lived credential the RP uses to get a new Access Token without re-authenticating the user. High-value; must be stored and transmitted carefully.

3.3 — Consent: The Part of the Protocol That Is Actually About People

Every time you see "TheWebsite.com wants access to your email and profile," you're looking at OpenID Connect's consent model made visible. Technically it's implemented through scopes — openid, email, profile, phone, and domain-specific extensions. The RP asks for scopes; the IdP surfaces them to the user; the user approves or denies.

This is one of the few places in a technical spec where the right engineering decision and the right ethical decision are the same: request the minimum scopes you need. It aligns with GDPR and CCPA expectations. It also builds user trust, which compounds across every "Sign in with…" button on the internet. Applications that over-request erode trust not just in themselves but in the entire federated identity ecosystem.

3.4 — Sessions vs. Tokens (and Why Most Real Systems Use Both)

Once the IdP has authenticated the user and your RP has validated the ID Token, you face a design question: how do you keep the user logged in on subsequent requests?

The two classical answers are sessions (a server-side record keyed by a cookie) and tokens (a signed JWT the client carries with every request). Sessions are revocable, stateful, and friendly to web apps but painful to scale across servers and awkward for mobile apps and SPAs. Tokens are stateless, scale beautifully, and match the grain of modern APIs — but they're immutable until expiry, revocation is tricky, and anything you put in them is visible to anyone who can read a JWT.

Chapter 3 walks through the tradeoffs in detail. The short version: most production systems end up hybrid — ID Token verified on login, short-lived Access Token for API calls, Refresh Token for rotation, and some backend state for revocation and audit. Pure-stateless and pure-session are both idealizations; shipping systems live in between.

3.5 — The Boundary of Responsibility

If you remember one section from this chapter, make it this one. The IdP is responsible for authenticating the user, storing credentials safely, issuing signed tokens, and enforcing consent. The RP is responsible for validating those tokens (signature, expiry, audience, issuer), maintaining application session state, and — this is the one that trips teams up — making authorization decisions.

The IdP has no idea what your application's roles, features, or permissions are. "The user is authenticated" does not mean "the user may delete this record." Any code that collapses those two statements into one is a future incident, and the book is full of real-world examples of exactly that mistake.

The other half of this boundary is trust direction. RPs must validate what comes from the IdP cryptographically, and they must never trust identity claims that come directly from the client without going through that validation. An Authorization header that says "I am admin" is not evidence. The signed ID Token backing it is.

What Chapter 3 Sets Up

By the end of this chapter you should be able to draw the IdP/RP/User triangle from memory, name the three tokens and what each is for, explain what a scope is, pick between session-based and token-based auth with intention, and say — in one sentence — where the IdP's job ends and yours begins. Everything in Parts II–VII is built on these concepts.

Next up — Chapter 4: Protocol Overview and Flows. We leave conceptual territory and start tracing actual protocol exchanges: actors and roles on the wire, the Authorization Code Flow, PKCE, Client Credentials for machine-to-machine, CIBA and Device Flow for constrained clients, and why Implicit/Hybrid flows are now mostly of historical interest. If Chapter 3 is the map, Chapter 4 is the first time we walk the territory.