Ace ID OIDC Signing-Key Rotation

Ace ID loads its active key set from JWKS_JSON and can retain previous keys through JWKS_PREVIOUS_JSON. Rotation must preserve public verification keys until tokens and relying-party JWKS caches using the old kid have expired.

Staged rotation

1. Generate a new asymmetric signing key with a unique kid. Store private material only in the deployment secret manager.
2. Configure the new key set in JWKS_JSON and the prior key in JWKS_PREVIOUS_JSON.
3. Deploy and verify the public JWKS endpoint publishes the expected public keys only. No private fields such as d, p, q, dp, dq or qi may be exposed.
4. Complete a fresh Authorization Code + PKCE flow. Confirm newly issued tokens use the new kid and validate using the published JWKS.
5. Verify previously issued tokens remain valid during the overlap, including at least one representative relying party.
6. Keep the old key for at least the maximum token lifetime plus JWKS cache propagation and clock tolerance.
7. Remove the old key only after the overlap and validation period has elapsed. Never reuse a kid for different key material.
8. Record rotation timestamp, key IDs (not key material), deployment revision, operator and validation results.

Rollback

If the new key fails, restore the prior active configuration while keeping both public keys available. If any tokens were signed with the new key, retain that key as a previous key until those tokens expire. Do not delete it immediately.

Validation checklist

• [ ] All key IDs are unique and stable.
• [ ] Public JWKS exposes no private key material.
• [ ] Fresh authorization-code + PKCE login and callback succeed.
• [ ] Old tokens remain valid during the overlap.
• [ ] Logout, revocation and refresh behavior remain correct.
• [ ] Old key removal waits until token lifetime and JWKS cache expiry have passed.