Authenticate the browser, not the user

A third pattern that sits between the HMAC anti-abuse gate (Part 1, no key state) and authenticated DPoP (Part 3, post-login). This one binds a session token to a non-extractable key the browser holds, before the user has authenticated. The session is anonymous from byte zero — but it's still tied to the originating device, so a token that gets harvested off one page load can't be moved to other machines.

The gap HMAC tokens leave

The Part 1 HMAC demo proves "this browser loaded the page recently" — enough to make scraping more expensive, not enough to make a harvested token useless. The token itself is a bearer instrument: an HMAC over nonce | expiry, no key binding, no per-request signature. A bot that does one page load and sells the harvested token to 1,000 other bots gets a 1,000x multiplier on the work — every buyer can mint lookups until the token expires.

• Token resale markets exist. Bot operators buy and sell short-lived API tokens on private Telegram channels and Discord servers. The harvester does one expensive thing (solve a captcha, render the JS, click through a consent flow); the buyers do the cheap thing (replay).
• CDN bot scoring is per-token, not per-request. If your edge issues a token after a Cloudflare Turnstile check and downstream API trusts the token, an attacker who clears Turnstile once can drain the budget that the token authorises.
• Pre-auth surfaces are everywhere. Marketing-page LLM costs, public search APIs, content scraping endpoints, signup flows — all live before the user is known and after the page is loaded. HMAC raises the floor; it doesn't bind the credential.

What anonymous DPoP does

Same primitive as full DPoP (RFC 9449), applied before authentication. On page load the browser generates a non-extractable WebCrypto keypair and posts the public JWK to a "start session" endpoint. The server computes the RFC 7638 thumbprint, mints a short-lived session JWT with cnf.jkt set to that thumbprint, and returns it. Every subsequent API call carries the session JWT in Authorization: DPoP <token> plus a freshly-signed DPoP proof in the DPoP header. The same RFC 9449 §4.3 verifier runs every check including cnf.jkt and ath — no separate code path.

POST /api/v1/anon-session/start HTTP/1.1
Content-Type: application/json

{"jwk": {"kty":"EC","crv":"P-256","x":"…","y":"…"}}      ← the public half of a non-extractable keypair

HTTP/1.1 200 OK
{
  "access_token": "eyJhbGciOiJIUzI1NiJ9…",                ← HS256 JWT with cnf.jkt = thumbprint(JWK)
  "token_type":   "DPoP",
  "expires_in":   600
}

The crucial difference from Part 1's HMAC token: the access token cannot be replayed by another machine, because the other machine doesn't have the private key. Apple's Private Access Tokens (RFC 9577) and several CDN bot-management products use the same pattern in production — bind credibility to the device, not to the human.

Try it · the full anonymous flow

Three steps. Generate a keypair (extractable=false), start an anonymous session, call a protected endpoint. The protected endpoint is the same /api/v1/dpop-verify the authenticated demo uses — that's the whole point: the verifier doesn't care whether the session came from a login or from an anonymous-session start, it only cares that the proof binds.

Step 1 — generate a keypair

The private key never leaves the browser — generated with extractable: false, so even a same-origin script (think: injected XSS) cannot read it back out via exportKey. Only WebCrypto itself, via subtle.sign, ever touches the private half. The public key is exported as a JWK and POSTed to the start endpoint so the server can compute the RFC 7638 thumbprint and bind cnf.jkt.

Step 2 — start an anonymous session

POSTs the page's public JWK to /api/v1/anon-session/start. The server computes the RFC 7638 thumbprint, mints a 10-minute HS256 session JWT with cnf.jkt set to that thumbprint, and returns it. The page keeps the token in module-scope memory — closing the tab forgets it, matching what a real anonymous-DPoP client would do.

Step 3 — call the protected endpoint

POSTs to /api/v1/dpop-verify with Authorization: DPoP <session_token> and a fresh DPoP proof bound to the token via ath. The server runs every RFC 9449 §4.3 check, including the cnf.jkt binding and the per-request ath claim.

Attack scenarios

Three failure modes anonymous DPoP defends against. Each button runs the attack against the just-issued anonymous session and shows you the per-check verdict — the failure is always loud.

Verdict

What this is not