Svenska
  • efteranalys

Efteranalys: autentiseringsfel orsakade av JWKS-cache och nyckelrotation för signering

Efteranalys för autentiseringsincidenten den 8 januari 2026 (PST).

Gao
Gao
Founder

Sluta slösa veckor på användarautentisering
Lansera säkra appar snabbare med Logto. Integrera användarautentisering på några minuter och fokusera på din kärnprodukt.
Kom igång
Product screenshot

Datum: 8 jan 2026 (PST)

Varaktighet: ~60 minuter

Påverkan: vissa produkthyresgäster upplevde inloggnings- och tokenvalideringsfel; Console-inloggning kan ha påverkats

Sammanfattning

En mismatch mellan en roterad signeringsnyckel och en cachad JWKS på vår *.logto.io-domän orsakade valideringsfel för tokens. Vi rensade JWKS-cachen och återställde den tidigare signeringsnyckeln för att återställa tjänsten.

Vissa användare kan fortfarande se problem med Console-inloggning på grund av webbläsarcache. Vi ber om ursäkt för den störning detta orsakat.

Tidslinje (PST)

  • 16:00 incidenten startade (ökning av auth/token-valideringsfel)
  • 16:35 grundorsak identifierad (JWKS cachad medan signeringsnyckel roterades)
  • 16:41 cache rensad
  • 16:49 signeringsnyckel återställd
  • 17:00 tjänsten återställd; fortsatt övervakning

Incidentdetaljer

Påverkan

Under incidentens varaktighet kunde vissa användare inte logga in och vissa tokenvalideringar misslyckades. Detta påverkade flera produkthyresgäster och kunde även blockera åtkomst till Logto Console.

Vi har inte sett några bevis på obehörig åtkomst relaterad till denna incident; påverkan var begränsad till autentiseringsfel.

Åtgärd för kunder

Om du fortfarande inte kan logga in på Logto Console, prova att:

  • öppna ett inkognito-/privat fönster, eller
  • rensa/inaktivera din webbläsarcache och försök igen

Vad hände

  1. Vi uppdaterade JWKS-cacheinställningarna för kundernas hyresdomäner (*.logto.app). JWKS-caching var av misstag fortfarande aktiverad på vår Cloud-domän (*.logto.io).
  2. Vi roterade signeringsnyckeln för vår Cloud-tjänst. Eftersom JWKS-svaren för *.logto.io var cachade fortsatte vissa klienter att använda en föråldrad JWKS och kunde inte validera nyligen utfärdade tokens.
  3. Vi rensade JWKS-cachen för *.logto.io, återställde till den tidigare signeringsnyckeln och rensade JWKS-cachen igen för att säkerställa att klienterna plockade upp den återställda nyckeluppsättningen.
  4. Autentiseringen återställdes. Vissa användare kan fortfarande uppleva inloggningsproblem i Console på grund av webbläsarcache.

Lärdomar

Nyckelrotation är inte bara en nyckelhanteringsuppgift. Det är en ändring som kräver änd-till-änd-kompatibilitet och måste ta hänsyn till cachebeteendet mellan utfärdare och validerare. Konfigurationsdrift mellan domäner (*.logto.app kontra *.logto.io) är en faktisk risk. Ändringar som är säkra för en domän kan bryta en annan om de inte tillämpas konsekvent.

Våra befintliga integrationstester täckte inte JWKS-cachebeteende likt produktion, så detta fel scenario testades inte innan rotationen.

Förebyggande åtgärder

Vi implementerar:

  • ogiltigförklaring av JWKS-cache som ett obligatoriskt steg i flödet för signeringsnyckelrotation (rotera endast efter att ogiltigförklaringen slutförts)
  • hålla JWKS-cache inaktiverad tills ogiltigförklaringsflödet är på plats, sedan återaktivera caching för prestanda
  • integrationstester liknande produktion för nyckelrotation, inklusive JWKS-cachebeteende och kontroller för cache ogiltigförklaring