Passkeys: Settings → Passkeys lists, adds and removes them, and signing in with one issues the same session as a password #1713

Settings → Passkeys now lists, adds and removes passkeys, and signing in with one gives the same HttpOnly session cookie a password does. bun x tsc --noEmit is clean, and test/passkeys.test.ts, test/webauthn.test.ts, test/check-list.test.ts, the settings/session tests and the schema tests all pass (about 140 tests). The browser script is untested: the tests drive the endpoints with a software authenticator and never run it in a real browser.

• Storage: migration 80 adds a passkey table, several per account. It is deleted with the account, and src/core/passkeys.ts handles list, add, remove, find and mark-used. An account keeps at most 20 passkeys.
• Settings page: /settings/passkeys shows the list with a name, added and last-used columns. Removal goes through the existing /-/confirm step. The add form posts JSON from a small nonce'd inline script in src/web/passkey-client.ts. Without JavaScript the page still lists and removes, and says adding needs script.
• Mutations: they need a session cookie, not a token or password. They are same-origin checked, a challenge answers once, and passkey names are escaped.
• Sign-in: the sign-in page has a "Sign in with a passkey" button, and the passkey routes sit beside the others in src/http/server.ts. A good assertion creates the session through the same createSession and sessionCookie as a password, and honours ?next=. Every refusal is the same 401, and the challenge is spent even on a refusal.
• Sign-in throttle: passkey sign-in reuses the password throttle, keyed by client address.
• Gate: test/passkeys.test.ts is named in GATE in scripts/gate.ts. It covers add two, remove one, sign in with the other, and the removed one refused, plus cross-origin and no-session refusals, replay and forgery, duplicate enrolment, and escaping.
• Other edits: signinAllowed and safeNext are now exported from site.ts. accountShell takes an optional scriptJs. The README has a short paragraph.

Left out:

• There is no "last passkey" guard, because passwords stay valid.
• There is no rename, no attestation formats beyond none, and no conditional-UI autofill.
• The relying party is the host the browser used, or FORGE_URL when set, so a passkey does not follow a forge to another hostname.
• Sign-in challenges sit in one in-memory store per process, capped at 10,000 and rate-limited per address.

To try it: boot with bun run src/main.ts, sign in, open Settings → Passkeys, add one, then sign out and use the button on /signin.

🤖 Generated with Claude Code

Closes #1694

I merged main into this branch, resolved the one conflict in src/core/schema.ts, and pushed it.

The conflict: both sides had added a migration numbered 80. main's restore-drill table (drill, #1668) keeps 80, and the passkey table from this pull is now migration 81, right after it. Neither table changed.

Tests: test/passkeys.test.ts passes, 4 of 4, and so do the schema tests (19 pass in total across both). A full bun test run showed 4 failures, all in unrelated suites: the scaffolded-app typecheck, the capacity admin test, the chromium look capture, and the phone-width page check. I re-ran the capacity test on a clean main checkout and it fails there too, so I take it to be the sandbox. I did not re-run the other three on main, and they did not run again after the merge.

I added the four missing tests to test/passkeys.test.ts, with no change to app code. bun test test/passkeys.test.ts passes (8 tests) and tsc --noEmit is clean. I did not delete each guard to confirm its test goes red.

• Another account's passkey: a second account, eve, POSTs /settings/passkeys/<pat's id>/delete. The redirect's flash shows "No such passkey." and pat's row is still there.
• Tokens: an admin-scope bearer token for pat gets 403 on both /settings/passkeys/options and /settings/passkeys, and no passkey row is added.
• Deactivated account: a user enrols a passkey and is then suspended (suspended_at, which is what isActive checks). Signing in with that key returns 401 and sets no cookie.
• Rate limit: with signin.per_account set to 2, /signin/passkey/options returns 429 with a positive retry-after, and /signin/passkey returns 429 as well. The test resets the limit afterwards.

The rate-limit test does not pin the "two tokens per sign-in" detail you mentioned. Every test in the file shares one socket address, so the bucket is already partly spent when the test starts. I couldn't assert exact counts. The test loops up to three more calls until it sees the 429. It pins that options and the answer share one limit, not how many tokens a full sign-in costs.

I left the app code alone and did not add a terminal door, as you said.

I merged origin/main into the branch and pushed it. The check had failed because the branch no longer merged into main: both sides had edited scripts/gate.ts and src/core/schema.ts.

• scripts/gate.ts: I kept both sides' test entries, so test/passkeys.test.ts sits alongside main's new test/turnstile.test.ts and test/thoughts.test.ts.
• src/core/schema.ts: main had taken migration 81 for the thought table, so the passkey table is now migration 82, after it. No other code refers to the number.
• Tests: tsc --noEmit is clean. I ran the passkey, webauthn, schema and thoughts tests and 45 pass. I did not run the whole suite; the forge's check does that on this push.