Signing key management for JWTs

JWT signing keys are not just configuration. They are the root of trust for every token the issuer creates. If a signing key leaks, an attacker can mint credentials that look legitimate until rotation and detection catch up. If key management is painful, teams postpone rotation and keep secrets in places that were convenient during the first launch. That is how authentication debt becomes incident debt.

Generate and store keys deliberately

Use strong random generation from a trusted tool or KMS. Do not derive HMAC secrets from product names, deployment names, or passwords. For asymmetric signing, keep private keys out of application repositories and container images. The service that signs tokens needs access to private key operations, not necessarily the raw key bytes. KMS, HSM, or a cloud signing service can reduce exposure, though latency and quota limits must be tested.

Separate environments. Development, staging, and production should not share signing keys. Partner sandboxes should not accept production issuers unless there is a deliberate federation design. A surprising number of incidents start with a staging key that verifies in production because issuer and audience checks were loose.

Control who can sign

Verification can be broad. Signing must be narrow. Only the issuer service should create user tokens, and administrative tooling should use a separate path with stronger audit. If every backend service has the signing secret, every backend compromise becomes an identity provider compromise. Prefer a central token service or constrained signing API with clear scopes.

Rotation and audit

Plan rotation before compromise. Keep key ids unique, publish new public keys before use, retain old public keys until tokens expire, and monitor which kid signs new tokens. Audit every change to signing configuration: who changed it, what key id, which environment, and which deployment picked it up. Store enough history to answer whether a suspicious token could have been signed by a key active at that time.

Emergency response

Have a runbook for key compromise. It should include disabling signing with the affected key, publishing removal, shortening token lifetimes if possible, revoking sessions, and communicating expected client impact. Practice it in staging. The first time a team discovers that mobile clients hard-code a JWKS URL should not be during a real compromise.

The useful standard

A healthy JWT key system makes the secure action ordinary: keys generated centrally, private material isolated, signing access limited, rotation rehearsed, and audit trails readable by on-call engineers. Anything else becomes a future security archaeology project.