Why You Need to Rotate Your OpenIddict Signing Keys

Introduction

In most production setups, OpenIddict issues tokens as JSON Web Tokens (JWTs) signed by your OpenIddict server. As long as the signing key is trusted, every API and client can safely accept those tokens. If that key is ever compromised, though, an attacker can mint their own “valid” tokens and walk straight through your defences. 

That’s why signing key rotation isn’t a “nice to have” – it’s a core part of running a serious OpenID Connect system.

Your signing key is a safe, not a magic shield.

Think of your signing key like a bank safe. No manufacturer will promise “this safe can never be opened”. What they promise is closer to: “given current tools, this safe will withstand attack for at least N hours”. As long as someone checks regularly, you’ll spot tampering in time.

Signing keys are similar:

• We can’t assume they’ll never be stolen, leaked, or brute‑forced.
• We can limit the damage window by regularly replacing them.
• The shorter the window, the less valuable a stolen key becomes.

In practice, that means:

• Keep keys strong (RSA 2048+ or ECDSA on modern curves). 
• Rotate them on a regular schedule (for example, around every 90 days, which is the default in your component). 
• Keep old keys around for a while so previously issued tokens still validate safely.

You can manage this manually, but it can be surprisingly hard to do in a clean, operationally safe way.

Why “just do it manually” doesn’t work well.

Out of the box, OpenIddict expects you to configure signing credentials yourself – typically by registering certificates or keys in your server configuration.

You quickly run into practical issues:

1. Redeploys for every change
2.  Adding or removing a signing key usually means changing code or configuration and redeploying the server.
3. Limited “built‑in” rotation
4. You can register multiple certificates and let OpenIddict choose between them based on dates, but:
   • You still have to provision and deploy those certs yourself.
   • There’s no scheduler – you decide when to add/remove them.
5. Long‑lived keys hang around
6. It’s tempting to use one certificate for years. That makes deployment easy, but it also means:
   • A bad actor can use a stolen key for a long time.
   • You carry more compliance and audit risk.
7. Operational coordination is painful
8. You need to line up:
   • Token lifetimes
   • Discovery document caching (by clients and gateways)
   • Deprecation of old keys

Doing this correctly across environments, clusters and microservices is precisely the kind of thing humans are bad at, and automation is good at.

OpenIddict Key Rotation: automate the boring (and critical) stuff

The OpenIddict Key Rotation component from Rock Solid Knowledge adds an automatic key lifecycle to OpenIddict. In plain terms, it:

• Generates signing keys for you (RSA or ECDSA).
• Stores and protects them using .NET’s Data Protection system.
• Publishes keys via the JSON Web Key Set (JWKS) endpoint so clients and APIs can validate tokens.
• Rotates keys on a schedule without redeployments.
• Keeps old keys available to validate previously issued tokens.

The result is a “hands‑off” approach: you decide the policy, the component handles the mechanics.

How the rotation lifecycle works

The component drives a simple but powerful lifecycle, controlled by the KeyRotationOptions you configure. 

At a high level:

1. Check interval (CheckInterval)
   • How often does the component check whether a new key is needed?
   • Default: every 2 hours.
2. Publish window (KeyPublishTime)
   • A new key appears in the JWKS document, but has not yet been used to sign tokens.
   • Gives clients time to refresh discovery and cache the new key before it starts signing tokens.
   • Default: 7 days.
3. Active lifetime (KeyLifetime)
   • The period during which a key actually signs tokens.
   • Default: 90 days, providing a good balance between security and operations.
4. Retirement window (KeyRetirementTime)
   • After a key stops signing new tokens, it still appears in JWKS, so old tokens continue to validate.
   • Default: 7 days.

Taken together, these phases mean:

• New keys are available for use before validation failures occur.
• Old keys are kept long enough to cover token lifetimes and caches.
• You get continuous rotation with no “all clients must update NOW” moment.