OAuth, decoded.
In one scroll_

Why we needed OAuth in the first place

Before OAuth, if a third-party app wanted to read your Gmail or post to your Twitter, you had to give it your password. That meant any random calendar integration could now log in as you, change your password, and read your DMs forever. That is the era OAuth ended.

The four roles in every OAuth flow

Every OAuth conversation has exactly four players. Memorize these and the rest of OAuth snaps into focus.

Fun fact: the Authorization Server and the Resource Server can be the same machine — they're roles, not necessarily separate servers. At Google they're different teams; at a small startup they may live in the same Express app.

Which OAuth flow should I use?

OAuth 2 has several "grant types" (a.k.a. flows). Most of them are obsolete in 2026. Answer the questions below — we'll tell you which one you actually need.

Authorization Code flow, step by step

This is the flow you'll use 95% of the time. The animation below walks through every hop. Click Next step to advance — watch the messages move between the four roles.

Try PKCE live — your browser, real crypto

PKCE ("pixy" — Proof Key for Code Exchange) stops attackers who steal the authorization code from being able to redeem it. Your client invents a secret (code_verifier), hashes it (code_challenge), sends the hash up-front, and reveals the original secret only at token exchange. No verifier? No token.

This panel runs the same SubtleCrypto SHA-256 your real client would. Hit generate and watch.

Access, Refresh, ID — which is which?

Decode a JWT yourself

Most ID tokens and many access tokens are JWTs — three base64url chunks separated by dots. Paste one below (or try a sample) to see the header, payload, and signature. Nothing leaves your browser.

—

—

—

The well-known URLs you'll see everywhere

Authorization servers expose a small, standardized set of endpoints. Once you know their names, every provider — Google, GitHub, Auth0, Cognito, your homegrown one — looks the same.

{
  "issuer": "https://accounts.google.com",
  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
  "token_endpoint":         "https://oauth2.googleapis.com/token",
  "userinfo_endpoint":      "https://openidconnect.googleapis.com/v1/userinfo",
  "jwks_uri":               "https://www.googleapis.com/oauth2/v3/certs",
  "response_types_supported": ["code", ...],
  "scopes_supported":         ["openid", "profile", "email", ...],
  "code_challenge_methods_supported": ["plain", "S256"]
}

Scopes are how you say "only this much"

Scopes are space-separated permission strings the client requests at /authorize. The user sees them on the consent screen ("This app wants to read your email and post on your behalf"). Pick scopes below and watch the request build.

The security gotchas (and how to dodge them)

Most OAuth bugs aren't in OAuth — they're in how people implement it. Here are the classics that the OWASP and Auth0 security teams keep finding in the wild.

OAuth vs OIDC vs SAML — what's the difference?

The single most-asked OAuth question. Short version: OAuth is authorization (what the app can do). OIDC and SAML are authentication (who the user is). OIDC is a thin layer built on OAuth.

Prove it.

10 questions. No timer. Each one has an explanation so even when you miss one, you learn.

OAuth glossary you can pin to your monitor

Authorization Code code

A short-lived (typically <60s) opaque string returned to the client's redirect URI. Useless on its own — must be exchanged at /token.

Access Token AT

The credential a client presents to a resource server in the Authorization: Bearer header. Short-lived (minutes to ~1h).

Refresh Token RT

Long-lived credential sent only to the authorization server to get fresh access tokens without re-prompting the user.

ID Token IDT

OIDC-only JWT containing claims about the authenticated user. Tells the client who logged in.

PKCE RFC 7636

Proof Key for Code Exchange. A SHA-256 hash dance that prevents auth-code interception attacks. Mandatory in OAuth 2.1.

State Parameter state

Random per-request value the client sends to /authorize and verifies on the callback. CSRF defense.

Nonce OIDC

Like state but for the ID Token. Sent at /authorize, echoed in the token's nonce claim. Prevents token replay.

Scope scope

Space-separated permission string. What the user consents to and what the resulting token can access.

Front-channel

Communication that goes through the user's browser (URL redirects, fragments). Visible to JS, logged by browsers.

Back-channel

Server-to-server HTTPS POST. Not visible to the user or the browser. Where secrets and tokens belong.

JWKS jwks_uri

JSON Web Key Set — the public keys you use to verify a JWT's signature. Fetched from the provider's discovery document.

Confidential vs Public client

Confidential = can keep a secret (server-side app). Public = cannot (SPA, mobile, CLI). Public clients must use PKCE; confidential ones authenticate with client_secret too.

BFF (Backend-for-Frontend)

Pattern where a small server-side proxy holds the tokens and issues only HttpOnly session cookies to the browser. Best practice for SPAs in 2026.

DCR RFC 7591

Dynamic Client Registration. Lets clients register themselves with the authorization server at runtime. Used by MCP, IDE plugins, etc.