Reference · OAuth 2.1 / RFC 6749 + RFC 7636

OAuth 2.1 Flow Visualizer.

Visual reference for the OAuth 2.1 flows you actually use in production — Authorization Code with PKCE, Client Credentials, Device Authorization, Refresh Token. Each flow shows the swimlane between client, browser, authorization server, and resource server, with the precise request and response at each step.

Authorization Code with PKCE

Default for any client that runs in a browser (SPA) or on a device (mobile / desktop / CLI).

When to use

Use whenever the client cannot be trusted with a long-lived secret — single-page apps, mobile apps, CLIs. PKCE eliminates the need for a client secret and protects against authorization-code interception.

Spec

RFC 6749 (Authorization Code) + RFC 7636 (PKCE) + OAuth 2.1 BCP

1. Generate PKCE pair
Client → Browser
Client generates a high-entropy `code_verifier` (43-128 chars), then derives the `code_challenge` as base64url(SHA256(code_verifier)).
```
code_verifier = high-entropy random
code_challenge = base64url(sha256(code_verifier))
code_challenge_method = S256
```

2. /authorize redirect

Browser → Auth server

Browser is redirected to the authorization endpoint with the PKCE challenge, response_type=code, the client ID, scope, and state.

GET /authorize?
  response_type=code
  &client_id=<client>
  &redirect_uri=<callback>
  &scope=openid+profile
  &state=<csrf>
  &code_challenge=<challenge>
  &code_challenge_method=S256

3. Login + consent
Auth server → User
User authenticates with the IdP, then approves the requested scopes. If the user is already logged in and has previously consented, this step is silent.
4. Code redirect
Auth server → Browser
Authorization server redirects the browser back to the client's redirect_uri with the authorization code and the original state.
```
HTTP 302
Location: <callback>?code=<auth_code>&state=<csrf>
```
5. Browser hands code to client
Browser → Client
For an SPA, the client picks up the code from the URL fragment / query. For a native app, the deep-link delivers it.
6. Exchange code for tokens
Client → Auth server
Client POSTs the code + the original PKCE verifier to /token. The server validates that SHA256(code_verifier) matches the challenge from step 2.
```
POST /token
  grant_type=authorization_code
  &code=<auth_code>
  &redirect_uri=<callback>
  &client_id=<client>
  &code_verifier=<verifier>
```
7. Tokens returned
Auth server → Client
Server returns an access token (short-lived), an ID token (OIDC), and optionally a refresh token.
```
{
  "access_token": "...",
  "id_token": "...",
  "refresh_token": "...",
  "token_type": "Bearer",
  "expires_in": 3600
}
```
8. Call resource server
Client → Resource server
Client includes the access token in the Authorization header on every API call.
```
GET /api/things
Authorization: Bearer <access_token>
```

Actors used in this flow: User · Client · Browser · Auth server · Resource server.

What this is good for

Typical use cases.

Show a new developer how the PKCE flow works without drawing on a whiteboard
Confirm which parameters belong in `/authorize` vs `/token`
Reference the device-code flow for IoT / CLI integrations

Go deeper

Read the OAuth 2.1 explainer.

OAuth 2.1 explainedDecode an access token