Move refresh token to an httpOnly cookie, keep access token in memory (#5)

[dsbaars]

Phase 5 (final) of the phased security-review response. Independent of #10–#13.

Closes

• Closes Move auth tokens out of browser storage and into httpOnly secure cookies #5 — Move auth tokens out of browser storage and into httpOnly secure cookies

Problem

The web app persisted both access and refresh tokens in browser-managed storage (localforage / IndexedDB) and sent the access token as a Bearer header. Any JavaScript in the page (e.g. via XSS or a malicious extension) could read long-lived session credentials — a meaningful risk for an app that manages encrypted private keys.

Approach

Adopt the recommended pattern: refresh token in an httpOnly cookie, access token in memory only.

Server

• Register @fastify/cookie.
• issueSession() moves the refresh token into an httpOnly, SameSite=Lax cookie (Secure in production), scoped to path=/api/auth, and strips it from the JSON body. Applied to register, login, totp/verify, and passkey login.
• POST /auth/refresh now reads the refresh token from the cookie (not the body), rotates it, and re-sets the cookie; returns only { accessToken }.
• POST /auth/logout reads the cookie, revokes the session, and clears the cookie.

Web

• No tokens are persisted anymore; the access token lives in memory (nanostores) only — localforage is gone from the auth store.
• restore() recovers a session on load by calling /auth/refresh (cookie sent automatically) then fetching the profile.
• logout() clears local state immediately and calls the server to clear the cookie + revoke the session (previously logout was client-side only).
• The API client sends credentials: 'include'.

Why SameSite=Lax is sufficient here

Both dev (Vite proxies /api → :3000) and prod (Caddy proxies /api* → server:3000 on the same :8080 origin) are same-origin for the browser, so SameSite=Lax cookies cover CSRF on the state-changing auth routes without needing a separate CSRF token.

Acceptance criteria (from the issue)

• ✅ Refresh tokens are no longer in localStorage / IndexedDB / localforage.
• ✅ Browser JS cannot read the long-lived session credential (httpOnly).
• ✅ login / refresh / logout / restore all still work.
• ✅ CSRF handled via SameSite on a same-origin deployment.
• ✅ Tests for cookie-based auth behaviour.

Operator note

• Deploying logs users out once — there are no persisted tokens to migrate, and old localforage tokens are no longer sent. One-time re-login. (Same one-time effect as Hash refresh tokens at rest with HMAC-SHA256 (#4) #11 if both ship.)

Tests

• Server: controller sets the refresh cookie + strips it from the body; /refresh reads/rotates from the cookie and rejects when missing; /logout revokes + clears. (server 92/92)
• Web: restore() recovers via the refresh cookie; logout() clears state and calls the server; api client sends credentials. (web 37/37)
• Both apps type-check/build; pnpm lint 0 errors; lint:security clean; format:check clean.

Reviewer notes

• The access token remains in JS memory (short-lived, 15m) and is still sent as a Bearer header — the issue explicitly allows this transitional state; the high-value change is getting the long-lived refresh token out of JS-readable storage.
• I could not run the full browser/Playwright E2E here — please smoke-test login / reload-restore / logout / TOTP / passkey in a real browser before merge. The cookie round-trip is covered by unit tests but not an end-to-end browser run.
• Two security/detect-object-injection lint warnings (not errors) remain on the cookie reads (req.cookies?.[REFRESH_COOKIE], a constant key — false positive); the dedicated lint:security config is clean.