OAuth2 Authorization Code Flow
Fast recall
Quick revision
Core answer
code_verifier/code_challenge) extends the flow to public clients (SPAs, mobile) without a client secret. OIDC adds an id_token for user identity. Spring Security OAuth2 Client automates the entire dance.Whether the candidate understands why the authorization code flow is more secure than the implicit flow and can trace the full token lifecycle.
Confusing the authorization code flow with the implicit flow, or not knowing the purpose of the state parameter (CSRF prevention).
Explain PKCE (Proof Key for Code Exchange) for public clients, the difference between access tokens and ID tokens in OIDC, and how Spring Security OAuth2 Client handles this flow automatically.
Interview-ready guide
Interview answer
The flow — step by step
- User clicks Login with Google; app redirects to
https://accounts.google.com/o/oauth2/auth?client_id=...&redirect_uri=...&state=&scope=openid email&code_challenge=...&code_challenge_method=S256 - User authenticates at Google and approves scopes
- Google redirects back with
?code=&state= - Backend verifies
statematches, exchangescodefor tokens via POST to Google's token endpoint withcode_verifier(orclient_secret) — server-to-server - Google returns
access_token+id_token(JWT with user info) +refresh_token - App stores tokens, uses
access_tokento call Google APIs
Why authorization code instead of implicit
- Implicit returned access token in URL fragment — visible in history, referrers, logs
- Code flow: token exchanged server-to-server; browser only sees one-time code
PKCE for SPAs
- SPAs can't keep a client secret
- PKCE proves the code exchanger is the same origin that initiated
- Required for any public client; recommended for confidential too (OAuth 2.1)
Common pitfalls
- Not validating
state-> CSRF / flow-injection - Skipping PKCE for mobile/SPA -> code interception attack
- Confusing
access_tokenandid_token - Long-lived access tokens without refresh rotation
OAuth2 Authorization Code Flow
Direct Answer
The OAuth2 authorization code flow separates user authentication from token issuance via a short-lived authorization code as an intermediary. The browser never receives the access token — it is exchanged server-to-server after the code is received. This prevents tokens from being exposed in browser history, logs, or referrer headers. The state parameter prevents CSRF on the authorization endpoint. PKCE (code_verifier/code_challenge) extends the flow to public clients (SPAs, mobile) without a client secret. OIDC adds an id_token for user identity. Spring Security OAuth2 Client automates the entire dance.
Common Mistakes & Pitfalls
Confusing the authorization code flow with the implicit flow, or not knowing the purpose of the state parameter (CSRF prevention).
Check your understanding
Answer these without looking back at the article.
- What is PKCE and when is it required in the authorization code flow?
- What is the difference between an OAuth2 access token and an OIDC ID token?
- How does Spring Security's OAuth2 Client store and manage tokens between requests?
- How does the state parameter prevent flow-injection attacks?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.