Postmortem for the authentication incident on Jan 8, 2026 (PST).
Date: Jan 8, 2026 (PST)
Duration: ~60 minutes
Impact: some production tenants experienced sign-in and token validation failures; Console sign-in could be affected
A mismatch between a rotated signing key and a cached JWKS on our *.logto.io domain caused token validation failures. We cleared the JWKS cache and reverted to the previous signing key to restore service.
Some users may still see Console sign-in issues due to browser cache. We are sorry for the disruption this caused.
During the incident window, some users could not sign in and some token validations failed. This impacted multiple production tenants and could also block access to the Logto Console.
We have seen no evidence of unauthorized access related to this incident; the impact was limited to authentication failures.
If you still can’t sign in to the Logto Console, please try:
*.logto.app). JWKS caching was mistakenly still enabled on our Cloud domain (*.logto.io).*.logto.io were cached, some clients continued using a stale JWKS and could not validate newly issued tokens.*.logto.io, reverted to the previous signing key, then cleared the JWKS cache again to ensure clients picked up the reverted key set.Key rotation is not just a key management task. It is an end-to-end compatibility change that must account for caching behavior between issuers and validators. Config drift across domains (*.logto.app vs *.logto.io) is a real risk. Changes that are safe for one domain can break another if not applied consistently.
Our existing integration tests did not cover production-like JWKS caching behavior, so this failure mode was not exercised before the rotation.
We are implementing: