fix(api): stable JWT_SECRET signing so restarts don't invalidate sessions #4065

Originally written by @ccantynz-alt on GitHub.
Imported from https://github.com/ccantynz-alt/AlecRae.com/pull/66

Symptom

After logging in, an API call returns "Invalid or expired bearer token" — especially right after an alecrae-api restart/deploy.

Root cause

jwt.ts resolved signing keys as: provided RS256 keypair → ephemeral RS256 generated at boot → HS256 from JWT_SECRET (last resort). On Bun, ephemeral RS256 generation always succeeds, so:

• Access tokens are signed with throwaway keys regenerated on every boot → every restart invalidates all sessions.
• A configured JWT_SECRET (which production has, for the OAuth state signer) never actually took effect for token signing.

Fix

Reorder key resolution so a stable secret wins over ephemeral keys:

1. Provided RS256 keypair (JWT_PRIVATE_KEY + JWT_PUBLIC_KEY)
2. Stable HS256 from JWT_SECRET ← deployed APIs land here; tokens now survive restarts
3. Production refuses to boot with neither (an ephemeral keypair would log everyone out on restart)
4. Dev-only: ephemeral RS256 / dev secret

No JWKS endpoint exists (the API verifies its own tokens), so symmetric HS256 is safe. Avoids wrestling multiline RS256 PEMs into systemd EnvironmentFile.

Verify after deploy

bun run typecheck (api) ✅. After deploy: log in, restart alecrae-api, confirm the existing session still works (previously it broke). Boot log shows [jwt] Using HS256 with JWT_SECRET (stable across restarts).

Follow-up (not in this PR)

Access tokens are 15 min; the Google sign-in flow doesn't persist a refresh token, so there's no silent re-auth — a separate fix for session longevity.

https://claude.ai/code/session_01McgJLnTbZG9mwhfwd5iAX3

Generated by Claude Code