Full Stack Developer Interview Question

Walk me through the OAuth authorization code flow with PKCE.

What the interviewer is probing, how to structure your answer, and a spoken example you can adapt.

Quick answer

The client generates a random verifier, hashes it into a code challenge, and redirects the user to the authorization server with that challenge. The user authenticates, gets redirected back with a single use code, and the client exchanges that code plus the original verifier for tokens. Because the exchange requires the verifier, an intercepted code is useless. OAuth 2.1 requires PKCE for every client, public or confidential.

Why interviewers ask this

Almost every product does social login or a third party integration, so the interviewer wants to know whether you have implemented one or only clicked through a library. They are listening for the redirect, the code exchange happening server to server, and why PKCE exists at all. Bonus signal comes from separating OAuth authorization from OIDC authentication, which is the distinction most candidates blur.

How to structure your answer

  • Trace the flow in order, from verifier to token exchange.
  • Explain what attack PKCE prevents.
  • Distinguish the ID token from the access token.
  • Say where each token ends up on your side.

Example answer

Spoken example, first person

The client starts by generating a high entropy verifier and hashing it with SHA-256 to make the code challenge. It sends the user to the authorization server with the client id, redirect URI, scopes, a state value and that challenge. The user logs in and consents, and the authorization server redirects back with a short lived code. The client then posts that code and the raw verifier to the token endpoint, the server hashes the verifier and checks it matches the challenge it stored, and only then issues tokens. That is the whole point of PKCE: a code stolen from a redirect, a log or a malicious app on the device cannot be redeemed without the verifier, which never left the client. I still validate state separately, because that covers CSRF on the callback rather than code interception. If I am doing login rather than API access, I care about the OIDC ID token and I validate its signature, issuer, audience and nonce before trusting a single claim in it.

Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.

See how it works

Follow-up questions to expect

  • What does the state parameter protect against that PKCE does not?
  • What is the difference between an ID token and an access token?
  • Where would you store the refresh token for a browser based client?

Related full stack developer questions

Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.

Predict my questions

Rehearse the hard questions before they are asked

Practise with a live copilot, then walk in ready. A $29 Session Pass gets you through the interview with no subscription and no lock-in.

Get GhostPilot