Stage 12 · L50

Follow authorization code, PKCE, state and nonce

Optional extension · expanded identity visuals; no released federation

Protocol study only. No federated login, callback, JWKS, refresh or SSO endpoint is implemented.

Before federated login, the provider must know the client and exact permitted redirect URIs. A public browser client cannot keep a client secret. A confidential server client owns its credential on the server. Client registration is a real provider decision, not a callback URL invented from an incoming request.

Discover endpoints from a configured trusted issuer and verify the returned issuer matches it. Do not fetch discovery from an arbitrary issuer supplied by an unverified token. The authorization, token and JWKS endpoints belong to that trusted configuration. No discovery fetch or real client registration is performed in this revision.

The browser is redirected with a short-lived authorization code rather than receiving every credential in a front-channel URL. The client then exchanges that code through the token endpoint under its client/PKCE contract. Codes are short-lived and single-use; they must be bound to the intended client and redirect.

PKCE binds the code exchange to the client that initiated the attempt. Generate a high-entropy verifier, send its S256 challenge during authorization and prove the verifier during exchange. The challenge is base64url(SHA256(verifier)) without padding. This hashing primitive can be studied offline; it is not a complete authorization flow.

state correlates the returned callback with the initiating login attempt; nonce binds the ID token to that authentication attempt. They are not substitutes for each other or for PKCE. Check state before exchanging a code, then validate the token and expected nonce before establishing the local session. Store attempt data with a bounded lifetime and reject mismatch/replay. None of those callback/session mechanisms is installed here.

import base64, hashlib, secrets
verifier = secrets.token_urlsafe(32)
challenge = base64.urlsafe_b64encode(hashlib.sha256(verifier.encode('ascii')).digest()).decode('ascii').rstrip('=')
assert 43 <= len(verifier) <= 128 and len(challenge) == 43

Registered redirect/trusted issuer → fresh attempt state/nonce/verifier → authorization code → validate returned state → exchange using verifier → validate intended token/nonce. PKCE binds the redeemer, state correlates the return, nonce binds the ID token to the attempt. This offline hash proves none of the server flow; trusted key/account linking is the next lesson.