Post-mortem para o incidente de autenticação em 8 de janeiro de 2026 (PST).
Data: 8 de janeiro de 2026 (PST)
Duração: ~60 minutos
Impacto: alguns locatários de produção tiveram falhas no login e na validação de tokens; o login no Console pode ter sido afetado
Um descompasso entre uma chave de assinatura rotacionada e um JWKS em cache no nosso domínio *.logto.io causou falhas na validação de tokens. Limpamos o cache do JWKS e voltamos para a chave de assinatura anterior para restaurar o serviço.
Alguns usuários ainda podem encontrar problemas para entrar no Console devido ao cache do navegador. Pedimos desculpas pela interrupção causada.
Durante o período do incidente, alguns usuários não conseguiram fazer login e algumas validações de tokens falharam. Isso afetou vários locatários de produção e também poderia bloquear o acesso ao Console do Logto.
Não vimos nenhuma evidência de acesso não autorizado relacionado a esse incidente; o impacto ficou restrito a falhas de autenticação.
Se você ainda não consegue acessar o Console do Logto, tente:
*.logto.app). O cache de JWKS foi inadvertidamente mantido ativo em nosso domínio Cloud (*.logto.io).*.logto.io estavam em cache, alguns clientes continuaram usando um JWKS desatualizado e não conseguiram validar tokens recém-emitidos.*.logto.io, revertendo para a chave de assinatura anterior, e limpamos novamente o cache do JWKS para garantir que os clientes recebessem o conjunto de chaves revertido.A rotação de chave não é apenas uma tarefa de gerenciamento de chaves. É uma mudança de compatibilidade ponta a ponta que deve considerar o comportamento de cache entre emissores e validadores. Derivações de configuração entre domínios (*.logto.app vs *.logto.io) representam um risco real. Mudanças seguras para um domínio podem quebrar outro se não forem aplicadas de forma consistente.
Nossos testes de integração existentes não cobriam o comportamento de cache de JWKS parecido com produção, então esse modo de falha não foi exercitado antes da rotação.
Estamos implementando: