OAuth 2.0 Flow Diagram and Types: Authorization Code with PKCE First

Roles, client types, and the flow map

RFC 6749 defines four roles. The resource owner is usually the user. The client is the application that wants access. The authorization server authenticates the user and issues tokens, and the resource server is the API that accepts them. Clients are confidential when they can protect a credential, such as a backend web app, and public when they cannot, such as a single-page app, a mobile app, or a CLI. Anything shipped to a device can be extracted, so a public client has no real secret.

Two channels matter. The front channel is the browser redirect, which travels through URLs, history, and possibly logs. The back channel is a direct HTTPS call from the client to the token endpoint. Good flows put only short-lived, single-use values in the front channel and exchange them for tokens over the back channel. The table maps each grant to its use and its status under the OAuth 2.0 Security Best Current Practice, RFC 9700.

• RFC 6749: The OAuth 2.0 Authorization Framework

Authorization code with PKCE, step by step

The client generates a high-entropy code_verifier and derives code_challenge = BASE64URL(SHA-256(verifier)). It redirects the browser to the authorization endpoint with response_type=code, client_id, redirect_uri, scope, state, code_challenge, and code_challenge_method=S256. After the user signs in and consents, the authorization server redirects back to the registered redirect URI with a one-time code and the same state. The client checks state, then posts grant_type=authorization_code, the code, the redirect_uri, and the original code_verifier to the token endpoint.

The server hashes the verifier and compares the result with the stored challenge before issuing tokens. That is the whole trick: an attacker who intercepts the code from a redirect, a log line, or a malicious app registered for the same custom URL scheme cannot redeem it without the verifier, which never traveled through the front channel. RFC 9700 says public clients MUST use PKCE, recommends it for confidential clients, names S256 as the method that does not expose the verifier, and requires exact redirect URI matching.

• RFC 7636: Proof Key for Code Exchange (PKCE)
• RFC 9700: Best Current Practice for OAuth 2.0 Security

Compute an S256 challenge and check the RFC test vector

RFC 7636 requires a verifier of 43 to 128 characters drawn from letters, digits, and the four characters - . _ ~. The snippet uses secrets.token_urlsafe(32), which turns 32 random bytes into 43 URL-safe characters, and checks the format with a regular expression. The challenge is the raw SHA-256 digest encoded as base64url with the trailing = padding removed. Appendix B of RFC 7636 publishes a verifier and its expected challenge, which makes a deterministic test.

Running python3 pkce.py on Python 3.12 prints E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM, then True, then 43 43: the computed challenge matches the RFC value, and a fresh verifier and its challenge are both 43 characters long. A mismatch surfaces as an invalid_grant error at the token endpoint. The usual causes are standard base64 with + and /, leftover padding, hashing the hex digest instead of the raw bytes, or generating a new verifier between steps 2 and 5.

import base64, hashlib, re, secrets

def s256(verifier: str) -> str:
    digest = hashlib.sha256(verifier.encode("ascii")).digest()
    return base64.urlsafe_b64encode(digest).rstrip(b"=").decode("ascii")

def new_verifier() -> str:
    v = secrets.token_urlsafe(32)  # 32 random bytes -> 43 URL-safe characters
    assert re.fullmatch(r"[A-Za-z0-9\-._~]{43,128}", v)
    return v

# RFC 7636 Appendix B test vector
rfc_verifier = "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
expected = "E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM"

print(s256(rfc_verifier))
print(s256(rfc_verifier) == expected)
v = new_verifier()
print(len(v), len(s256(v)))

Client credentials and the device authorization grant

When no user is involved, such as a billing service calling a reporting API, the client authenticates to the token endpoint as itself with grant_type=client_credentials and receives a token for its own permissions. RFC 6749 limits this grant to confidential clients, which authenticate with a client secret, a signed JWT assertion, or mutual TLS, and says a refresh token should not be included; the client simply asks again. Scope the client narrowly, because whoever holds its credential is that service.

The device grant in RFC 8628 serves TVs, consoles, and CLIs. The device requests a device_code, a short user_code, and a verification_uri, shows the code, and polls the token endpoint with grant_type urn:ietf:params:oauth:grant-type:device_code. Until the user approves on a phone or laptop, the server answers authorization_pending; slow_down means add five seconds to the polling interval. RFC 8628 warns about remote phishing: an attacker can start the flow and persuade a victim to enter the code, so RFC 8628 recommends telling the user that they are authorizing a device and asking them to confirm it is in their possession.

• RFC 8628: OAuth 2.0 Device Authorization Grant

Why implicit and password grants are deprecated

The implicit grant returned the access token directly in the redirect URL fragment, so tokens could leak through manipulated redirect URIs, referrer headers, and browser history, and no standard mechanism bound them to the client that requested them. RFC 9700 says clients SHOULD NOT use it unless those leaks and token injection are otherwise prevented. The resource owner password credentials grant asks the client to collect the user's password itself, which exposes the credential to the client, trains users to type passwords outside the authorization server, and is not designed for two-factor or multi-step logins. RFC 9700 says it MUST NOT be used.

OAuth 2.1 consolidates these lessons, but cite it honestly: as of November 2026 it is still an Internet-Draft, draft-ietf-oauth-v2-1-17 from October 2026, not an RFC. The draft leaves out the implicit and password grants, requires exact redirect URI matching, and requires PKCE with the authorization code flow, except for confidential clients that correctly use the OpenID Connect nonce. In an interview, say that today's best practice is RFC 9700 and that OAuth 2.1 is the draft folding it into the core specification.

• RFC 9700: Best Current Practice for OAuth 2.0 Security
• IETF draft-ietf-oauth-v2-1: The OAuth 2.1 Authorization Framework (Internet-Draft)

OAuth vs OpenID Connect

OAuth answers a delegation question: may this client call this API on the user's behalf, with these scopes? It does not tell the client who the user is, and an access token is meant for the resource server, not as proof of login for the client. OpenID Connect adds an identity layer on top of OAuth 2.0, most often with the authorization code flow. The client requests the openid scope and receives an ID token, a JWT addressed to the client with claims such as iss, sub, aud, exp, and nonce, plus access to a UserInfo endpoint.

The working rule: the ID token is for the client, and the access token is for the API. Validate the ID token's signature, issuer, audience, and nonce before trusting sub, and never forward it to APIs as a bearer credential. A common interview slip is to call OAuth an authentication protocol; a precise answer says OAuth handles delegated authorization and OpenID Connect standardizes authentication on top of it.

• OpenID Connect Core 1.0

Redraw it, then practice the follow-ups

Practice drawing the nine steps in under a minute, labeling which arrows pass through the browser. Then prepare short answers to the follow-ups interviewers like: why the code is single-use, what state protects against, why a single-page app is a public client, and what changes when a backend-for-frontend keeps tokens on the server. RFC 9700 lets a client rely on PKCE for CSRF protection once it has confirmed that the server supports PKCE; otherwise state must carry a one-time CSRF token bound to the browser.

Then rehearse the decision in reverse: given a smart TV app, a nightly batch job, and a mobile app, name the grant for each and the reason: the device grant, client credentials, and authorization code with PKCE. Recompute the RFC 7636 test vector from memory as well; it quickly shows whether you remember base64url without padding. The question sets below cover the surrounding authentication and HTTP material.

• 36 backend authentication and security interview questions
• 36 HTTP and REST API interview questions
• Practise the backend interview track

Quick answers

Frequently asked questions