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
Acts as the user’s interface, carrying out HTTP redirects and rendering the application and consent interfaces. Orchestrates front-channel interactions, passing authorization codes via query parameters. In the demo, watch redirect flows (blue/amber) bounce between Client App and Authorization Server via the Browser.
Client App
The application requesting access to the user’s data on the resource server. Initiates login requests, stores session state, exchanges authorization codes for tokens over a secure back-channel, and validates ID tokens. In the demo, watch the client app store the PKCE verifier, compare state parameters, and store issued tokens.
Authorization Server
The identity provider responsible for verifying user identities and issuing authorization codes and tokens. Authenticates users, presents consent screens, and verifies redirection parameters. In the demo, watch the server handle login redirect requests and issue the authorization code.
Consent Screen
Gives users control over which scopes/permissions the client app is requesting. Displays requested scopes and prompts the user to grant or deny access. In the demo, observe user interaction step yielding scope approval.
Token Endpoint
The secure back-channel endpoint used to redeem authorization codes for cryptographic tokens. Validates client credentials, authorization codes, and PKCE parameters, then issues Access, ID, and Refresh tokens. In the demo, watch the back-channel POST request verify PKCE and return tokens.
Resource Server
The API host that holds the user’s protected resources. Inspects access tokens (bearer token in Authorization header) to verify validity, expiration, and required scopes. In the demo, watch data requests carry access tokens and return protected user data.
App Session
Manages the local lifecycle of the logged-in user in the Client App. Tracks token expiry, performs refresh token rotation, and handles logout invalidation. In the demo, observe token lifetime countdowns and token rotation events.
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).\n
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.