Post-mortem : échecs d'authentification causés par la mise en cache de JWKS et la rotation de la clé de signature
Post-mortem de l'incident d'authentification du 8 janvier 2026 (PST).
Post-mortem de l'incident d'authentification du 8 janvier 2026 (PST).
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
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.
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.
Si tu ne peux toujours pas te connecter à la Console Logto, essaie :
*.logto.app). La mise en cache JWKS était par erreur encore activée sur notre domaine Cloud (*.logto.io).*.logto.io étaient en cache, certains clients utilisaient encore un JWKS obsolète et ne pouvaient pas valider les nouveaux jetons émis.*.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.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.
Nous mettons en place :