A signing-key rotation can be simple on paper: generate a new key, change the signer, and deploy. In a running service, that sequence can reject valid tokens. A token signed just before the change may remain valid for another fifteen minutes. At the same time, a receiving API may still have a JWKS snapshot without the new key.

The failure is confusing because each component may look healthy. The auth server signs a token. The resource service is serving requests. The JWKS endpoint returns JSON. Yet a call fails because they disagree about which public keys are available at that moment .

I built Orionis so the auth server can hold multiple signers, publish all their public keys in JWKS, and select one active_kid for new tokens. That gives a planned rotation an overlap period.

This article is about a routine, planned rotation of a service-token signing key. The goal is to change the key used for new tokens while letting already issued tokens reach their normal expiry.…