How the OAuth 2.0 Authorization Code Flow Works in 2026

Authorization code plus PKCE is the 2026 default for user-facing apps. Here is exactly what happens when you click Login with Google, and why a single-use code plus a hashed proof beats sharing a password.

One account, many apps, no password sharing

The next time you click Login with Google on a third-party site, a quiet protocol is doing a lot of work. OAuth 2.0 is the industry-standard framework that lets an app access your data on another service without ever seeing your password. In 2026 the correct implementation for nearly every user-facing app is the authorization code flow, paired with PKCE (Proof Key for Code Exchange).

OAuth handles authorization (you, granting an app permission to act on your behalf). If the same protocol also needs to answer authentication — who are you? — developers layer on OpenID Connect by adding an openid scope. A common confusion: JWTs are a token format, not a replacement for OAuth; the tokens the flow returns are frequently JWTs, but the flow itself is what grants them.

The four roles

Resource owner — you, the human whose data is protected.
Client — the app you are using (web site, mobile app, desktop tool).
Authorization server — the identity provider (for example, the Google /authorize endpoint) that asks for your consent and issues tokens.
Resource server — the API that actually serves your data and accepts the access token.

The six steps of the code flow

The app redirects you to the authorization server's /authorize endpoint with its client_id and the scopes it wants.
The authorization server shows a login and consent screen; you approve.
The server issues a single-use authorization code and redirects it back to your app's redirect URI.
Your app exchanges the code at the /token endpoint — for server-side apps, along with a client_secret.
The server returns short-lived access tokens (and usually a longer-lived refresh token for silent renewals).
Your app attaches the access token to API requests; the resource server validates it and serves your data.

The indirection is the point. The authorization code is a short-lived, single-use ticket: nobody who intercepts your browser redirect gets a usable credential. The real exchange happens server-to-server, where a confidential backend can present its secret, so tokens never touch the browser at all. When access tokens expire, the refresh token quietly mints new ones without re-prompting you.

PKCE: proof that you started the flow

Single-page apps, mobile apps, and public desktop clients cannot keep a client_secret safely. That is where PKCE comes in: before the redirect, the app generates a random code_verifier and sends only its hash — the code_challenge — to the authorization server. Later, when exchanging the code for tokens, it presents the original verifier. The server checks that hash(verifier) matches the challenge. If someone steals the authorization code off your device or an open Wi-Fi network, the code is useless without the verifier that only the original client holds. PKCE is now mandatory for SPAs and strongly recommended everywhere, and the in-progress OAuth 2.1 effort is consolidating this de-facto standard into the spec.

What this means for you

Every time you Login with a third party, you should see a clear consent screen naming exactly what scopes are requested — and you can deny them. If an app asks for far more access than its features need, decline it: scopes are the whole permission model. And when a site's session quietly stays logged in for months, that is a refresh token doing its job — revoking it in your account's connected-apps settings breaks the chain, not just the current browser session.

Sources: OAuth 2.0 (oauth.net, IETF OAuth Working Group); Auth0 — What is OAuth 2.0?; Microsoft Learn — OAuth 2.0 authorization code flow.

Corrections: Report an error at corrections@wireshaman.com.