OAuth 2.0 & OIDC Flow Visualization
Walk through OAuth 2.0 Authorization Code and OIDC flows: redirects, consent, authorization code, PKCE verification, token exchange, API calls, state, nonce, token theft, refresh
Continue with the guided workspace
Use the paired workspace to connect this guide's mental model with live component state, visible signals, and the outcome each step or scenario is meant to prove.
Mental Model
Modern application security requires robust identity and access management. OAuth 2.0 and OpenID Connect (OIDC) govern how applications securely delegate authentication and authorize API access without exposing user credentials.
For interactive exploration of these behaviors, you can run the live sandbox: OAuth 2.0 & OIDC Flow Simulator.
Components and Why They Exist
User Browser
The user browser acts as the front-channel user agent, executing HTTP redirects and rendering both the client application and identity provider consent screens. Blue and amber redirect particles travel between the Client App and Authorization Server through the browser as it carries authorization requests and returns short-lived authorization codes via callback query parameters.
Client App
The client app is the application requesting delegated access to the user’s data on the resource server. It initiates login requests, stores the local PKCE verifier, compares returned state parameters against its stored session state, and exchanges authorization codes over a back-channel call to save issued tokens.
Authorization Server
The authorization server is the identity provider responsible for authenticating users and issuing authorization codes and tokens. It handles login redirect requests, verifies user credentials, presents consent screens, and validates redirect parameters before issuing a single-use authorization code.
Consent Screen
The consent screen gives users explicit control over which scopes and permissions the client application is requesting. It displays the requested identity and API scopes so the user can approve or deny delegated access before code issuance proceeds.
Token Endpoint
The token endpoint is the back-channel HTTPS endpoint where the client redeems authorization codes for cryptographic tokens. A direct POST request from the client presents the authorization code and PKCE verifier here, returning signed Access, ID, and Refresh tokens once verification succeeds.
Resource Server
The resource server is the backend API host that holds the user’s protected data. Incoming API requests attach the bearer access token in the Authorization header, and the server validates the token signature, expiration status, and required scopes before returning protected user data.
App Session
The app session component manages the local authenticated lifecycle of the user inside the Client App. It tracks token lifetime countdowns, initiates refresh token rotation when access tokens expire, and clears session state on logout or revocation.
Edge Cases and Misconceptions
Front-channel vs. Back-channel Security
A common misconception is that passing tokens through the browser URL query parameters is safe. The front-channel (browser URL redirects) is highly vulnerable to history leaks and interception. Authorization Code flow uses the front-channel only to pass short-lived authorization codes, while actual tokens are exchanged over the secure back-channel (direct server-to-server calls).
State Parameter vs. PKCE
Learners often confuse state and PKCE (code_verifier). The state parameter is used to prevent Cross-Site Request Forgery (CSRF), validating that the login response comes from the same session that initiated it. PKCE prevents Authorization Code Interception attacks, proving that the client redeeming the code is the same client that requested it.
Implicit Grant Obsolescence
Historically, the Implicit Grant issued tokens directly to the browser front-channel without an authorization code exchange. Due to modern security vulnerabilities (like token leakages in browser histories and referer headers), Implicit Grant is deprecated. Authorization Code flow with PKCE is now the industry standard for all client types, including Single Page Applications (SPAs).
Common Questions
What is the difference between OAuth 2.0 and OpenID Connect (OIDC)?
OAuth 2.0 is an authorization framework designed to grant access to APIs (Resource Servers) using Access Tokens. OpenID Connect is an identity layer built on top of OAuth 2.0 to handle authentication (proving who the user is) by introducing ID Tokens (JWTs).
How does the state parameter prevent CSRF attacks?
Before redirecting to the authorization server, the client generates a random state value and stores it locally. The authorization server returns this state in the callback query. The client verifies that the returned state matches the stored value; if they mismatch, the login request is rejected.
What is PKCE and why is it required even for public clients?
PKCE (Proof Key for Code Exchange) requires the client to create a secret code_verifier and its hash code_challenge. The challenge is sent during the initial request, and the verifier is sent during code redemption. If an attacker intercepts the authorization code, they cannot redeem it because they lack the original code_verifier.
What is Refresh Token Rotation?
Refresh Token Rotation is a security measure where every time a client uses a Refresh Token to get a new Access Token, a new Refresh Token is also issued, and the old one is invalidated. If an attacker steals a refresh token and attempts to use it, the detection of a reused token will cause the authorization server to revoke all tokens associated with that family.