OAuth 2.0 Flow Visualizer

OAuth 2.0 is an authorization framework — it answers 'can this app access this resource on behalf of the user?' It deals in access tokens scoped to specific resources. OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0 — it answers 'who is this user?' by adding an ID token (a JWT) containing the user's profile. When you see a scope like 'openid profile email', the openid scope triggers OIDC and the auth server returns an id_token in addition to the access_token. Use OAuth alone for delegated API access; add OIDC when you need authentication (login) as well.

PKCE (Proof Key for Code Exchange, RFC 7636) prevents authorization code interception attacks. Before redirecting, the client generates a random code_verifier, hashes it to produce a code_challenge, and sends the challenge to the auth server. When exchanging the code for tokens, the client sends the original code_verifier — the server verifies they match. Without PKCE, a malicious app on the same device could intercept the authorization code from the redirect and exchange it for tokens. PKCE is required for public clients (SPAs, mobile apps) and strongly recommended for confidential clients too. OAuth 2.1 (the upcoming simplified spec) mandates PKCE for all Authorization Code flows.

Use Client Credentials when there is no human user involved — your backend service, cron job, or microservice needs to call another API. The service authenticates as itself using its client_id and client_secret. Use Authorization Code when a human user is authorizing access — they need to log in and approve the scopes. The key question is: 'Is there a user who needs to consent?' If yes → Authorization Code. If no → Client Credentials.

Access tokens used in SPAs should be stored in memory (JavaScript variable) — not localStorage or sessionStorage, which are vulnerable to XSS. For web apps with a backend, store the refresh token in an HttpOnly, Secure, SameSite=Strict cookie and issue short-lived session cookies to the browser. Never store sensitive tokens in localStorage. In mobile apps, use the platform's secure storage (iOS Keychain, Android Keystore). Refresh tokens must be treated like passwords — rotate them on use (refresh token rotation) and invalidate old ones immediately.

When an API returns 401 Unauthorized, the client should check if it has a valid refresh token. If it does, it sends a POST /token request with grant_type=refresh_token and the refresh_token value. The auth server validates the refresh token and returns a new access_token (and often a new refresh_token — refresh token rotation). If the refresh token is also expired or revoked (e.g. user logged out, password changed, suspicious activity), the client must send the user back through the authorization flow from the beginning. Always implement token refresh logic before building any OAuth-protected feature.