Comment je débogue JWT key rotation sans casser la vérification

Quand la vérification JWT commence à échouer autour d'un changement de signing key, je traite le problème comme un key lifecycle problem, pas seulement comme invalid signature. Le token et le verifier peuvent être corrects individuellement ; le défaut peut se trouver dans la transition old/new, la sélection kid ou le cache JWKS.

Ma question centrale est :

Le verifier peut-il encore trouver et faire confiance à la clé qui a signé ce token pendant la durée de vie restante du token ?

Avec JWT et current key set, je démarre dans JWKS Validator.

Étape 1 : lire kid, issuer et expiration

{
  "alg": "RS256",
  "kid": "signing-key-2026-09"
}

{
  "iss": "https://login.example.com/",
  "exp": 1789203600
}

Je veux immédiatement savoir : qui doit posséder la key, quel kid est demandé et combien de temps le token doit encore pouvoir être vérifié.

Étape 2 : comparer le current JWKS au kid

Pendant un rollover normal, old/new public keys peuvent coexister :

{
  "keys": [
    { "kid": "signing-key-2026-06", "kty": "RSA", "alg": "RS256", "use": "sig" },
    { "kid": "signing-key-2026-09", "kty": "RSA", "alg": "RS256", "use": "sig" }
  ]
}

Si un old token est encore valide mais sa key a disparu, je vérifie si elle a été retirée trop tôt ou si j'inspecte le mauvais issuer/environment.

Étape 3 : distinguer planned rollover et emergency revocation

Lors d'une rotation planifiée, je garde généralement l'ancienne verification key assez longtemps pour que les tokens déjà émis arrivent à expiration.

Après compromise, conserver l'ancienne key peut au contraire être dangereux. Des tokens encore non expirés peuvent devoir devenir invalid immédiatement.

La raison de la rotation détermine donc la policy de transition.

Étape 4 : vérifier le cache JWKS

Je contrôle :

• TTL ;
• refresh sur unknown kid ;
• caches supplémentaires gateway/framework ;
• instances avec cache différent ;
• CDN/proxy stale ;
• error path qui conserve trop longtemps l'ancien set.

Un kid miss peut déclencher un refresh contrôlé depuis la trusted JWKS location, pas depuis une URL arbitraire du token.

Étape 5 : la nouvelle key doit appartenir au même Trusted Issuer

expected issuer
      ↓
trusted metadata/config
      ↓
trusted JWKS
      ↓
matching kid
      ↓
compatible JWK
      ↓
signature verification

Je ne considère pas un staging key set comme une solution pour un production token.

Étape 6 : contrôler les metadata de key

Même avec un kid identique, je contrôle kty, alg, use et key_ops. L'algorithm allowlist vient de la configuration de l'application.

Étape 7 : comparer rotation timing et token lifetime

11:59 token signé avec old key
12:00 new signing key actif
12:01 old public key retiré
12:30 old token encore valide 29 minutes

Pour une rotation planifiée, cela crée une fenêtre de panne.

La durée de coexistence dépend du maximum token lifetime, du cache et d'un buffer opérationnel.

Étape 8 : tester un old token et un new token

Je vérifie les deux contre le current trusted JWKS. Cela permet de séparer missing old key, missing new key, stale cache, wrong issuer et un problème de signature général.

Pour kid not found, j'utilise aussi la guide JWT kid.

Je ne désactive pas verification pendant le rollout

Si la new key n'est pas disponible, je corrige publication, distribution ou cache. Je ne change pas le security model en acceptant temporairement des tokens non vérifiés.

Mon modèle de rollover sain

1. Publier la new public key dans le trusted JWKS
2. Conserver l'old public key
3. Commencer à signer avec new private key / kid
4. Les verifiers acceptent old et new
5. Attendre la fin de l'old-token acceptance window
6. Retirer l'old key selon la policy

Ma checklist key rotation

1. Lire iss, alg, kid, exp.
2. Confirmer expected issuer.
3. Inspecter current trusted JWKS.
4. Chercher le token kid.
5. Vérifier kty, alg, use, key_ops.
6. Tester dans JWKS Validator.
7. Vérifier cache age/refresh.
8. Comparer token lifetime et key availability.
9. Distinguer rollover et emergency revocation.
10. Garder signature verification active.

Pour moi, key rotation consiste à coordonner token lifetime, publication des public keys, key selection, cache refresh et issuer trust, pas seulement à remplacer une private key.