What
The application has no mechanism to rotate the JWT signing key without invalidating all existing tokens.
Why
If the JWT secret is compromised (leaked, exposed in logs, etc.), there is no way to:
- Issue new tokens with a new key while allowing old tokens to expire naturally
- Support multiple active signing keys during a rotation window
- Gracefully transition between keys
This means a key compromise requires either:
- Immediate invalidation of ALL user sessions (bad UX)
- Continuing to use a compromised key (security risk)
Scope
- Support an array of JWT secrets (current + previous)
- Verify tokens against all active secrets
- Sign new tokens only with the latest secret
- Add a configuration option for key rotation (JWT_SECRET_PREVIOUS)
- Document the rotation procedure
Acceptance Criteria
- Multiple JWT secrets can be configured
- Token verification checks all configured secrets
- New tokens are signed with the latest secret
- Graceful transition when adding a new key
Technical Context
- File: src/server.ts:184-187 (JWT registration)
- Fastify JWT supports verify with multiple secrets via an array
- Config: JWT_SECRET (current), JWT_SECRET_PREVIOUS (optional)
What
The application has no mechanism to rotate the JWT signing key without invalidating all existing tokens.
Why
If the JWT secret is compromised (leaked, exposed in logs, etc.), there is no way to:
This means a key compromise requires either:
Scope
Acceptance Criteria
Technical Context