O Logto v1.42.0 traz arquivos de verificação de domínio personalizado, listas de permissões de e-mail com padrões curinga, links mágicos para redefinição de senha, um webhook Grant.LimitExceeded e uma atualização na camada de protocolo com node-oidc-provider v9, Koa 3 e proteção SSRF ativada por padrão.
SimengDeveloper
Pare de perder semanas com autenticação de usuários
Lance aplicativos seguros mais rapidamente com o Logto. Integre a autenticação de usuários em minutos e concentre-se no seu produto principal.
Logto v1.42.0 é um lançamento focado em domínios e protocolos. Ele oferece às equipes uma maneira de provar a propriedade de domínio sem precisar levantar outro host, maior controle sobre quais e-mails podem acessar um tenant e um processo de redefinição de senha mais suave para os usuários finais. Sob o capô, o Logto passa a usar node-oidc-provider v9 e Koa 3, além de ativar a proteção SSRF para solicitações OIDC de saída por padrão. Veja as novidades:
Serviços de terceiros muitas vezes verificam a propriedade do domínio solicitando que você sirva um pequeno arquivo em um caminho fixo. Até agora, isso significava executar um host separado junto do seu domínio personalizado no Logto.
Agora é possível anexar arquivos de verificação a um domínio personalizado ativo em Console > Configurações do tenant > Domínios. Cada arquivo possui:
Um caminho que pode ser um nome de arquivo na raiz com extensão (por exemplo, /verify.txt) ou um caminho sob /.well-known/.
Um tipo de conteúdo text/plain ou application/json. O conteúdo JSON é validado ao salvar.
Conteúdo de até 16 KB.
É possível configurar até 10 arquivos por domínio, e os caminhos devem ser únicos. O Logto atende exatamente às correspondências GET e HEAD com o tipo de conteúdo configurado e endurecimento da resposta. As rotas já existentes do Logto sempre têm prioridade sobre um arquivo de verificação no mesmo caminho, garantindo que um arquivo configurado incorretamente nunca substitua um endpoint real. A experiência no Console é localizada em todos os idiomas suportados.
Como o Logto não interfere no conteúdo dos arquivos, ele funciona com qualquer esquema de verificação de provedor sem que o Logto precise modelar comportamentos específicos de cada um.
Regras de acesso por e-mail: allowlist e padrões curinga#
A política de bloqueio de e-mails evoluiu para um conjunto mais completo de regras de acesso por e-mail, configuráveis em Console > Segurança > Lista de bloqueio de e-mail.
Lista de permissões personalizada. Configure uma lista de permissões de endereços de e-mail, domínios ou padrões curinga. Quando a allowlist está definida, apenas e-mails correspondentes são aceitos para novos cadastros e novos vínculos de e-mail — tanto para registro por e-mail quanto para atualizações de e-mail na conta.
Padrões curinga. Tanto a allowlist quanto a blocklist aceitam padrões de endereço e domínio com curinga, como foo*@example.com, *@example.com e @*.example.com, além de endereços exatos ([email protected]) e domínios (@example.com).
Avisos de conflito. O Console avisa quando uma entrada da allowlist também corresponde a uma regra de bloqueio, quando uma entrada usa sinal de mais enquanto subendereçamento de e-mail está bloqueado e quando as regras combinadas não permitiriam a entrada de nenhum novo e-mail.
A lógica de correspondência e validação é compartilhada por helpers reutilizáveis em @logto/core-kit, garantindo que as mesmas regras se apliquem em todos os pontos de entrada de e-mail de um tenant.
O aplicativo Experience agora suporta fluxos de redefinição de senha que validam links mágicos de uso único diretamente a partir da página de destino da redefinição de senha, além dos códigos de verificação.
Quando concessões OIDC são revogadas porque um aplicativo excedeu o limite máximo de concessões permitidas, o Logto agora aciona um evento webhook Grant.LimitExceeded, selecionável nas configurações de webhooks do Console como qualquer outro evento.
O payload informa userId, applicationId, revokedGrantIds, maxAllowedGrants e preRevocationActiveGrantCount. O envio é fire-and-forget: falhas são registradas como entradas de log de auditoria em TriggerHook.Grant.LimitExceeded e nunca bloqueiam a resposta de autenticação.
Provedor OIDC atualizado para node-oidc-provider v9#
A maior mudança aqui é uma correção de segurança na revogação de tokens.
Revogar um token opaco de acesso agora também revoga todos os tokens sob a mesma concessão, incluindo o refresh token. Na v8, o refresh token permanecia utilizável após a revogação e podia continuar solicitando novos access tokens.
Outras atualizações de protocolo na v9:
O endpoint de revogação agora rejeita access tokens JWT com unsupported_token_type, em vez de retornar sucesso sem revogar nada, como na v8.
O endpoint de metadados do servidor de autorização RFC 8414 está disponível em /oidc/.well-known/oauth-authorization-server.
O claim redundante at_hash foi removido dos ID tokens emitidos no endpoint de token.
Os ID tokens não incluem mais o cabeçalho opcional typ: "JWT". OpenID Connect define ID tokens como JWTs e não exige que clientes verifiquem esse header.
Ação necessária para verificação de ID token personalizada. Não é necessário fazer nada se você estiver usando um SDK oficial Logto. Se sua integração realiza verificação personalizada de ID tokens, atualize-a para permitir ausência do claim at_hash e do header typ: "JWT".
O Logto agora roda em Koa 3, a linha de lançamento ativamente mantida e que recebe primeiro as correções de segurança do Koa. Nenhuma mudança de comportamento é esperada: todos os endpoints, fluxos OIDC e respostas de API se comportam exatamente como antes.
Segredos internos de aplicativos não são mais expostos via APIs de Gerenciamento.
A política de bloqueio de e-mail não é mais retornada em respostas públicas da experiência de login.
Recuperar tokens de acesso de provedores terceiros salvos via Account API agora exige o escopo de usuário identities, igual aos outros endpoints sociais e SSO empresarial.
Códigos de verificação da Account API não são mais enviados para endereços de e-mail bloqueados.
Validação de e-mail e domínio agora exige valores completos e reforça labels de domínio mais rígidos.
Correções para experiência, armazenamento e estabilidade#
Quando o fluxo de cadastro social ou SSO é rejeitado por regras de acesso por e-mail, ao reconhecer o erro o usuário agora retorna para a página de login do Logto ao invés de voltar ao provedor de identidade externa.
MFA é agora ativada automaticamente após o usuário vincular um fator via Account APIs.
Criar um novo conector de e-mail ou SMS executa a inserção e a limpeza dos antigos em uma única transação de banco de dados. Antes, uma falha entre os dois comandos podia deixar conectores duplicados.
As credenciais de cluster Redis agora são decodificadas por cento, permitindo conexões quando o usuário ou senha contêm caracteres reservados de URL.
O TLS está habilitado corretamente para conexões Redis cluster que usam o protocolo rediss.
jose v6: Os conectores Apple, Google, OAuth e OIDC agora usam jose 6, baseado na Web Crypto API em vez do módulo crypto do Node. A assinatura e verificação de tokens ID continuam funcionando igual antes.
GitLab: Removida a dependência jose não utilizada, evitando instalação de um pacote nunca importado.
Aliyun SMS: Números de telefone de Hong Kong agora são tratados como números internacionais.
Serviço de autenticação Aliyun SMS (MAS): A assinatura agora é inserida como texto livre em vez de um dropdown, garantindo funcionamento caso a Aliyun altere as assinaturas novamente.
Ação necessária — proteção SSRF do provedor OIDC. A segurança das requisições de saída foi reforçada e a proteção SSRF está ativada por padrão. Implantações self-hosted que precisam acessar endpoints trusted relying-party em redes privadas devem definir OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true antes de iniciar o Logto; caso contrário, deixe a variável sem valor.
Migração de banco de dados obrigatória. Esta versão traz alterações no schema para arquivos de verificação de domínio personalizado, além de índices e tabelas internas. Após a atualização, execute o comando de alteração do banco de dados (npm run alteration deploy na imagem @logto/cli/core, ou logto db alteration deploy) antes de iniciar a nova versão. Veja o guia de atualização para detalhes.
Verificação personalizada de ID token. Veja a seção acima sobre node-oidc-provider v9 para as mudanças em at_hash e cabeçalho typ.
