Post-mortem : échecs d'authentification causés par la mise en cache de JWKS et la rotation de la clé de signature

Date : 8 janvier 2026 (PST)

Durée : ~60 minutes

Impact : certains locataires en production ont rencontré des échecs de connexion et de validation de jetons ; la connexion à la Console pouvait également être affectée

Résumé#

Un décalage entre une clé de signature tournée et un JWKS mis en cache sur notre domaine *.logto.io a provoqué des échecs de validation de jeton. Nous avons vidé le cache JWKS et sommes revenus à la clé de signature précédente pour rétablir le service.

Certains utilisateurs peuvent encore rencontrer des problèmes de connexion à la Console à cause du cache du navigateur. Nous sommes désolés pour la perturbation causée.

Chronologie (PST)#

• 16h00 début de l'incident (hausse des erreurs de validation des jetons/auth)
• 16h35 cause principale identifiée (JWKS mis en cache alors que la clé de signature avait été tournée)
• 16h41 cache vidé
• 16h49 retour à la clé de signature précédente
• 17h00 service rétabli ; surveillance continue

Détails de l’incident#

Impact#

Pendant la période de l’incident, certains utilisateurs ne pouvaient plus se connecter et certaines validations de jetons échouaient. Cela a affecté plusieurs locataires en production et pouvait également empêcher l'accès à la Console Logto.

Nous n'avons trouvé aucune preuve d'accès non autorisé lié à cet incident ; l’impact s’est limité aux échecs d’authentification.

Action client#

Si tu ne peux toujours pas te connecter à la Console Logto, essaie :

• d’ouvrir une fenêtre de navigation privée/incognito, ou
• de vider/désactiver le cache de ton navigateur, puis réessayer

Que s’est-il passé#

1. Nous avons mis à jour les paramètres de mise en cache JWKS sur les domaines locataires des clients (*.logto.app). La mise en cache JWKS était par erreur encore activée sur notre domaine Cloud (*.logto.io).
2. Nous avons tourné la clé de signature pour notre service Cloud. Comme les réponses JWKS pour *.logto.io étaient en cache, certains clients utilisaient encore un JWKS obsolète et ne pouvaient pas valider les nouveaux jetons émis.
3. Nous avons vidé le cache JWKS pour *.logto.io, sommes revenus à la clé de signature précédente, puis vidé à nouveau le cache JWKS pour garantir que les clients utilisent bien le jeu de clés reverti.
4. L’authentification a été rétablie. Certains utilisateurs peuvent encore voir des soucis de connexion Console à cause du cache navigateur.

Enseignements#

La rotation de clé n’est pas qu’une tâche de gestion des clés. C’est un changement de compatibilité de bout en bout qui doit prendre en compte les mécanismes de mise en cache entre les émetteurs et les validateurs. La dérive de configuration entre les domaines (*.logto.app vs *.logto.io) constitue un vrai risque. Un changement sûr pour un domaine peut casser un autre s’il n’est pas appliqué de manière cohérente.

Nos tests d’intégration existants ne couvraient pas le comportement de mise en cache JWKS en production, donc ce scénario d’échec n’a pas été rencontré avant la rotation.

Actions préventives#

Nous mettons en place :

• l’invalidation du cache JWKS comme étape obligatoire dans le processus de rotation de la clé de signature (ne tourner la clé qu’après l’invalidation complétée)
• garder la mise en cache JWKS désactivée jusqu’à l’implémentation du flux d’invalidation, puis re-activer la mise en cache pour la performance
• des tests d’intégration reproduisant la production pour la rotation de clé, y compris le comportement de cache JWKS et les contrôles d’invalidation du cache