OAuth From Zero

Start here

Authorization Code + PKCE, step by step

JayP wants Print Express to read Google Drive files. Read the picture by following the moving credential: password stays at Google, code returns to Print Express, token goes to the Drive API.

Password

Stops at Google

Code

Passes through browser

Token

Unlocks the API

ResetPrevPlayNext

Step 1 / 12

Interactive scene

Click a step. Watch the authorization code become an access token, then unlock the API.

1Resource Owner initiates authorization2Client prepares state and PKCE values3Client sends Authorization Request4Authorization Server authenticates the user5Authorization Server obtains consent6Authorization Server returns an authorization code7Client validates state and redirect_uri8Client sends Token Request9Authorization Server issues tokens10Client calls Resource Server with Bearer token11Resource Server validates token and responds12Client refreshes the access token

Resource Owner to Client

Resource Owner initiates authorization

JayP clicks "Connect Google Drive" in Print Express. In OAuth terms, JayP is the Resource Owner, Print Express is the Client, and the browser is the User-Agent.

Plain English

Resource Owner communicates with Client.

The first arrow is just the user intent: JayP asks Print Express to connect Drive.

Front-channel: the User-Agent is redirected through the browser.

Show technical details

client_idredirect_uriscope

Other OAuth flows

User-facing login usually uses Authorization Code + PKCE. Service-to-service jobs use Client Credentials because there is no Resource Owner or User-Agent redirect.

Authorization Code + PKCEClient Credentials

Which setup do I have?

App type	Secret?	Flow	Why
Website with a backend	Can keep secrets	Authorization Code	The backend can keep a client secret and exchange the authorization code server-side
Browser-only app	Cannot keep secrets	Authorization Code + PKCE	Browser code cannot keep a client secret, so PKCE protects the authorization code exchange
Mobile or desktop app	Cannot keep secrets	Authorization Code + PKCE	Installed apps cannot keep a client secret, so PKCE is required
Backend service	Can keep secrets	Client Credentials	There is no Resource Owner; the service authenticates as itself
TV or CLI	Usually cannot keep secrets	Device code	The user finishes login on another device with a real browser

Use Next to walk through the story. The advanced details are there when you want them.

How to read the picture

JayP wants Print Express to read photos in Google Drive. The safety rule is visible in the diagram: JayP’s password stops at Google, while Print Express only handles short-lived OAuth artifacts.

Follow three objects:

• code_challenge goes from Print Express to Google before login.
• authorization code returns through the browser after consent.
• access_token is created by Google and used only when Print Express calls Drive.

The boxes on screen

Name on this page	What it means
Resource Owner	JayP, the user who owns the Google Drive files.
User-Agent	JayP’s browser, which follows redirects between Print Express and Google.
Client	Print Express, the app requesting delegated access.
Authorization Server	Google Accounts, which authenticates JayP, obtains consent, issues authorization codes, and issues tokens.
Resource Server	Google Drive API, which hosts protected files and validates access tokens.

The most important visual invariant: the Client never gets the Resource Owner’s password.

Authorization Code + PKCE as a loop

You can compress the whole sequence into one loop:

prepare PKCE -> redirect to Google -> receive code -> exchange code for token -> call Drive

The diagram expands that loop into clickable steps because the boundaries matter. Browser redirects are the front channel. Token exchange and API calls are back-channel server requests. state protects the browser return trip; PKCE proves that the same client that started the login is finishing it.

An access token is a delegated credential. It does not say “the Client knows the user’s password.” It says “the Authorization Server issued this token for this audience, scope, subject, and expiry.”

The Authorization Server and Resource Server are separate roles. A company can run both roles in the same product boundary, but the jobs are different: one issues tokens; the other validates tokens and serves protected resources.

AI code review checks

When AI generates OAuth code for the JayP / Print Express example, inspect the implementation against these visual invariants:

Visual check	What you should see in code
Password stops at Google	The Client redirects to /authorize; it does not collect Google credentials.
Browser returns only a code	The callback handles ?code=...&state=..., not access_token in the URL.
Return trip is checked	The callback validates state before any token exchange.
PKCE closes the loop	The token request sends the original code_verifier.
Token goes to the API	The Drive API receives Authorization: Bearer <access_token>, never JayP’s password.
Scope is narrow	The requested scope is Drive read access, not broad account access.

If those parts are wrong, the implementation is probably wrong.

Words you can ignore at first

OAuth has many technical names: authorization code, PKCE, state, redirect_uri, access_token, refresh_token, scope, audience, and token endpoint.

You do not need to memorize them on the first pass. First understand the handoff:

authorize -> receive code -> exchange code for token -> call Resource Server.

Further reading

• OAuth 2.0 Explained In Simple Terms (With Visuals) — the JayP / Print Express / Google Drive story used as inspiration here.
• RFC 6749 — OAuth 2.0 Authorization Framework
• RFC 7636 — PKCE
• OAuth 2.0 Security BCP — Current best practices