Identity Protocol · Security-First

The Protocol Behind
Every "Sign In With"
Button.

oidc.ms is the definitive resource for OpenID Connect — clear explanations, security best practices, and implementation guidance for authenticating humans, services, and AI agents the modern way.

ID Token Access Token PKCE JWKS Claims AI Agent Identity

id-token.decoder — live ✓ SIGNATURE VERIFIED

Raw JWT (eyJ…)

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6InNpZy1yc2EtMDEifQ.eyJzdWIiOiJ1c2VyXzQ4MjEiLCJpc3MiOiJodHRwczovL2lkcC5leGFtcGxlLmNvbSIsImF1ZCI6ImFwcC1jbGllbnQiLCJleHAiOjE3NTAwMDAwMDAsImlhdCI6MTc0OTk5NjQwMCwibm9uY2UiOiJhYmMxMjMiLCJlbWFpbCI6InVzZXJAZXhhbXBsZS5jb20iLCJuYW1lIjoiSmFuZSBEb2UifQ.SflKxwRJSMeKKF2QT4fw…

Header

alg"RS256"

typ"JWT"

kid"sig-rsa-01"

Payload · Claims

sub"user_4821"

iss"https://idp.example.com"

aud"app-client"

exp1750000000

iat1749996400

nonce"abc123"

email"user@example.com"

name"Jane Doe"

Signature valid · Issuer matched · Audience verified · Token not expired

// The Problem

The Most Misunderstood Lock
in Modern Security

OpenID Connect quietly authenticates billions of logins a day — yet it remains one of the most frequently misconfigured protocols in security. A single flawed redirect URI or unvalidated token can hand an attacker the keys to your application.

Open redirect URIs expose OAuth authorization endpoints to token hijacking, turning a working integration into an undetected vulnerability.

Missing state and nonce parameters leave applications wide open to CSRF and replay attacks on the authorization flow.

Implicit flow leftovers expose tokens in the browser URL — a legacy pattern that survives in production far longer than it should.

As AI agents begin authenticating alongside humans, mis-scoped tokens operate at machine speed with no one watching.

OIDC Misconfig · Active Threat Feed

LIVE

Open Redirect URI

Authorization endpoint exploitable

CRITICAL

Accepting wildcard or unbounded redirect URIs allows attackers to intercept authorization codes and tokens. Every redirect URI must be exact-matched and allowlisted at the authorization server. No exceptions.

Missing nonce Validation

ID token replay not prevented

CRITICAL

Without validating the nonce claim in ID tokens, a captured token can be replayed to authenticate as the victim. The nonce must be generated per-request, stored securely, and verified on every token response.

Implicit Flow Still Active

Tokens exposed in browser URL

HIGH

The implicit flow passes tokens directly in URL fragments, where they can be captured by referrer headers, browser history, or injected scripts. Migrate all implicit-flow integrations to Authorization Code with PKCE.

No Audience Validation

Tokens accepted from foreign issuers

HIGH

Failing to validate the aud claim allows tokens issued to other clients to be accepted. An attacker who obtains a valid token for any client of the same IdP can use it against applications that skip audience checks.

Agent Token Over-Scoping

Machine-speed access with broad permissions

MEDIUM

AI agents given broadly scoped tokens can act far beyond their intended mandate — and do so at automation speed. Each agent identity should carry the minimum claims needed for its specific task, with short expiry and explicit revocation paths.

// Capabilities

Everything You Need to
Implement OIDC Right

From protocol fundamentals to AI agent identity patterns — security-first guidance for every layer of modern authentication.

Plain-Language Protocol Guides

ID tokens, access tokens, claims, scopes, issuers, audiences — the building blocks of OIDC explained clearly, with diagrams of every major flow from Authorization Code + PKCE to client credentials.

Security Best Practices

The mistakes that turn OIDC into a vulnerability — open redirect URIs, missing state and nonce, weak token validation, implicit-flow leftovers — and exactly how to avoid each one.

Token Validation Deep Dives

Signature verification, issuer and audience checks, expiry and clock skew, key rotation via JWKS — the complete checklist for trusting a token without taking it on faith.

OIDC for AI Agents

How the protocol is being extended to give AI agents verifiable identities: agent-issued tokens, scoped delegation, and the patterns emerging for agent-to-service and agent-to-agent authentication.

Provider Configuration Guides

