Postmortem voor het authenticatie-incident op 8 januari 2026 (PST).
Datum: 8 januari 2026 (PST)
Duur: ~60 minuten
Impact: sommige productie-tenantgebruikers ondervonden problemen met aanmelden en tokenvalidatie; Console-aanmelding kon worden beïnvloed
Een mismatch tussen een gedraaide ondertekeningssleutel en een gecachte JWKS op ons *.logto.io-domein veroorzaakte tokenvalidatiefouten. We hebben de JWKS-cache gewist en teruggeschakeld naar de vorige ondertekeningssleutel om de dienst te herstellen.
Sommige gebruikers kunnen nog steeds aanmeldproblemen bij de Console ervaren door browsercache. Onze excuses voor de veroorzaakte verstoring.
Tijdens het incidentvenster konden sommige gebruikers niet aanmelden en mislukte de validatie van sommige tokens. Dit trof meerdere productie-tenants en kon ook toegang tot de Logto Console blokkeren.
We hebben geen bewijs gezien van ongeautoriseerde toegang in verband met dit incident; de impact was beperkt tot authenticatiefouten.
Als je nog steeds niet kunt aanmelden bij de Logto Console, probeer dan:
*.logto.app). JWKS-caching stond per ongeluk nog steeds aan op ons Cloud-domein (*.logto.io).*.logto.io gecachet werden, bleven sommige clients een verouderde JWKS gebruiken en konden ze nieuwe tokens niet valideren.*.logto.io gewist, teruggeschakeld naar de vorige ondertekeningssleutel, en daarna opnieuw de JWKS-cache gewist om zeker te zijn dat clients de teruggezette sleutels oppakten.Sleutelrotatie is niet alleen een taak voor sleutelbeheer. Het is een end-to-end compatibiliteitswijziging die rekening moet houden met cachegedrag tussen uitgevers en validators. Configuratiedrift over domeinen heen (*.logto.app vs *.logto.io) is een reëel risico. Wijzigingen die veilig zijn voor het ene domein, kunnen een ander domein breken als ze niet consequent worden toegepast.
Onze bestaande integratietests dekten het productieachtige JWKS-cachegedrag niet, waardoor deze faalmogelijkheid niet zichtbaar werd voor de rotatie.
We implementeren: