Postmortem : changement inattendu de `iss` dans JWT

Résumé#

Le 2024-03-18, une mise à jour modifiant le comportement de l'émetteur JWT dans Logto Cloud a perturbé les flux d'authentification pour les utilisateurs avec des domaines personnalisés et une validation iss. La correction a nécessité que ces utilisateurs mettent à jour leur logique de validation.

• Utilisateurs affectés : utilisateurs ayant activé des domaines personnalisés et effectuant une validation iss.
• Gravité : Critique, rupture de la validation iss dans les flux d'authentification.

Cause principale#

La mise à jour a changé le champ iss pour qu'il corresponde au domaine demandé, perturbant les validations existantes qui attendaient l'ancien émetteur par défaut.

Chronologie#

• 2024-03-18 10:00 (UTC) : mises à jour déployées, modifiant le comportement de iss.
• 2024-03-18 23:30 (UTC) : premier rapport utilisateur reçu concernant le comportement existant défaillant.
• 2024-03-19 12:00 (UTC) : confirmation du problème et début de l'enquête.
• 2024-03-19 14:00 (UTC) : identification de la cause principale et de l'impact.
• 2024-03-20 20:00 (UTC) : préparation de l'email aux utilisateurs affectés.
• 2024-03-20 06:00 (UTC) : envoi des emails à tous les utilisateurs concernés.

Analyse d'impact#

Détails de la mise à jour#

Logto Cloud supporte les domaines personnalisés pour l'authentification, les développeurs ayant des locataires activés sur domaine personnalisé peuvent configurer le point d'accès au domaine personnalisé dans les SDKs, puis l'utilisateur final utilisera ce point d'accès pour initialiser le processus d'authentification et obtenir des jetons. Certains jetons sont sous forme JWT, qui inclut un champ iss indiquant l'émetteur de ce jeton. Auparavant, même lorsqu'un point d'accès de domaine personnalisé était utilisé pour demander un jeton d'accès, l'émetteur restait par défaut notre domaine standard ([tenant-id].logto.app).

Mais le domaine de l'émetteur devrait être le même que le point d'accès demandé. Nous avons donc publié une mise à jour pour corriger ce problème, et maintenant le champ iss reflétera automatiquement le domaine utilisé dans la requête.

Pour ceux qui utilisent déjà un domaine personnalisé pour accorder des jetons et qui ont implémenté une validation du champ iss dans le serveur de ressources, cela pourrait être un changement perturbateur. La vérification d'authentification existante échouera à cause du changement d'émetteur. Pour résoudre ce problème, les développeurs doivent modifier le code de validation, remplacer l'émetteur attendu par le nouveau avec domaine personnalisé.

Nous n'avons pas su pleinement considérer l'impact sur les validations iss existantes, en conséquence, cette mise à jour est devenue un changement perturbateur sans notification préalable.

Résolution#

Notification des utilisateurs concernés par email, leur conseillant de mettre à jour leur validation iss pour correspondre au domaine demandé.

Rollbacks ?#

Le changement est une correction nécessaire pour le champ émetteur, et certains utilisateurs ont peut-être déjà adapté leur comportement au nouveau fonctionnement. Un retour en arrière causerait de la confusion et de l'incohérence.

Leçons apprises#

• Les modifications de code affectant l'authentification de base doivent avoir l'approbation de l'équipe en plus des révisions régulières.
• Les tests automatiques devraient couvrir plus de cas, notamment dans des scénarios spécifiques au cloud.

Mesures correctives et préventives#

• Ajouter des tests d'intégration : Ajouter des cas de test pour couvrir le scénario dans cet incident.
• Projets de surveillance de fonctionnalités : En plus de Logto Cloud, créer nos propres projets parallèles et s'intégrer profondément avec Logto pour détecter les problèmes potentiels avant les mises à jour.