PKCE & OpenID Connect

01 The gap PKCE fills

Lesson 5's security rested on the client secret protecting the back-channel token exchange. But an SPA or mobile app is a public client — every byte ships to the user's device, so it can't hold a secret (anyone can pop open DevTools or decompile the app and read it). Without a secret, a stolen authorization code could be redeemed by an attacker. PKCE closes that hole without any pre-shared secret.

02 How PKCE works — hash now, reveal later

Three moves, all built on a one-way hash (SHA-256, exactly the irreversibility idea from Lesson 4's password hashing):

1. verifier — the client generates a big random string and keeps it private (in memory/session).
2. challenge — it computes BASE64URL(SHA256(verifier)) and sends only this hash in the front-channel authorize request.
3. proof — at the back-channel token exchange it sends the raw verifier. The server hashes it and checks it matches the challenge it stored. Match → genuine.

03 🎯 Your tangible win (5 min): generate PKCE + decode an ID token

A zero-dependency lab runs both halves of this lesson: it builds a real verifier/challenge pair, redeems it, shows an attacker failing, then decodes an OIDC ID token.

# in your terminal (no npm install needed):
cd ~/projects/learn/public/courses/auth/practice/pkce-lab
node demo.js

PART A — PKCE:
  code_verifier  = MALyC6frNqopvqxZQ0wv9gB0mv_f5DCxt9fVhEUKRoU   (secret, stays local)
  code_challenge = Z4_5_NoCWdm_Nbtja8BpcjByigxrOX2j8Z94zkplQX4   (= SHA256, sent first)
  ✅ provider: SHA256(verifier) === stored challenge → issues token
  🛡️ attacker with the stolen code but a guessed verifier → "PKCE verification failed"

PART B — OIDC id_token (a JWT) decoded:
  { "iss":"accounts.google.com", "aud":"spa-app",
    "sub":"110169484474386276334", "email":"alex@example.com", "name":"Alex" }

04 The complete modern flow in Express (this is the real thing)

Authorization-code + PKCE, public-client style — note there's no client_secret anywhere:

const crypto = require('crypto');
const b64url = (b) => b.toString('base64url');

app.get('/login', (req, res) => {
  const verifier  = b64url(crypto.randomBytes(32));               // 1. per-request secret
  const challenge = b64url(crypto.createHash('sha256').update(verifier).digest());
  req.session.pkceVerifier = verifier;                          // keep it server-side
  req.session.state = b64url(crypto.randomBytes(8));            // CSRF (Lesson 2)
  const u = new URL('https://accounts.google.com/o/oauth2/v2/auth');
  Object.entries({ response_type:'code', client_id:CLIENT_ID,
    redirect_uri:REDIRECT_URI, scope:'openid email profile',    // openid → OIDC!
    state:req.session.state, code_challenge:challenge, code_challenge_method:'S256'
  }).forEach(([k,v]) => u.searchParams.set(k, v));
  res.redirect(u.toString());
});

app.get('/callback', async (req, res) => {
  if (req.query.state !== req.session.state) return res.status(403).end();
  const r = await fetch('https://oauth2.googleapis.com/token', { method:'POST',
    body: new URLSearchParams({ grant_type:'authorization_code', code:req.query.code,
      client_id:CLIENT_ID, redirect_uri:REDIRECT_URI,
      code_verifier:req.session.pkceVerifier }) });               // 3. prove it — no secret
  const { id_token, access_token } = await r.json();
  const user = await verifyIdToken(id_token);                    // 4. VERIFY (never decode-and-trust)
  req.session.userId = user.sub;                                 // 5. your own session begins
  res.redirect('/account');
});

05 OIDC: the layer that turns access into identity

Plain OAuth2 gives you an access token — permission to call an API. It deliberately says nothing reliable about who the user is. OpenID Connect (OIDC) is a thin standard layer on top that adds exactly that: ask for the openid scope and the provider also returns an ID token — a signed JWT whose claims identify the user.

06 Putting the whole course-so-far together

"Sign in with Google" is not a new thing — it's everything you've already learned, stacked:

07 Check yourself

08 Where we go next

You've now assembled the full password-free login. But every token-based scheme in this course has shared one nagging loose end: tokens expire, and you can't easily revoke them (Lessons 1 & 3). Lesson 7 tackles the token lifecycle head-on — refresh tokens, rotation, logout, and revocation: how real systems keep you logged in for weeks while keeping access tokens short-lived, and how they actually kill a session when you click "log out everywhere."

💬 Ask me anything — e.g. "wire real Google sign-in with openid-client in Express", "show me a provider's JWKS and how verification uses it", or "should my app use Google directly or a broker like Auth0/Clerk?" · Back to Lesson 5 · Lesson 3 (JWTs) · Resources.