Hands-on walkthroughs for configuring OIDC correctly with Entra ID, Okta, Auth0, Google, and self-hosted options — highlighting each one's defaults and gotchas.

Reference Implementations

Annotated, security-reviewed example integrations you can study and adapt — instead of copying the first code snippet a search engine offers.

// Process

From Protocol Theory to
Production-Grade Practice

A structured path from conceptual understanding to a hardened implementation. Click any step to explore the details.

01 ——

Understand

What OIDC adds on top of OAuth 2.0 and why ID tokens changed federated login.

oidc.concepts

02 ——

Choose

Pick the right flow for your scenario — web app, SPA, M2M, or AI agent.

flow.selector

03 ——

Implement

Provider walkthroughs and reference implementations to build it correctly first time.

provider.guides

04 ——

Harden

Run the security checklist: token validation, redirect hygiene, key rotation, session management.

security.checklist

Understand the Protocol Foundation

Start with the conceptual guides: what OpenID Connect adds on top of OAuth 2.0 and why the ID token was the piece that made federated login truly work.

OAuth 2.0 authorizes access — OIDC establishes identity via the ID token
The ID token is a signed JWT issued by the authorization server, not the resource server
Claims in the ID token are assertions about the authenticated subject
The UserInfo endpoint provides additional claims beyond what fits in the token

// OAuth 2.0 vs OIDC

OAuth 2.0 → answers "what can you access?"

OIDC → answers "who are you?"

// ID Token structure (JWT)

header: { alg, typ, kid }

payload: { sub, iss, aud, exp, iat,

nonce, email, name, ... }

sig: RS256-signed by IdP private key

// Discovery endpoint

GET /.well-known/openid-configuration

Choose the Right Flow for Your Scenario

Clear decision guidance for every use case — web app, SPA, native app, machine-to-machine, or AI agent. The wrong flow is a security misconfiguration, not just a technical choice.

Web app with server backend → Authorization Code + PKCE
SPA or mobile app → Authorization Code + PKCE (no client secret)
Service-to-service / M2M → Client Credentials with scoped tokens
AI agent → Client Credentials or agent-specific token delegation
Implicit flow → retired; migrate to PKCE everywhere it survives

// Flow decision matrix

user-facing web app

→ Auth Code + PKCE

SPA / mobile

→ Auth Code + PKCE (public client)

service / daemon / AI agent

→ Client Credentials

implicit flow

→ ⚠ DEPRECATED — migrate now

Implement Correctly the First Time

Follow the provider-specific walkthroughs and annotated reference implementations. Build on security-reviewed patterns — not on the first code snippet a search returns.

Entra ID, Okta, Auth0, Google — each with specific gotchas flagged
Self-hosted options: Keycloak, Dex, and standards-compliant alternatives
Annotated code examples in the languages your team actually uses
Common integration pitfalls identified and corrected before they ship

// PKCE code exchange (simplified)

code_verifier = random(43..128 chars)

code_challenge = base64url(SHA256(verifier))

// Authorization request

GET /authorize?

response_type=code

&code_challenge={challenge}

&code_challenge_method=S256

&nonce={cryptographic_random}

Harden Against the Real Attack Surface

A working OIDC integration is not a secure one until it's been through the full validation checklist. Security is in the validation, not the handshake.

Verify the JWT signature against the JWKS endpoint — always, on every token
Validate iss, aud, exp, and nonce on every ID token received
Implement redirect URI exact-matching — no wildcards, no prefixes
Handle JWKS key rotation without downtime using kid-based lookup

// Token validation checklist

✓ Fetch JWKS from /.well-known/jwks.json

✓ Match kid from token header to JWKS key

✓ Verify RS256/ES256 signature

✓ Check iss === expected issuer URL

✓ Check aud contains your client_id

✓ Check exp > now (allow ≤60s clock skew)

✓ Check nonce matches your stored value

⚠ Never skip any of the above

// Use Cases

Where oidc.ms Applies

Single Sign-On on a Foundation That Actually Holds

Roll out SSO across your applications on correctly validated ID tokens — not on an integration that merely works until someone probes it. oidc.ms gives teams the knowledge to build SSO that's secure by default, not secure until proven otherwise.

ID Token ValidationAuth Code + PKCESession ManagementRedirect Hygiene

