O Logto v1.43.0 adiciona aplicativos dinâmicos com Documentos de Metadados de ID de Cliente OAuth, solicitações de autenticação SAML assinadas, um runtime limitado para Custom JWT e Actions, validação mais rigorosa na troca de tokens e proteção SSRF expandida para webhooks e SSO corporativo.
CharlesDeveloper
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.
O Logto v1.43.0 amplia como aplicativos e provedores de identidade corporativos se conectam, enquanto reforça os limites de segurança para tokens e solicitações de saída. Ele apresenta aplicativos dinâmicos com Documentos de Metadados de ID de Cliente OAuth, solicitações de autenticação SAML assinadas e um runtime consolidado para Custom JWT e Actions. O lançamento também reforça a troca de tokens, webhooks e SSO corporativo, além de melhorias no Account Center, suporte ao espanhol (México) e correções de confiabilidade. Confira o que há de novo.
A experiência de login agora suporta es-MX (espanhol, México).
Para usuários cuja linguagem é espanhol (México), os campos de telefone usam, por padrão, o código do país do México (+52). Este lançamento também corrige marcadores de posição de formatador de listas e a última mensagem MFA não traduzida nos locais em espanhol.
Solicitações de saída configuradas pela Management API agora são bloqueadas quando resolvem para endereços loopback, privados, link-local, metadados de nuvem ou outros endereços de uso especial.
A proteção agora cobre:
Entrega de webhook, incluindo POST /api/hooks/:id/test.
Descoberta, token e solicitações userinfo OIDC de SSO corporativo.
Busca de metadados do provedor de identidade SAML.
Cada salto de redirecionamento feito por essas solicitações.
Nomes DNS são verificados quando a conexão é estabelecida, então um hostname que resolve para um endereço protegido é rejeitado como um endereço IP literal.
Além de exigir tokens de sujeito de primeira parte, o Logto agora valida se um JWT apresentado como sujeito do access_token é realmente um access token.
O JWT deve conter:
O header de tipo at+jwt do RFC 9068.
Um claim client_id.
Tokens OIDC ID e outros JWTs assinados pelo tenant não podem mais ser substituídos por um access token. Tokens do sujeito inválidos são rejeitados com invalid_grant.
Aplicativos de terceiros não podem mais alterar dados de conta via Account API ou Verification API. Essas solicitações agora retornam:
Aplicativos de primeira parte, incluindo Account Center e Console, não são afetados.
A verificação falha fechada para identificadores de cliente não resolvidos. Isso inclui aplicações deletadas cujos tokens de acesso ainda estão ativos e clientes CIMD cujo identificador é uma URL de metadados.
Nenhuma rota de leitura recebeu uma nova proteção direta. No entanto, as seguintes leituras exigem registros de verificação criados por rotas protegidas e, portanto, não são mais acessíveis por aplicativos de terceiros:
GET /api/my-account/grants
GET /api/my-account/sessions
GET /api/my-account/mfa-verifications/backup-codes
Usuários suspensos não podem receber novos tokens#
A emissão de tokens e userinfo agora rejeita usuários suspensos com invalid_grant, igualando o comportamento existente para usuários deletados.
Isso se aplica em fluxos de refresh token, authorization code, device code e troca de tokens, mesmo que um token anterior ou revogação de sessão não tenha sido completada com sucesso.
Os escopos de aplicativos de terceiros são revalidados#
Remover um escopo de usuário da configuração de consentimento de um aplicativo de terceiros agora afeta tanto autorizações existentes quanto novas solicitações de autorização.
Trocas de refresh token removem escopos que não estão mais configurados.
Solicitações de autorização que continuam uma autorização existente falham com invalid_scope quando apropriado.
Solicitações de token para organizações falham com insufficient_scope após a remoção do escopo de organizações.
O envio do consentimento não concede mais um escopo que foi removido enquanto a tela de consentimento estava aberta.
Lockouts de identificador usam identificadores normalizados#
Os contadores de lockout Sentinel agora usam a mesma forma normalizada de identificador que a busca de contas:
Endereços de e-mail ficam em minúsculas.
Números de telefone são canonizados.
Nomes de usuário só mudam caixa quando a política do tenant é case-insensitive.
Isso previne que diferentes grafias do mesmo identificador criem buckets de tentativas separados e enfraqueçam o maxAttempts.
Desbloqueio manual também limpa grafias equivalentes quando identificam a mesma conta. Após atualizar, um lockout existente registrado com grafia não canônica pode terminar antes, mas nenhum usuário ficará mais bloqueado do que antes.
Revogar a autorização de um aplicativo de terceiros de um usuário agora invalida apenas os tokens desse aplicativo. A sessão SSO do navegador do usuário permanece ativa.
Chaves de assinatura Elliptic Curve agora anunciam o algoritmo que corresponde à sua curva: P-256 usa ES256, P-384 usa ES384 e P-521 usa ES512.
Alternar do login por passkey para login por código de verificação não impede mais que usuários concluam CAPTCHA.
Mensagens OIDC invalid_scope e insufficient_scope agora mostram o escopo rejeitado em vez de mostrar raw {{error_description}} ou {{scope}}.
O Safari e outros gerenciadores de senhas agora sugerem e salvam uma senha forte nas telas de set-password e reset-password usando o identificador correto da conta.
Valores quality de Accept-Language com espaços em branco, como en; q=0.7, agora são analisados corretamente. Valores quality inválidos caem em fallback com segurança ao invés de gerar NaN.
A correspondência de custom allowlist e blocklist do Gmail agora trata gmail.com e googlemail.com como equivalentes e ignora pontos na parte local do endereço.
O Console agora oferece exemplos, descrições e marcadores de posição mais claros e curtos para regras de e-mail personalizadas.
Salvar configurações do Account Center ou de sign-up agora descarta referências a campos de perfil personalizados deletados ao invés de retornar custom_profile_fields.entity_not_exists_with_names.
Campos deletados continuam removíveis pelo Console, mesmo que o controle de permissão esteja desligado.
Endpoints de relação da Management API agora aceitam arrays de escopo ou função vazios como no-ops ao invés de retornar erro 500. Isso inclui endpoints como:
POST /applications/:applicationId/user-consent-scopes
POST /organizations/:id/users/:userId/roles
Agora a validação de datas corresponde ao input completo e rejeita caracteres extras após uma data válida.
Requisições POST de webhook agora são tentadas até três vezes quando o endpoint retorna resposta HTTP 5xx, condizente com o contrato de entrega documentado.
Como um evento reenviado pode ser entregue mais de uma vez, os receptores de webhook devem processar eventos de forma idempotente.
O conector Microsoft Azure AD agora oferece a opção disableEmailSync.
Por padrão, o conector ainda copia o atributo mail do Microsoft Graph para o perfil do usuário no Logto. Ative essa opção caso o conector deva autenticar o usuário sem sincronizar esse endereço, igual ao controle disponível para SSO corporativo Azure OIDC.
Ação necessária — proteção para requisições de saída: Caso webhooks ou conectores SSO corporativo acessarem serviços em uma rede privada intencionalmente, adicione os endereços IP ou faixas CIDR necessárias em SSRF_ALLOWED_ADDRESSES antes da atualização:
Permitir apenas os destinos necessários é mais seguro do que desabilitar a proteção globalmente.
Compatibilidade com apps dinâmicos: Configurar SSRF_ALLOWED_ADDRESSES desabilita o CIMD para que clientes dinâmicos não autenticados não consigam usar a allowlist para alcançar serviços privados. Definir SSRF_PROTECTION_DISABLED=true também desabilita CIMD.
Compatibilidade de configuração: OIDC_PROVIDER_SSRF_PROTECTION_DISABLED permanece suportado como alias para SSRF_PROTECTION_DISABLED. Essas variáveis só se aplicam a implantações self-hosted.
Limites de runtime para scripts: Scripts Custom JWT e Actions devem ser concluídos em até 5 segundos, manter-se dentro do limite de memória do worker de 128 MB e retornar valores serializáveis em JSON.
Migração de banco de dados obrigatória: Este lançamento traz novas alterações de schema e índices. Após atualizar, 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 rodar a nova versão. Veja o guia de atualização.
