Never hand over
the password.

OAuth 2.0 exists to answer one question: how can I let an app do something on my behalf at another service without giving it my password? Handing over credentials would be a disaster — the app could do anything, forever, and you couldn't revoke it without changing your password everywhere. OAuth replaces that with delegated authorization: you authenticate directly with the provider (Google, GitHub), approve a specific, limited scope, and the provider hands the app a token — a key to one room, not the master key.

The token is scoped (only what you approved — "read calendar," not "delete account"), short-lived, and revocable (you can cut it off without touching your password). That's the whole value proposition: your credentials never leave the provider, and the access you grant is narrow and reversible. But getting that token to the app safely, through the untrusted medium of a browser redirect, is where the real design lives — and where the security is won or lost.

The standard, most secure path is the authorization code flow. Its defining trick is that what travels through the browser is not the token — it's a short-lived authorization code that's useless on its own. Turning that code into a token requires a separate back-channel request the browser (and any attacker watching it) can't make.

Two things never appear in a browser URL: your password (you type it into the provider, not the app) and the access token (it's only ever returned over the back channel in step 4). The code does ride through the browser, which is exactly why it must be short-lived, single-use, and — as the next section shows — bound to a secret the attacker can't have. Split the flow into "get a code publicly, redeem it privately" and the browser leg carries nothing an attacker can use alone.

Two parameters defend the two ways the browser leg can be attacked. state is a random value the app generates before the redirect and checks is echoed back unchanged. If the returned state doesn't match what the app sent, the response belongs to a flow the app never started — a forged authorization response — and it's rejected. That's CSRF protection: an attacker can't trick your browser into completing their login into your session, because they can't guess your state.

PKCE (Proof Key for Code Exchange, "pixie") defends against a stolen code. Before redirecting, the app generates a random verifier and sends only its hash — the challenge — to the provider. At exchange time (step 4), the app must present the original verifier; the provider re-hashes it and rejects the exchange unless it matches the challenge it stored. So even if an attacker intercepts the authorization code, they can't redeem it: they'd need the verifier, which never left the app. State proves the response is yours; PKCE proves the redemption comes from the same app that started the flow. Together they make a code that flies through an untrusted browser safe to use.

PKCE binds the code to a secret via a one-way hash: the challenge is the hash of the verifier, and the exchange re-derives it and compares. A token is issued only if the state matches and the verifier hashes to the challenge:

The challenge is public (it rode through the browser); the verifier is secret. Because SHA-256 is one-way, seeing the challenge doesn't reveal the verifier — so a stolen code can't be redeemed.

Break either check and no token is issued — a mismatched state (forged response) or a wrong verifier (stolen code without the secret) both fail closed:

Two independent gates, both must pass. The runnable version below derives the challenge, checks state, verifies PKCE, and runs the full exchange for valid and attacker cases.

The single most common confusion in this space is treating authentication and authorization as the same thing. They aren't. Authentication (authn) is proving who you are — verifying identity with a password, passkey, or biometric. Authorization (authz) is deciding what you may do — whether an already-identified user can perform a given action. You authenticate once; you're authorized (or not) for each thing you try.

Plain OAuth 2.0 is an authorization protocol — it grants scoped access via tokens; it does not, by itself, tell the app who you are. That's what OpenID Connect (OIDC) adds: a thin identity layer on top of OAuth that issues an ID token (a signed JWT) proving who authenticated. "Sign in with Google" is OIDC — OAuth's access grant plus an identity assertion. Keep the two straight and the ecosystem stops being a soup of acronyms: OAuth hands out access, OIDC adds identity, tokens carry both across requests so the server doesn't have to keep server-side session state. Confuse them and you'll build systems that authenticate but don't authorize (everyone's an admin) or authorize without authenticating (anonymous access to private data) — both classic breaches.

The first is skipping state or PKCE because "it works without them." It does work — right up until someone forges a response or steals a code. Both parameters are cheap and both are now mandatory in the current best-practice (OAuth 2.1 bakes PKCE into every flow). The second is the deprecated implicit flow, which returned the token directly in the browser URL. It exists in old tutorials; don't use it — the authorization-code flow with PKCE replaces it precisely because a token in a URL is a token in browser history, referer headers, and logs.

Three more. Not validating tokens: a server that accepts a token without checking its signature, issuer, audience, and expiry will accept forged or stolen ones — always verify, don't just decode. Wide scopes and no expiry: request the least scope you need and keep access tokens short-lived (use refresh tokens to renew), so a leaked token is both limited and temporary. And leaking tokens: a token is a bearer credential — whoever holds it is you — so treat it like a password: never log it, never put it in a URL, store it carefully (httpOnly cookies over localStorage where you can). Get the flow right — code not token in the browser, state and PKCE always on, tokens validated, scoped, and short-lived — and OAuth does something genuinely elegant: it lets strangers act for you, exactly as much as you allowed, and never a bit more. The whole handbook is that sentence: delegate access, never the password, and guard the code with state and PKCE.