07. Discovery, cache JWKS et rotation

Comprendre le mécanisme

La découverte OpenID Connect permet d’obtenir des métadonnées d’un fournisseur attendu, dont une localisation de clés. Elle ne rend pas fiable un issuer choisi librement par un token. La relation entre configuration locale, issuer exact et métadonnées doit être vérifiée avec TLS et des limites réseau. Les caches de métadonnées possèdent un cycle distinct de celui des jetons.

Raisonner et vérifier

Une rotation normale peut publier une nouvelle clé avant son utilisation et conserver temporairement les anciennes clés nécessaires aux tokens encore acceptés. Une compromission demande une autre stratégie, liée au délai de révocation admis. Prévoyez cache expiré, fournisseur indisponible et identifiant inconnu avec actualisation bornée. La disponibilité ne doit pas entraîner une acceptation sans vérification.

Fournisseur configuré

La découverte part d’un fournisseur attendu. La confiance précède les métadonnées téléchargées. La découverte part d’une identité attendue et admise. Un token ne doit pas pouvoir faire accepter un nouvel émetteur simplement en annonçant son URL et des métadonnées cohérentes avec lui-même.

Canal vérifié

Le TLS de récupération doit être vérifié. Les métadonnées doivent venir du pair attendu. Le téléchargement des métadonnées et des clés doit vérifier TLS et la destination. Une récupération réussie avec validation désactivée permettrait à un intermédiaire de remplacer la base de confiance.

Publication préalable

Une nouvelle clé peut être publiée avant son usage. Les consommateurs doivent pouvoir obtenir la clé utile. Publiez K2 avant de commencer à signer avec elle. Les consommateurs peuvent ainsi actualiser leurs caches ; testez la chronologie au lieu de supposer que toute distribution est instantanée.

Chevauchement normal

Les anciennes clés peuvent rester pendant une transition définie. Le calendrier dépend des tokens encore acceptés. Gardez K1 le temps nécessaire aux tokens encore valides selon la politique. Reliez cette durée à leur expiration et aux tolérances, puis retirez-la lorsque la transition prévue est terminée.

Incident distinct

Une compromission peut exiger une autre chronologie. Le risque et le retrait demandé diffèrent. Une compromission de K1 peut imposer un retrait plus rapide que la rotation normale. Prévoyez invalidation de cache et communication opérationnelle, en acceptant les conséquences de refus nécessaires selon le risque.

Actualisations bornées

Les actualisations doivent être bornées. La récupération est aussi une surface de consommation. Fixez délais réseau, taille maximale et fréquence de rafraîchissement. Un fournisseur lent ou une rafale de références inconnues ne doit pas monopoliser tous les workers de l’API.

Disponibilité et confiance

Le cache peut améliorer la disponibilité sans supprimer la validation. L’absence de clé utilisable ne prouve pas l’authenticité. Une clé encore admise en cache peut permettre de continuer selon la politique. Sans aucune clé valide disponible, refusez ; une panne du fournisseur ne justifie pas l’acceptation sans preuve.

Métadonnées cohérentes

Les métadonnées doivent correspondre au fournisseur configuré. Les relations d’issuer et de destination doivent rester contrôlées. Vérifiez les champs qui lient configuration et fournisseur attendu. Une adresse JWKS présente dans un document quelconque ne devient pas automatiquement une source autorisée pour votre API.

Chronologie testée

Une chronologie de test doit couvrir les deux clés. Le chevauchement et le retrait doivent être observés. Essayez tokens K1 et K2 avant publication, pendant chevauchement et après retrait. Contrôlez également une instance qui conserve un cache ancien pour mesurer la propagation réelle.

Consommateurs observés

Un incident doit mesurer les consommateurs réels. Les caches et déploiements peuvent conserver des états différents. L’émission avec K2 ne démontre pas le retrait de K1 partout. Vérifiez API, workers et services partenaires inclus dans le périmètre et consignez le délai de refus observé.

Atelier guidé : lire, expliquer et vérifier le code

t0: JWKS publie K1 + K2
 t1: l’émetteur commence à signer avec K2
 t2: K1 est retirée selon la politique de durée

L’ordre t0 puis t1 prépare les vérificateurs avant l’émission de tokens K2. Le retrait de K1 à t2 suit la durée définie pour la transition normale. Rejouez le scénario avec un cache lent puis distinguez la procédure exceptionnelle nécessaire si K1 est compromise.

La rotation ne retire pas ces exigences. Ce calendrier normal ne prouve pas l’absence d’incident. La distribution prépare la transition des vérificateurs. Seuls les paramètres publics doivent être distribués ainsi.

Travail pratique : Simulez deux versions du jeu de clés et une panne de récupération pendant la transition.

Critères de correction : Vérifiez l’acceptation attendue de K1/K2 sur une chronologie fixée, le nombre borné de récupérations et le refus en l’absence de clé utilisable.