Obduktionsrapport: oväntad JWT `iss`-ändring

Sammanfattning#

Den 2024-03-18 orsakade en uppdatering av förändrad JWT-utgivarsbeteende i Logto Cloud avbrott i autentiseringsflöden för användare med anpassade domäner och iss-validering. Lösningen krävde att dessa användare uppdaterade sin valideringslogik.

• Påverkade användare: Användare med aktiverade anpassade domäner och utförande av iss-validering.
• Allvarlighetsgrad: Kritisk, vilket bryter iss-valideringen inom autentiseringsflöden.

Grundorsak#

Uppdateringen ändrade iss-fältet för att matcha den begärda domänen, vilket bröt befintliga valideringar som förväntade sig den tidigare standardutgivaren.

Tidslinje#

• 2024-03-18 10:00 (UTC): Uppdateringar distribuerades, förändrade iss-beteendet.
• 2024-03-18 23:30 (UTC): Första användarrapport mottogs om det befintliga beteendet som bröt.
• 2024-03-19 12:00 (UTC): Bekräftade problemet och började undersöka.
• 2024-03-19 14:00 (UTC): Identifierade grundorsaken och påverkan.
• 2024-03-20 20:00 (UTC): Förberedde e-post till påverkade användare.
• 2024-03-20 06:00 (UTC): Skickade e-post till alla påverkade användare.

Påverkansanalys#

Detaljer om utgåvan#

Logto Cloud stöder anpassad domän för autentisering. Utvecklare som har aktiverat anpassade domänhyrare kan ställa in slutpunkten till den anpassade domänen i SDK:er, sedan kommer slutanvändaren att använda denna slutpunkt för att initiera autentiseringsprocessen och få tokens. Vissa tokens är i form av JWT, som inkluderar ett iss-fält som anger utgivaren av denna token. Tidigare, även när en anpassad domänslutpunkt användes för att begära en åtkomsttoken, skulle utgivaren fortfarande vara standardiserad till vår domän ([tenant-id].logto.app).

Men utgivarens domän bör vara densamma som den begärda slutpunkten. Så vi släppte en uppdatering för att fixa detta problem, och nu kommer iss-fältet automatiskt att spegla domänen som används i förfrågan.

För de som redan använder anpassad domän för att bevilja tokens och implementerat iss-validering i resursservern, kan detta vara en brytande ändring. Befintlig autentiseringskontroll kommer att misslyckas på grund av förändringen av utgivaren. För att fixa detta behöver utvecklarna ändra valideringskoden, ersätta den förväntade utgivaren med den nya med anpassad domän.

Vi misslyckades med att fullständigt överväga påverkan på befintliga iss-valideringar, vilket resulterade i att denna utgåva blev en brytande ändring utan tidigare meddelande.

Lösning#

Meddelade påverkade användare via e-post och rådde dem att uppdatera sin iss-validering för att matcha den begärda domänen.

Återställningar?#

Förändringen är en nödvändig fix för utgivarens fält, och vissa användare kan redan ha anpassat sig till det nya beteendet. En återställning skulle orsaka förvirring och inkonsekvens.

Lärdomar#

• Kodändringar som påverkar kärnautentisering måste ha godkännas av teamet utöver vanliga granskningar.
• Automatiska tester bör täcka fler fall, särskilt i molnspecifika scenarier.

Korrigerande och förebyggande åtgärder#

• Lägg till integrationstester: Lägg till testfall för att täcka scenariet i denna incident.
• Funktionövervakningsprojekt: Utöver Logto Cloud, skapa våra egna sidoprojekt och djupt integrera med Logto för att fånga potentiella problem innan utgåvor.