## 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](https://docs.logto.io/docs/recipes/impersonation/) 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: ```js import LogtoClient from '@logto/client'; const logtoClient = new LogtoClient(/* sua configuração */); logtoClient.signIn({ redirectUri: 'https://your-app.com/callback', extraParams: { organization_id: '', }, }); ``` O valor `` 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.