Comment je débogue JWT kid et la sélection de clés JWKS

Quand je vois kid not found, un identifiant de clé inconnu ou une signature qui casse après une rotation, je commence par le header. kid sert généralement d'indice pour sélectionner une clé dans un JWK Set de confiance.

Mon but n'est pas de trouver n'importe quelle clé qui fait passer le test. Je veux démontrer que j'ai choisi la bonne clé du bon issuer avec un algorithme explicitement autorisé par l'application.

Avec un JWT et un JWKS, j'utilise d'abord JWKS Validator.

Étape 1 : lire kid

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "2026-09-key-03"
}

RFC 7515 et RFC 7517 définissent kid comme Key ID. Il est particulièrement utile pendant une rotation de clés.

Je le traite comme une aide à la sélection, jamais comme une preuve de confiance. Un token non vérifié peut choisir n'importe quelle valeur.

Étape 2 : chercher dans un JWKS de confiance

{
  "keys": [
    { "kty": "RSA", "kid": "2026-09-key-03", "use": "sig", "alg": "RS256", "n": "...", "e": "AQAB" },
    { "kty": "RSA", "kid": "2026-06-key-02", "use": "sig", "alg": "RS256", "n": "...", "e": "AQAB" }
  ]
}

Je ne cherche pas le même kid sur Internet. Les Key IDs ne sont pas globalement uniques.

Ma chaîne de confiance :

issuer configuré
      ↓
metadata de confiance
      ↓
jwks_uri de confiance
      ↓
JWK Set
      ↓
correspondance kid

Étape 3 : l'absence de kid n'est pas toujours invalide

Tous les JWT signés n'ont pas besoin de kid.

Si le JWKS de confiance contient exactement une clé compatible, la politique peut permettre une sélection non ambiguë.

S'il en contient plusieurs et que kid manque, je n'utilise pas une stratégie « essayons toutes les clés jusqu'à ce qu'une passe » sans règle déterministe.

JWKS Validator signale ce cas comme ambigu.

Étape 4 : contrôler alg, kty, use, key_ops

Une correspondance de kid n'est pas la fin.

Je vérifie :

• JWT alg ;
• JWK kty ;
• JWK alg si présent ;
• use si présent ;
• key_ops si présent.

RS256 attend une clé RSA ; ES256 une clé EC compatible. Une clé explicitement use: "enc" n'est pas mon choix pour vérifier une signature JWS.

Étape 5 : kid not found me mène souvent à la rotation et au cache

issuer publie A
→ les tokens utilisent A
→ issuer ajoute B
→ les nouveaux tokens utilisent kid B
→ le vérificateur garde encore seulement A en cache

Je vérifie :

1. B est-il publié maintenant ?
2. Quel est le TTL du cache ?
3. Une absence de kid déclenche-t-elle un rafraîchissement contrôlé ?
4. Suis-je sur le bon environnement et le bon tenant ?

Je ne remplace pas le cache par une requête réseau pour chaque token.

Étape 6 : vérifier environnement et tenant

JWT iss:    https://login.dev.example.com/
API trusts: https://login.example.com/

explique facilement un kid not found.

Je demande donc « où est cette clé ? » et « ce token vient-il de l'issuer de confiance attendu ? ».

Étape 7 : ne pas suivre jku/x5u automatiquement

Ces URLs sont contrôlées par l'entrée. RFC 8725 avertit contre les problèmes SSRF et de confiance.

Le JWKS Validator charge uniquement une URL que je saisis explicitement.

Étape 8 : trouver kid n'est pas vérifier la signature

kid trouvé             ✓
algorithme compatible  ✓
clé prévue pour signer ✓
signature vérifiée     ✓ / ✕

Si le dernier point échoue, je passe au guide sur la signature invalide.

Étape 9 : après la signature, valider les claims

Je contrôle encore iss, aud, exp, nbf, le type de token et les permissions.

Ma checklist kid

1. Décoder le JWT, lire alg, kid, iss.
2. Identifier l'issuer de confiance.
3. Obtenir son JWKS de confiance.
4. Chercher une correspondance exacte de kid.
5. Contrôler kty, alg, use, key_ops.
6. Si la clé manque, examiner rotation et cache.
7. Vérifier environnement et tenant.
8. Ne pas faire confiance aux URLs de clés contrôlées par le token.
9. Vérifier la signature avec la JWK sélectionnée.
10. Valider issuer, audience et temps.

L'idée clé : kid m'aide à trouver une clé ; il n'explique pas pourquoi je dois lui faire confiance.