Postmortem: mudança inesperada de `iss` em JWT

Resumo#

A 18-03-2024, uma atualização que alterou o comportamento do emissor de JWT no Logto Cloud interrompeu os fluxos de autenticação para utilizadores com domínios personalizados e validação de iss. A correção exigiu que esses utilizadores atualizassem a sua lógica de validação.

• Utilizadores afetados: utilizadores com domínios personalizados ativados e que realizam validação de iss.
• Gravidade: Crítica, interrompendo a validação de iss dentro dos fluxos de autenticação.

Causa raiz#

A atualização alterou o campo iss para corresponder ao domínio solicitado, interrompendo validações existentes que esperavam o emissor padrão anterior.

Cronologia#

• 18-03-2024 10:00 (UTC): atualizações implementadas, alterando o comportamento de iss.
• 18-03-2024 23:30 (UTC): primeiro relatório de utilizador recebido sobre o comportamento interrompido existente.
• 19-03-2024 12:00 (UTC): problema confirmado e início da investigação.
• 19-03-2024 14:00 (UTC): causa raiz e impacto identificados.
• 20-03-2024 20:00 (UTC): email preparado para os utilizadores afetados.
• 20-03-2024 06:00 (UTC): emails enviados a todos os utilizadores afetados.

Análise de impacto#

Detalhes da atualização#

O Logto Cloud suporta domínios personalizados para autenticação, os desenvolvedores que têm locatários com domínio personalizado ativado podem definir o ponto final para o domínio personalizado nos SDKs, então o usuário final usará este ponto final para iniciar o processo de autenticação e obter tokens. Alguns tokens estão na forma de JWT, que inclui um campo iss indicando o emissor deste token. Anteriormente, mesmo quando um ponto final de domínio personalizado era usado para solicitar um token de acesso, o emissor ainda seria, por padrão, o nosso domínio padrão ([tenant-id].logto.app).

Mas o domínio do emissor deve ser o mesmo que o ponto final solicitado. Então lançámos uma atualização para corrigir este problema, e agora o campo iss refletirá automaticamente o domínio usado no pedido.

Para aqueles que já estão usando um domínio personalizado para conceder tokens e implementaram a validação do campo iss no servidor de recursos, isso poderia ser uma alteração incompatível. A verificação de autenticação existente falhará devido à mudança do emissor. Para corrigir isso, os desenvolvedores precisam alterar o código de validação, substituindo o emissor esperado pelo novo com domínio personalizado.

Falhámos em considerar totalmente o impacto nas validações de iss existentes, como resultado, esta atualização tornou-se uma mudança incompatível sem notificação prévia.

Solução#

Notificámos os utilizadores afetados por email, aconselhando-os a atualizar a sua validação de iss para corresponder ao domínio solicitado.

Reversões?#

A mudança é uma correção necessária para o campo do emissor, e alguns usuários podem já ter se adaptado ao novo comportamento. Uma reversão causaria confusão e inconsistência.

Lições aprendidas#

• As alterações de código que afetam a autenticação central devem ter aprovação pela equipa além das revisões regulares.
• Testes automáticos devem cobrir mais casos, especialmente em cenários específicos da nuvem.

Medidas corretivas e preventivas#

• Adicionar testes de integração: Adicionar casos de teste para cobrir o cenário deste incidente.
• Projetos de monitorização de funcionalidades: Além do Logto Cloud, criar nossos próprios projetos paralelos e integrar profundamente com o Logto para detectar potenciais problemas antes dos lançamentos.