Atualizações do produto Logto (Agosto de 2024)

Simulação de usuário (RFC 8693: OAuth 2.0 Troca de Token)#

Adicionada a funcionalidade de simulação de usuário via Troca de Token:

• Novo endpoint da API de Gerenciamento POST /subject-tokens para solicitar um subject_token para uso na troca de tokens.
• Atualizado o endpoint OIDC POST /oidc/token com um novo tipo de concessão urn:ietf:params:oauth:grant-type:token-exchange para trocar um subject_token por um access_token simulado para o usuário.

Veja Simulação de usuário para mais detalhes.

custom_data em nível de aplicativo#

Adicionado um novo campo de objeto arbitrário custom_data aos aplicativos. Este campo pode armazenar qualquer informação adicional não definida no esquema padrão de Aplicativo.

Clique para expandir as atualizações da API de Gerenciamento

• Novo endpoint PATCH /api/applications/{applicationId}/custom-data para atualizar o campo custom_data de um aplicativo.
• Atualização do endpoint PATCH /api/applications/{applicationId} para permitir a substituição do campo custom_data.

Clique para expandir as atualizações do Console

Adicionado um novo editor JSON para custom data na página de detalhes do aplicativo (exceto para Apps Protegidos).

Gerenciamento de múltiplos segredos de aplicativo#

Aplicativos seguros (máquina a máquina, web tradicional, Protegido) agora podem ter múltiplos segredos de aplicativo com data de expiração. Isso permite a rotação de segredos e proporciona uma experiência ainda mais segura.

Nota: O segredo legado criado antes desse recurso ainda pode ser usado para autenticação do cliente. No entanto, é recomendável excluir os antigos e criar novos segredos com data de expiração para maior segurança.

Clique para expandir as atualizações da API de Gerenciamento

• GET /api/applications/{applicationId}/secrets: Lista todos os segredos de um aplicativo.
• POST /api/applications/{applicationId}/secrets: Cria um novo segredo para um aplicativo.
• DELETE /api/applications/{applicationId}/secrets/{name}: Exclui um segredo de um aplicativo pelo nome.
• PATCH /api/applications/{applicationId}/secrets/{name}: Atualiza um segredo de um aplicativo pelo nome.
• DELETE /api/applications/{applicationId}/legacy-secret: Exclui o segredo legado de um aplicativo e substitui por um novo.

Clique para expandir as atualizações do Console

Para gerenciar os segredos do seu aplicativo, vá para Logto Console -> Aplicativos -> Detalhes do Aplicativo -> Endpoints e Credenciais.

O campo de entrada somente leitura do segredo do aplicativo original foi substituído por uma nova tabela de gerenciamento de segredos. Você pode criar, atualizar e excluir segredos nessa tabela.

Branding em nível de organização e aplicativo#

Logo da organização#

Agora é possível definir logotipos para temas claro e escuro para as organizações. Você pode carregar os logotipos na página de configurações da organização.

Também é possível substituir o logotipo da experiência de login de uma organização. Basta adicionar o parâmetro organization_id à solicitação de autenticação. Na maioria dos SDKs do Logto, isso pode ser feito usando o campo extraParams no método signIn.

Por exemplo, no SDK JavaScript:

O valor <organization-id> pode ser encontrado na página de configurações da organização.

Se você não encontrar o campo extraParams no SDK que está usando, por favor, nos avise.

Branding em nível de aplicativo#

Agora você pode definir logotipos, favicons e cores para o seu aplicativo. Essas configurações serão usadas na experiência de login quando o aplicativo iniciar o fluxo de autenticação. Para aplicativos que não possuem configurações de branding, será usada a experiência de login omni.

Se organization_id for fornecido na solicitação de autenticação, as configurações de branding em nível de aplicativo serão substituídas pelas configurações de branding da organização, se disponível.

Melhorias de performance#

Suporte à renderização no lado do servidor para experiência de aplicativo#

O Logto agora injeta as configurações e frases da experiência de login no arquivo index.html para melhorar a performance da primeira tela. O aplicativo de experiência ainda buscará as configurações e frases no servidor se:

• O servidor não tiver injetado as configurações e frases.
• Os parâmetros na URL forem diferentes dos dados renderizados pelo servidor.

Melhorias na compilação dos pacotes#

• Usando tsup para compilar os pacotes conectores. Isso tornará o processo de compilação mais rápido e não deve afetar a funcionalidade dos pacotes.
• Usando Vite para transpilar e agrupar os pacotes @logto/console, @logto/demo-app e @logto/experience. ParcelJS foi removido e substituído pelo Vite. Nenhuma mudança incompatível deve ser esperada.

Correções de bugs#

Correção do comportamento de atualização jsonb do endpoint PATCH /api/applications/{applicationId}#

Todos os campos jsonb do objeto Aplicativo devem ser atualizados no modo replace em vez de merge. Essa mudança tornará o método PATCH mais previsível e consistente com o design da API Restful.

• Atualização do modo de atualização do campo jsonb de merge para replace no endpoint PATCH /api/applications/{applicationId}.
• Atualização da validação dos parâmetros de entrada do campo jsonb da API de partial para full no endpoint PATCH /api/applications/{applicationId}.
• Campos afetados: oidc_client_metadata, custom_client_metadata, protected_app_metadata e custom_data.

Nota: Se você estiver usando o console Logto para atualizar as configurações do Aplicativo, não deverá ser afetado por essa mudança. Usuários da API que estão usando o método PATCH para atualizar as configurações do campo jsonb do Aplicativo devem estar cientes dessa mudança. O método PATCH agora substituirá todo o campo jsonb pelos novos dados de entrada. Qualquer dado de entrada parcial dos campos afetados será rejeitado.

Corrigir problema de retorno de status 404 nas cargas de eventos de alguns webhooks#

Eventos de webhook afetados: Role.Scopes.Updated, Organizations.Membership.Updates.

O código de status da resposta da API retornado na carga de eventos do webhook estava sempre 404. Isso foi causado pela inserção da carga de eventos do webhook antes do contexto da resposta da API ser definido.

Como só acionamos o webhook quando o evento é processado com sucesso, o código de status deve sempre ser 2xx.

Esse problema foi corrigido movendo a inserção da carga de eventos do webhook após a definição do contexto de resposta da API.

Outras melhorias#

• Agora o favicon para o tema escuro pode ser configurado nas configurações de branding da experiência de login.
• Adicionados novos algoritmos de digest de senha: Argon2d e Argon2id. Usuários com esses algoritmos serão migrados para Argon2i após um login bem-sucedido.
• A configuração da lista de navegadores para @logto/experience foi sincronizada com o que foi declarado no README.md.
• Melhoria na descrição de autenticação do swagger. Usando o esquema de segurança OAuth2 nativo do OpenAPI em vez do esquema de segurança baseado em cabeçalhos HTTP customizados.