Efteranalys för autentiseringsincidenten den 8 januari 2026 (PST).
Datum: 8 jan 2026 (PST)
Varaktighet: ~60 minuter
Påverkan: vissa produkthyresgäster upplevde inloggnings- och tokenvalideringsfel; Console-inloggning kan ha påverkats
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.
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.
Om du fortfarande inte kan logga in på Logto Console, prova att:
*.logto.app). JWKS-caching var av misstag fortfarande aktiverad på vår Cloud-domän (*.logto.io).*.logto.io var cachade fortsatte vissa klienter att använda en föråldrad JWKS och kunde inte validera nyligen utfärdade tokens.*.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.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.
Vi implementerar: