Анализ инцидента аутентификации от 8 января 2026 года (PST).
Дата: 8 января 2026 года (PST)
Длительность: ~60 минут
Влияние: некоторые производственные арендаторы столкнулись со сбоями при входе и проверке токенов; доступ к Console также мог быть нарушен
Несоответствие между ротированным ключом подписи и кэшированным JWKS на нашем домене *.logto.io привело к сбоям валидации токенов. Мы сбросили кэш JWKS и вернули предыдущий ключ подписи для восстановления работы сервиса.
У некоторых пользователей могут всё ещё наблюдаться проблемы с входом в Console из-за кэша браузера. Приносим извинения за причинённые неудобства.
В течение инцидента некоторые пользователи не могли войти в систему, а часть токенов не проходила валидацию. Это затронуло несколько производственных арендаторов и могло блокировать доступ к Logto Console.
Мы не обнаружили никаких признаков несанкционированного доступа, связанных с этим инцидентом; ущерб ограничился только сбоями аутентификации.
Если у тебя всё ещё не получается войти в Logto Console, попробуй:
*.logto.app). По ошибке кэширование JWKS всё ещё оставалось включённым для нашего облачного домена (*.logto.io).*.logto.io были закэшированы, некоторые клиенты продолжили использовать устаревший JWKS и не могли валидировать новые токены.*.logto.io, вернули предыдущий ключ подписи, затем снова очистили кэш JWKS, чтобы удостовериться, что клиенты получили обновлённый ключ.Ротация ключей — это не только задача управления ключами, но и комплексное изменение совместимости, которое должно учитывать поведение кэширования между эмитентами и валидаторами. Несогласованность конфигураций между доменами (*.logto.app и *.logto.io) представляет реальный риск. Изменения, безопасные для одного домена, могут привести к сбоям на другом, если применяются неравномерно.
Наши существующие интеграционные тесты не покрывали кэширование JWKS в условиях, приближённых к продакшену, поэтому данный сценарий сбоя не был отработан до ротации ключа.
Мы внедряем: