Q262: OAuth OIDC PKCE and Frontend Login Flows
What Interviewers Want To Evaluate
Interviewers want to know whether you can explain OAuth and OpenID Connect without turning them into vague "login with Google" language.
They want practical frontend judgment: redirects, authorization code flow, PKCE, state, nonce, token handling, callback routes, session creation, and failure UX.
Short Interview Answer
OAuth is an authorization framework, while OpenID Connect adds identity on top of OAuth. For browser-based login, the modern pattern is Authorization Code Flow with PKCE. The frontend redirects the user to the identity provider, includes state for CSRF protection and a PKCE challenge, receives an authorization code on the callback, and exchanges it securely for tokens or a server session. I prefer keeping long-lived tokens off the browser when possible and using a server-managed session for the app.
Detailed Interview Answer
OAuth and OIDC are often mixed together.
A senior answer separates them:
OAuth: delegated authorization
OIDC: authentication and identity layer on OAuth
OAuth answers:
can this client access a resource?
OIDC answers:
who is this user?
Login flows usually use OIDC.
API authorization may use OAuth access tokens.
Authorization Code Flow
The typical browser login flow:
user clicks sign in
app redirects to identity provider
provider authenticates user
provider redirects back with authorization code
app exchanges code for tokens or session
app establishes authenticated state
The authorization code is short-lived.
It is not the final session by itself.
PKCE
PKCE means Proof Key for Code Exchange.
It protects public clients that cannot safely store a client secret.
The client creates:
code_verifier
code_challenge
The challenge is sent during authorization.
The verifier is sent during token exchange.
The provider checks that they match.
This makes intercepted authorization codes much less useful.
State
state protects the login flow from request forgery and response confusion.
The app generates a random value, stores it temporarily, sends it to the provider, and verifies it on callback.
If returned state does not match, reject the callback.
State may also encode where to return after login, but avoid putting sensitive data directly inside it.
Nonce
OIDC often uses nonce to bind an ID token to the authentication request.
It helps prevent replay or token injection in certain flows.
The app verifies the nonce in the returned ID token.
State and nonce have different jobs.
Do not casually drop either in flows that require them.
Tokens
Common token types:
authorization code
access token
ID token
refresh token
session cookie
Access tokens authorize API calls.
ID tokens describe identity claims.
Refresh tokens renew access.
Session cookies can represent the app's own login session.
Do not use an ID token as a general API access token.
Frontend Storage Judgment
Browser token storage is a trade-off.
JavaScript-readable tokens are exposed if XSS occurs.
Cookies reduce direct token theft when HttpOnly, but introduce CSRF considerations.
Many production apps use a backend-for-frontend pattern:
provider tokens live server-side
browser receives app session cookie
frontend calls same-origin app APIs
server calls provider or resource APIs
This reduces browser token exposure.
Callback Route
The callback route should:
verify state
verify nonce where applicable
exchange code safely
handle provider errors
create app session
avoid leaking codes in logs
redirect to allowed return URL
clear temporary login data
Never blindly redirect to an arbitrary URL from a query parameter.
That creates open redirect risk.
Failure UX
Login can fail in many ways:
user cancels
provider error
state mismatch
expired code
network failure
account not allowed
missing organization
blocked third-party cookies
popup closed
The UI should explain what happened without exposing sensitive internals.
It should also give a recovery path.
Interview Example
If asked, "Why should SPAs use PKCE?"
Answer:
"A browser app cannot keep a client secret safe. PKCE binds the authorization request to the token exchange using a verifier and challenge, so an intercepted authorization code cannot be exchanged by an attacker who lacks the verifier."
Common Mistakes
Common mistakes include:
confusing OAuth with authentication
using implicit flow for modern browser apps
not validating state
not validating nonce
storing long-lived refresh tokens in localStorage
logging authorization codes
using ID tokens as API access tokens
allowing unvalidated return redirects
Senior-Level Framing
The senior framing:
"I design login as a redirect-based security protocol, not just a UI action. I protect the flow with state, PKCE, nonce, strict callback handling, safe token storage, and server-side session validation."
Practice Prompt
Draw a login sequence for:
frontend app
identity provider
callback route
backend session endpoint
protected API
Label where state, nonce, code verifier, authorization code, tokens, and app session are created and verified.
Final Mental Model
OAuth and OIDC flows are choreography.
Every redirect and token has a job.
A strong frontend engineer knows which parts are UI, which parts are protocol, and which parts must be enforced server-side.