Understanding OAuth 2.0 and OAuth 2.1: A Guide to Secure Authorization in 2026
Every time you tap "Log in with Google" and hand over no password, you are watching OAuth 2.0 do its job: delegating limited access to an app without sharing your credentials. The draft OAuth 2.1 spec folds a decade of hard lessons into one standard. Understanding the flow — not the buzzwords — is what separates implementations that hold from implementations that leak.
Authentication is not authorization
Authentication proves who you are. Authorization decides what you may touch. OAuth handles the second; OpenID Connect adds the first on top by issuing an id_token. Most "login with X" buttons run both together, and conflating the two is where developers start going wrong.
A cast of four
The resource owner is you, the human with the data. The client is the app asking for access. The authorization server — Google's, for instance — issues the tokens. The resource server is the API actually holding your photos or files. Every flow below is just these four passing messages.
The authorization code flow, step by step
The workhorse of the modern web, and the only public flow worth building on:
- The client generates a random code_verifier and sends its SHA-256 hash — the code_challenge, method S256 — together with its client ID and requested scopes when redirecting your browser to the authorization server.
- You log in, ideally with a passkey, and approve a consent screen naming exactly what the app wants.
- The server redirects back with a one-time authorization code.
- The client redeems the code directly, presenting the original code_verifier. The server hashes it and compares it with the stored challenge; a match proves the same client that started the flow is the one finishing it.
That comparison is PKCE, and OAuth 2.1 makes it mandatory for every client, not just mobile apps. The old implicit flow, which leaked tokens through URLs and browser history, is dead — delete it wherever it lingers.
The rules that keep it safe
- Register and match redirect_uri exactly; wildcards are how authorization codes get stolen.
- Always send the state parameter, or the login is open to CSRF — in OpenID Connect, the nonce guards the token.
- Keep access tokens short-lived, rotate refresh tokens on every use, and store tokens server-side; browser localStorage sits one XSS bug away from account takeover.
- Trust an email claim only when the provider has verified it.
Use a mature library — openid-client for Node, Authlib for Python — or a hosted identity provider. Rolling your own client is how every rule above gets broken in a single afternoon.
The whole protocol rests on one premise: consent must be explicit, limited and revocable. Palestine is the starkest reminder of what happens when a people's consent is treated as decoration rather than foundation.
Delegation done right hands over the least authority needed — never the keys to everything. Travel paperwork works the same way: you authorise HTG Travels in writing to act on your visa file and flights, and that limited authority is all we hold. Your passwords, like your trust, stay yours.
