Échecs de cache JWKS et rotation

JWKS paraît simple sur un schéma: l’émetteur publie des clés, les services les mettent en cache, les jetons sont vérifiés. Les pannes apparaissent dans le timing. Une clé tourne pendant qu’un cache reste ancien. Un nouveau kid arrive avant que toutes les régions aient reçu le JWKS à jour. Un vérificateur rafraîchit à chaque échec et donne sans le vouloir un petit levier de déni de service. Aucun de ces problèmes ne demande de casser un algorithme. Ce sont des systèmes distribués qui se comportent comme des systèmes distribués.

Deux mauvaises politiques de cache

La première mauvaise politique consiste à cacher pour toujours. La rotation normale devient inquiétante, donc les équipes l’évitent jusqu’à l’incident. La seconde consiste à récupérer le JWKS à chaque requête ou à chaque kid inconnu. Les clés restent fraîches, mais l’émetteur entre dans le chemin chaud. Un attaquant peut envoyer des milliers de jetons avec des kid aléatoires et déclencher une tempête de requêtes sortantes si le vérificateur ne limite pas ces ratés.

Un meilleur design garde un TTL normal, sert depuis le cache pendant les petites indisponibilités de l’émetteur et rafraîchit en arrière-plan lorsqu’un nouveau kid apparaît. Un kid inconnu ne devrait déclencher qu’un seul rafraîchissement par émetteur sur une courte fenêtre. Les autres requêtes doivent échouer fermement avec le cache courant, pas attendre une récupération distante.

L’ordre de rotation compte

Publie la nouvelle clé publique avant de signer des jetons avec la nouvelle clé privée. Garde l’ancienne clé publique jusqu’à l’expiration de la durée maximale des jetons plus la dérive d’horloge. Si les access tokens vivent quinze minutes et que certains clients peuvent avoir cinq minutes d’écart, retirer l’ancienne clé après dix minutes crée des rejets légitimes. La chronologie doit inclure propagation CDN, déploiement régional et clients mobiles hors ligne.

Signaux à suivre

Suit les échecs de vérification par émetteur, kid, algorithme et raison. Un pic de unknown kid après déploiement n’a pas la même signification qu’un pic de bad signature. Journalise l’âge du cache et le résultat du rafraîchissement. Pendant un incident, ces deux champs indiquent s’il s’agit d’une clé compromise, d’un mauvais rollout ou d’un chemin réseau cassé vers le JWKS.

Tester les modes de panne

Un pentest doit inclure le comportement avec JWKS périmé, pas seulement des jetons forgés. L’application vérifie-t-elle encore les anciens jetons pendant la rotation? Accepte-t-elle un jeton signé par une clé retirée? Que se passe-t-il si l’endpoint JWKS renvoie 500 ou répond lentement? Les défenseurs doivent répéter la rotation avec un émetteur de staging et des états de cache forcés. Si la première vraie rotation arrive sous pression, le runbook est déjà en retard.