Explain the OAuth 2.0 Authorization Code Flow.
The OAuth 2.0 Authorization Code Flow is the recommended grant type for web applications where a server-side backend can securely hold a client secret. It allows users to grant a third-party application access to their resources on another service (like Google or GitHub) without sharing their password.
**Participants:** - **Resource Owner**: the user - **Client**: the application requesting access (your app) - **Authorization Server**: issues tokens (e.g., Google's OAuth server) - **Resource Server**: the API holding the user's data (e.g., Google Calendar API)
**Flow steps:** 1. **Authorization Request**: The client redirects the user's browser to the authorization server with: `response_type=code`, `client_id`, `redirect_uri`, `scope`, and a `state` parameter (random nonce for CSRF protection).
2. **User Consent**: The user authenticates with the authorization server and grants the requested scopes. The authorization server does NOT share the user's credentials with the client.
3. **Authorization Code**: The authorization server redirects back to `redirect_uri` with a short-lived `code` and the `state` parameter. The client verifies `state` matches the value from step 1.
4. **Token Exchange**: The client's **backend** makes a server-to-server POST to the authorization server's token endpoint with: `code`, `redirect_uri`, `client_id`, and `client_secret`. This happens server-side — the `client_secret` never touches the browser.
5. **Token Response**: The authorization server returns an `access_token` (short-lived, 1h typically) and optionally a `refresh_token` (long-lived). The access token is used to call the Resource Server's API.
6. **API Calls**: The client includes `Authorization: Bearer <access_token>` in requests to the Resource Server.
**Why the two-step code + token exchange?** The authorization code travels through the browser's redirect URL — it could be intercepted by browser history, logs, or referrer headers. By making the code short-lived and requiring the client secret for exchange, an intercepted code is useless without the secret, which never leaves the server.
**PKCE (Proof Key for Code Exchange)** extends this flow for public clients (SPAs, mobile apps) that cannot hold a client secret. The client generates a `code_verifier` (random string), sends its hash (`code_challenge`) with the authorization request, and sends the original `code_verifier` during token exchange. The authorization server verifies the match — preventing code interception attacks even without a client secret.
Correctly names all four participants, describes all six steps in order, and explains why the two-step code + exchange is more secure than returning tokens directly in the redirect.
Explains the state parameter for CSRF prevention, distinguishes access token vs. refresh token lifetimes, explains PKCE and when it applies, and articulates what the client_secret protects against.
Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.
Get Graded — Free Assessment