O Logto v1.42.0 traz ficheiros de verificação de domínio personalizado, listas brancas de emails com padrões wildcard, links mágicos para redefinição de palavra-passe, um webhook Grant.LimitExceeded e uma atualização no protocolo com node-oidc-provider v9, Koa 3 e proteção SSRF ativa por defeito.
SimengDeveloper
Pare de perder semanas com autenticação de utilizadores
Lance aplicações seguras mais rapidamente com o Logto. Integre a autenticação de utilizadores em minutos e concentre-se no seu produto principal.
O Logto v1.42.0 é uma versão focada em domínios e protocolos. Oferece às equipas uma forma de provar a posse de domínio sem configurar um novo host, um controlo mais rigoroso sobre que emails podem entrar num tenant e um caminho mais simples para redefinição de palavra-passe para os utilizadores finais. Internamente, o Logto passa a usar node-oidc-provider v9 e Koa 3, ativando a proteção SSRF para pedidos OIDC outbound por defeito. Eis as novidades.
Ficheiros de verificação de domínio personalizado#
Serviços de terceiros frequentemente verificam a posse do domínio pedindo para disponibilizares um pequeno ficheiro num caminho fixo. Até agora, isso exigia correr um host separado ao lado do teu domínio personalizado de Logto.
Agora podes anexar ficheiros de verificação a um domínio personalizado ativo em Console > Definições do tenant > Domínios. Cada ficheiro tem:
Um caminho que pode ser um ficheiro ao nível da 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 guardar.
Conteúdo até 16 KB.
Podem ser configurados até 10 ficheiros por domínio, e os caminhos devem ser únicos. O Logto fornece correspondências exatas em GET e HEAD com o tipo de conteúdo configurado e reforço da resposta. As rotas existentes do Logto têm sempre prioridade sobre um ficheiro de verificação no mesmo caminho, por isso um ficheiro mal configurado nunca poderá esconder um endpoint real. A experiência no Console está localizada para todas as línguas suportadas.
Como o Logto não intervém no conteúdo dos ficheiros, isto funciona para qualquer esquema de verificação de fornecedor sem precisar adaptar o comportamento ao fornecedor.
Regras de acesso ao email: lista branca e padrões wildcard#
A política de lista negra de emails evolui para um conjunto mais completo de regras de acesso ao email, configuráveis em Console > Segurança > Lista negra de email.
Lista branca de email personalizada. Configura uma lista branca de endereços de email, domínios ou padrões wildcard. Quando a lista branca está definida, apenas emails coincidentes são aceites para novos registos e novos emails ligados — tanto no registo de email como nas atualizações do email da conta.
Padrões wildcard. Tanto a lista branca como a lista negra aceitam padrões wildcard para endereço e domínio, 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 se uma entrada da lista branca também corresponder a uma regra da lista negra, se usar um sinal de mais enquanto o subaddressing de email está bloqueado, e quando as regras combinadas não permitiriam a entrada de nenhum novo email.
A lógica de correspondência e validação é partilhada através de helpers reutilizáveis em @logto/core-kit, por isso as mesmas regras aplicam-se sempre que um email entra num tenant.
A aplicação Experience suporta agora fluxos de redefinição de palavra-passe que verificam links mágicos de uso único diretamente na página de aterragem de redefinição da palavra-passe, além dos códigos de verificação.
Quando concessões OIDC são expulsas porque uma aplicação excedeu o número máximo de concessões permitidas, o Logto agora dispara um evento webhook Grant.LimitExceeded, selecionável nas definições de webhooks do Console como qualquer outro evento.
O payload reporta userId, applicationId, revokedGrantIds, maxAllowedGrants e preRevocationActiveGrantCount. O envio é "fire-and-forget": falhas são registadas como entradas de log de auditoria TriggerHook.Grant.LimitExceeded e nunca bloqueiam a resposta de autenticação.
Provedor OIDC atualizado para node-oidc-provider v9#
A maior mudança é uma correção de segurança na revogação de tokens.
Revogar um access token opaco agora revoga igualmente todos os tokens sob a mesma concessão, incluindo o refresh token. Em v8, o refresh token permanecia utilizável após a revogação e podia continuar a obter access tokens.
Outras atualizações de protocolo em v9:
O endpoint de revogação rejeita agora access tokens JWT com unsupported_token_type, em vez de devolver sucesso sem revogar nada como em v8.
O endpoint de metadata de authorization server 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 tokens.
Os ID tokens já não incluem o cabeçalho opcional typ: "JWT". O OpenID Connect define os ID tokens como JWTs e não exige que os clientes verifiquem este cabeçalho.
Atenção à verificação personalizada de ID tokens. Não é preciso fazer nada quando se usa um SDK oficial do Logto. Se a tua integração executa verificação personalizada de ID tokens, atualiza-a para permitir a ausência do claim at_hash e do cabeçalho typ: "JWT".
O Logto passou a correr em Koa 3, a linha de lançamento ativamente mantida que recebe correções de segurança primeiro. Não são esperadas alterações de comportamento: todos os endpoints, fluxos OIDC e respostas da API comportam-se como antes.
Segredos internos de aplicações já não são expostos pelas APIs de Gestão.
A política de lista negra de emails já não é devolvida em respostas públicas de sign-in.
Recuperar tokens de acesso de fornecedores terceiros através da Account API agora exige o scope de utilizador identities, como os outros endpoints de SSO social e empresarial.
Os códigos de verificação API para conta já não são enviados para emails bloqueados.
A validação de email e domínio de email agora coincide com valores completos e impõe regras mais estritas para domínios.
Melhorias na experiência, armazenamento e estabilidade#
Quando um fluxo de registo social ou SSO é rejeitado pelas regras de acesso ao email, ao aceitar o erro o utilizador é devolvido à página de login do Logto em vez de voltar ao fornecedor externo de identidade.
MFA é agora ativado automaticamente após o utilizador ativar um fator via Account API.
Criar um novo conector de email ou SMS executa a inserção e a limpeza de conectores antigos numa única transação de base de dados. Antes, um crash entre as duas podia deixar conectores duplicados.
As credenciais do cluster Redis são agora percent-decoded, garantindo sucesso em casos em que o utilizador ou a palavra-passe incluam caracteres reservados em URLs.
O TLS é agora corretamente ativado em ligações de cluster Redis que usam o protocolo rediss.
jose v6: Os conectores Apple, Google, OAuth e OIDC usam agora jose 6, que funciona com a Web Crypto API em vez do módulo crypto do Node. A assinatura de tokens e verificação de ID tokens comportam-se da mesma forma.
GitLab: Removida a dependência jose não utilizada, assim instalar o conector já não instala um pacote que nunca foi importado.
Aliyun SMS: Os números de telefone de Hong Kong são agora tratados como números internacionais.
Aliyun SMS authentication service (MAS): A assinatura passa a ser introduzida como texto livre em vez de numa dropdown, permitindo continuar a funcionar caso a Aliyun altere as assinaturas novamente.
Atenção — proteção SSRF do provedor OIDC. A segurança de pedidos outbound foi reforçada e a proteção SSRF está ativada por defeito. Instâncias self-hosted que precisem de aceder endpoints de relying-party de confiança em redes privadas devem definir OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true antes de iniciar o Logto; caso contrário, deixa a variável de fora.
É necessária migração de base de dados. Esta versão inclui alterações no esquema para ficheiros de verificação de domínio personalizado, além de índices e tabelas internos. Depois de atualizar, executa o comando de alteração de base de dados (npm run alteration deploy na imagem @logto/cli/core, ou logto db alteration deploy) antes de arrancar a nova versão. Consulta o guia de atualização para detalhes.
Verificação personalizada de ID token. Consulta a secção sobre node-oidc-provider v9 acima para as alterações aos cabeçalhos at_hash e typ.
