O Logto v1.43.0 adiciona aplicações dinâmicas com Documentos de Metadados OAuth Client ID, pedidos de autenticação SAML assinados, 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 empresarial.
CharlesDeveloper
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.43.0 expande a forma como as aplicações e os fornecedores de identidade empresariais se conectam, ao mesmo tempo que reforça as fronteiras de segurança em torno dos tokens e dos pedidos externos. Introduz aplicações dinâmicas com Documentos de Metadados OAuth Client ID, pedidos de autenticação SAML assinados e um runtime consolidado para Custom JWT e Actions. Esta versão também reforça a troca de tokens, webhooks e SSO empresarial, juntamente com melhorias no Account Center, suporte ao espanhol (México) e correções de fiabilidade. Eis o que há de novo.
A experiência de início de sessão agora suporta es-MX (espanhol, México).
Para utilizadores cuja língua é espanhol (México), os inputs de telefone assumem por defeito o indicativo do México (+52). Esta versão também corrige os placeholders do formatador de listas e a mensagem MFA ainda não traduzida nos locais de espanhol.
Pedidos externos configurados através da Management API agora são bloqueados quando resolvem para endereços loopback, privados, link-local, metadata cloud ou outros de uso especial.
A proteção agora abrange:
Entrega de webhooks, incluindo POST /api/hooks/:id/test.
Pedidos de descoberta, token e userinfo de SSO empresarial OIDC.
Recolha de metadata de providers de identidade SAML.
Todos os saltos de redirecionamento feitos por estes pedidos.
Os nomes DNS são verificados quando a conexão é estabelecida, então um hostname que resolva para um endereço protegido é rejeitado como um endereço IP literal.
Além de requerer tokens de assunto first-party, o Logto agora valida que um JWT apresentado como subject de access_token é na verdade um access token.
O JWT deve conter:
O header do tipo RFC 9068 at+jwt.
Uma claim client_id.
Tokens ID OIDC e outros JWTs assinados pelo tenant já não podem ser utilizados como substitutos de um access token. Tokens de subject inválidos são rejeitados com invalid_grant.
Aplicações de terceiros já não podem alterar dados de conta através da Account API ou Verification API. Estes pedidos devolvem agora:
Aplicações first-party, incluindo Account Center e Console, permanecem sem alteração.
A verificação falha por defeito para identificadores de cliente não resolvidos. Isto inclui aplicações eliminadas cujos access tokens ainda estão ativos e clientes CIMD cujo identificador é um URL de metadata.
Nenhuma rota de leitura recebeu uma nova guarda direta. Contudo, as seguintes leituras requerem registos de verificação criados por rotas protegidas e, assim, deixam de estar disponíveis para aplicações de terceiros:
GET /api/my-account/grants
GET /api/my-account/sessions
GET /api/my-account/mfa-verifications/backup-codes
Utilizadores suspensos não podem receber novos tokens#
A emissão de tokens e userinfo rejeitam agora utilizadores suspensos com invalid_grant, correspondendo ao comportamento existente para utilizadores eliminados.
Isto aplica-se ao refresh token, authorization code, device code e token exchange, mesmo que uma revogação anterior de token ou sessão não tenha sido concluída com sucesso.
Scopes de aplicações de terceiros são revalidados#
Remover um scope de utilizador da configuração de consentimento de uma aplicação de terceiros afeta agora concessões existentes, assim como novos pedidos de autorização.
Trocas de refresh token removem scopes que já não estão configurados.
Pedidos de autorização que retomam uma concessão existente falham com invalid_scope quando apropriado.
Pedidos de token de organização falham com insufficient_scope após o scope de organizações ser removido.
Submissão de consentimento já não concede um scope que foi removido enquanto o ecrã de consentimento estava aberto.
Lockout de identificadores usa identificadores normalizados#
Os contadores de lockout Sentinel agora usam a mesma forma normalizada de identificador que a procura de conta:
Endereços de email são convertidos para minúsculas.
Números de telefone são canonizados.
Usernames são tratados via case-fold apenas quando a política da tenant para username é case-insensitive.
Isto evita que grafias alternativas do mesmo identificador criem buckets de tentativas diferentes e enfraqueçam o maxAttempts.
O desbloqueio manual também limpa grafias equivalentes quando identificam a mesma conta. Após o upgrade, um lockout já existente registado sob uma grafia não canónica pode terminar mais cedo, mas nenhum utilizador fica mais bloqueado do que antes.
Revogar uma autorização de aplicação de terceiros de um utilizador agora invalida apenas os tokens dessa aplicação. A sessão SSO do browser do utilizador permanece ativa.
Chaves de assinatura Elliptic Curve agora apresentam o algoritmo correspondente: P-256 usa ES256, P-384 usa ES384 e P-521 usa ES512.
Mudar de início de sessão passkey para código de verificação já não impede os utilizadores de completarem o CAPTCHA.
Mensagens OIDC invalid_scope e insufficient_scope agora mostram o scope rejeitado em vez de placeholders crus como {{error_description}} ou {{scope}}.
O Safari e outros gestores de passwords agora podem sugerir e guardar uma password forte nos ecrãs de definir password e de recuperação, utilizando o identificador de conta correto.
Valores de qualidade Accept-Language com espaços, como en; q=0.7, agora são corretamente analisados. Valores inválidos caem para um valor padrão seguro em vez de produzirem NaN.
O matching customizado de allowlist e blocklist do Gmail agora trata gmail.com e googlemail.com como equivalentes e ignora pontos na parte local.
O Console agora proporciona exemplos mais claros, descrições e placeholders mais curtos para regras de emails personalizados.
Guardar as definições do Account Center ou de registo agora remove referências a campos de perfil personalizados eliminados em vez de devolver custom_profile_fields.entity_not_exists_with_names.
Campos eliminados continuam removíveis do Console mesmo quando o seu controlo de permissões está desativado.
Os endpoints de relação da Management API agora aceitam arrays vazios para scope ou role como no-ops, ao invés de devolver erro 500. Isto inclui endpoints como:
POST /applications/:applicationId/user-consent-scopes
POST /organizations/:id/users/:userId/roles
A validação de datas agora corresponde ao input completo e rejeita caracteres após uma data válida.
Pedidos POST de webhook agora fazem retry até três vezes quando o endpoint devolve resposta HTTP 5xx, em conformidade com o contrato de entrega documentado.
Dado que um evento repetido pode ser entregue mais do que uma vez, receivers de webhooks devem processar eventos de forma idempotente.
O conector Microsoft Azure AD agora suporta a opção disableEmailSync.
Por defeito, o conector continua a copiar o atributo Microsoft Graph mail para o perfil de utilizador Logto. Ativa esta opção quando desejas que o conector autentique o utilizador sem sincronizar esse endereço, correspondendo ao controlo já existente para o SSO empresarial Azure OIDC.
Ação necessária — proteção de pedidos externos: Se os webhooks ou conectores SSO empresariais acedem intencionalmente serviços numa rede privada, adiciona os IPs ou ranges CIDR necessários em SSRF_ALLOWED_ADDRESSES antes de fazer o upgrade:
Colocar apenas os destinos necessários em allowlist é mais seguro do que desativar a proteção globalmente.
Compatibilidade com aplicações dinâmicas: Configurar SSRF_ALLOWED_ADDRESSES desativa CIMD, de modo que clientes dinâmicos não autenticados não possam utilizar a allowlist para aceder serviços privados. Ativar SSRF_PROTECTION_DISABLED=true também desativa CIMD.
Compatibilidade de configuração: OIDC_PROVIDER_SSRF_PROTECTION_DISABLED permanece suportado como alias para SSRF_PROTECTION_DISABLED. Estas variáveis aplicam-se apenas a instalações self-hosted.
Limites de runtime de scripts: Scripts Custom JWT e Actions devem terminar em até 5 segundos, utilizar até 128 MB de memória e devolver valores JSON-serializáveis.
Migração de base de dados necessária: Esta versão inclui novas alterações de schema e indexes. 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 iniciar a nova versão. Vê o guia de upgrade.