→ User: clicks "Sign in with Entra ID"
↳ App: generates code_verifier + nonce
→ IdP: authenticates user, returns code
↳ App: exchanges code for ID + access tokens
→ Validate: sig · iss · aud · exp · nonce
↳ All checks pass → session established
✓ User authenticated — zero shared secrets

Service-to-Service Auth With Auditable, Short-Lived Credentials

Use the client credentials flow and scoped tokens to authenticate service-to-service calls — replacing long-lived API keys with short-lived, auditable credentials that can be revoked without a config change.

Client CredentialsScoped TokensShort-Lived CredentialsAudience Validation

→ Service A: requests token from IdP
↳ grant_type: client_credentials
↳ scope: api:read api:write
→ IdP: issues access token (15 min TTL)
↳ aud: "service-b", scopes: ["api:read"]
→ Service B: validates token, serves request
✓ Attributable · revocable · no API keys

Verifiable Identity for Every AI Agent Action

Issue agents their own OIDC identities with tightly scoped claims, so every agent call is attributable, revocable, and bounded by policy — not running under a shared service account that no one can audit.

Agent Client IdentityScoped DelegationToken RevocationRFC 9068

→ Agent: authenticates as agent-47@pipeline
↳ client_id: "agent-47", grant: client_creds
→ IdP: issues narrowly scoped token
↳ scope: "docs:read" · exp: +300s
↳ sub: "agent-47" · aud: "docs-api"
→ API: validates + logs agent identity
✓ Attributable · scoped · revocable

// Audience

Built for Everyone Who
Touches Authentication

Developers Integrating Login

Get it right, not just get it working. Annotated implementations and flow decision guides mean your integration is secure by design from the start.

Security Engineers

Review OIDC implementations against a complete weakness taxonomy — every common misconfiguration documented with its precise impact and fix.

Architects

Design identity for applications, APIs, and agent ecosystems with the full protocol picture — including where OIDC ends and authorization policy begins.

Teams Modernizing Auth

Migrating off legacy authentication toward modern federation. Clear migration paths and before/after comparisons for every legacy pattern still running in production.

// Comparison

Auth Flows at a Glance

Which flow is right for your scenario — and which ones to retire today.

Flow	Use Case	Client Secret	PKCE Required	Token in URL	Recommended
Auth Code + PKCE	Web, SPA, Mobile	Optional	Yes	No	✓ 2026 Standard
Client Credentials	M2M / AI Agents	Yes	N/A	No	✓ Recommended
Auth Code (legacy)	Server-side apps	Yes	Partial	No	Migrate to PKCE
Implicit	SPAs (legacy)	No	No	Yes	✗ Retire Now
Hybrid	Server + SPA	Yes	Optional	Partial	Context-dependent
Device Code	CLI / TV / IoT	Optional	N/A	No	✓ For device flows

// FAQ

Common Questions

OAuth 2.0 is an authorization framework — it answers what you can access. OpenID Connect is a thin identity layer on top of it — it answers who you are, via the ID token. Most modern "login with" experiences are OIDC running over OAuth 2.0. You need both; OIDC doesn't replace OAuth, it extends it.

For nearly all user-facing apps: Authorization Code with PKCE. For machine-to-machine and agent scenarios: client credentials with tightly scoped tokens. The implicit flow is legacy and should be retired wherever it survives. If you're unsure, oidc.ms includes a flow decision guide with worked examples for each scenario.

Yes — the pattern is maturing fast. Agents receive their own client_id and short-lived, narrowly scoped tokens, making their actions attributable and revocable. The critical discipline is tight scoping: an agent with a mis-scoped token operates at machine speed. oidc.ms tracks the emerging standards and shows working patterns for agent-to-service and agent-to-agent authentication.

Yes. The protocol guidance is standards-based and applies regardless of provider. The provider walkthroughs cover Entra ID, Okta, Auth0, Google, and self-hosted options even-handedly — flagging each one's specific defaults and pitfalls without advocating for any vendor.

A lock installed wrong is worse than no lock — it creates false confidence. OIDC is the authentication layer for most modern applications; a misconfiguration at this layer isn't an edge case, it's a front-door vulnerability. Common issues like open redirect URIs, unvalidated nonces, and missing audience checks each have well-documented exploitation paths. The cost of getting it right once is far lower than the cost of a breach.

The Protocol BehindEvery "Sign In With"Button.

The Most Misunderstood Lockin Modern Security

Everything You Need toImplement OIDC Right