OIDC learning guide

Learn OIDC from the authorization request to token validation.

Trace Authorization Code with PKCE in plain language, with the claims, endpoints, and official references needed to verify an implementation.

OIDC flow at a glance

Authorization requestActor: RPDirection: RP to OP through the browserChannel: front-channelPurpose: Requests authentication with redirect, scope, state, nonce, and PKCE parameters.
Authentication and consentActor: OPDirection: Browser and OPChannel: front-channelPurpose: Authenticates the end user and applies the requested interaction and consent policy.
Authorization code responseActor: OPDirection: OP to RP through the browserChannel: front-channelPurpose: Returns the authorization code and correlation state to the registered redirect URI.
Token request and responseActor: RPDirection: RP to OP and backChannel: back-channelPurpose: Redeems the code with the PKCE verifier and receives tokens directly from the token endpoint.
ID Token validationActor: RPDirection: At the RPChannel: back-channelPurpose: Verifies signature, issuer, audience, time, subject, and nonce before creating a session.

Current guide

OIDC learning paths

Browse every chapter, or choose a goal to follow a shorter ordered route.

Learning modeGuided pathFull protocol reference

Guided paths

Start hereBuild the protocol model, follow Authorization Code with PKCE, and finish with ID Token validation.Understand the flowTrace the browser request, authorization response, token exchange, and resulting token contexts.Configure a requestSelect redirect, interaction, freshness, assurance, locale, and claims request parameters.Validate a responseValidate the authorization response, exchange the code, verify the ID Token, and interpret claims.Debug a failureDiagnose discovery, redirect, correlation, code exchange, key, claim, and provider errors.Perform a security reviewReview redirect handling, request correlation, PKCE, token validation, key rotation, and hardened profiles.

Start hereStep 1 of 9

Learn the OIDC roles, OAuth relationship, issuer model, discovery, and client identity basics.

Follow an authorization request, PKCE protection, browser response, and code exchange.

Use standard request parameters to influence interaction, freshness, assurance, and requested claims.

Distinguish token purposes, validate ID Tokens, resolve keys, process claims, and troubleshoot safely.

Understand RP-initiated logout, notification channels, and browser session monitoring.

Explore registration, protected requests and responses, financial-grade profiles, back-channel authentication, and historical flows.

Protocol foundationsCore lesson2 min readStart here · 1 of 9

Reference only

Roles and terminology

OIDC names the identity participants precisely: an End-User authenticates at an OpenID Provider, and a Relying Party consumes the result.

What it is

An OpenID Provider (OP) is an OAuth 2.0 Authorization Server that can authenticate an End-User and return Claims. A Relying Party (RP) is the OAuth 2.0 Client that requests that authentication.

Why it matters

Clear role names prevent a common design error: treating an ID Token as an access token, or treating an RP as the resource server that ultimately accepts an access token.

How it works

The End-User starts sign-in at the RP in the RP-initiated flow covered deeply by this guide.
The RP sends an Authentication Request through the browser to the OP's Authorization Endpoint.
The OP authenticates the End-User and, after the code exchange, issues an ID Token to the RP.
A resource server is a separate OAuth role that accepts an access token for an API; it does not consume the ID Token as proof of API authorization.

Options available

An Authorization Server that implements OIDC is also called an OpenID Provider.
An OAuth Client using OIDC is also called a Relying Party.
The same deployed system can host several roles, but each protocol message still has one intended issuer, audience, and recipient context.

What the official specification says

OIDC Core Sections 1.2 and 1.3 define the capitalized roles and the abstract exchange. Keep those definitions intact when mapping them to product-specific names.

Security and interoperability notes

Decide which component validates each token before implementation; sending a valid token to the wrong kind of recipient is still a protocol error.
Do not infer authorization from the fact that the OP authenticated the End-User.

Workbench support