Postmortem: authenticatiefouten veroorzaakt door JWKS-caching en rotatie van ondertekeningssleutels

Datum: 8 januari 2026 (PST)

Duur: ~60 minuten

Impact: sommige productie-tenantgebruikers ondervonden problemen met aanmelden en tokenvalidatie; Console-aanmelding kon worden beïnvloed

Samenvatting#

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.

Tijdlijn (PST)#

• 16:00 incident begon (toename van auth/token validatiefouten)
• 16:35 hoofdoorzaak vastgesteld (JWKS gecachet terwijl de ondertekeningssleutel werd gedraaid)
• 16:41 cache gewist
• 16:49 ondertekeningssleutel teruggezet
• 17:00 dienst hersteld; monitoring voortgezet

Incidentdetails#

Impact#

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.

Actie voor de klant#

Als je nog steeds niet kunt aanmelden bij de Logto Console, probeer dan:

• het openen van een incognito/privevenster, of
• het wissen/uitschakelen van de browsercache en vervolgens opnieuw proberen

Wat is er gebeurd#

1. We werkten de JWKS-cache-instellingen bij voor tenantdomeinen van klanten (*.logto.app). JWKS-caching stond per ongeluk nog steeds aan op ons Cloud-domein (*.logto.io).
2. We hebben de ondertekeningssleutel van onze Cloud-dienst gedraaid. Omdat JWKS-responses voor *.logto.io gecachet werden, bleven sommige clients een verouderde JWKS gebruiken en konden ze nieuwe tokens niet valideren.
3. We hebben de JWKS-cache voor *.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.
4. Authenticatie hersteld. Sommige gebruikers kunnen nog steeds Console-aanmeldproblemen zien door browsercache.

Geleerde lessen#

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.

Preventieve acties#

We implementeren:

• JWKS-cache-invalidatie als verplichte stap in het rotatieproces van de ondertekeningssleutel (sleutel alleen draaien nadat invalidatie voltooid is)
• JWKS-caching uitgeschakeld houden tot de invalidatiefunctie actief is, daarna caching herinschakelen voor prestaties
• productie-achtige integratietests voor sleutelrotatie, inclusief JWKS-cachinggedrag en cache-invalidatiecontroles