Explora a nossa versão de agosto de 2024 com simulação de utilizador, gestão de segredos de aplicação, personalização da experiência de início de sessão a nível de organização e aplicação, e muito mais.
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.
Simulação de utilizador (RFC 8693: Troca de Tokens OAuth 2.0)#
Adicionado suporte para simulação de utilizador via Troca de Tokens:
Novo endpoint da API de Gestão POST /subject-tokens para solicitar um subject_token para uso na troca de token.
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 pelo utilizador.
Adicionado um novo campo de objeto arbitrário custom_data às aplicações. Este campo pode armazenar qualquer informação adicional não definida no esquema padrão de Aplicação.
Clique para expandir as atualizações da API de Gestão
Novo endpoint PATCH /api/applications/{applicationId}/custom-data para atualizar o campo custom_data de uma aplicação.
Atualização do endpoint PATCH /api/applications/{applicationId} para permitir a sobrescrita do campo custom_data.
Clique para expandir as atualizações do Console
Adicionado um novo editor JSON de dados personalizados à página de detalhes da aplicação (exceto para Apps Protegidas).
Apps seguras (máquina-a-máquina, web tradicionais, Protegidas) podem agora ter vários segredos com expiração. Isto permite a rotação de segredos e proporciona uma experiência ainda mais segura.
Nota: O segredo legado criado antes desta funcionalidade ainda pode ser utilizado para autenticação do cliente. No entanto, recomenda-se eliminar os anteriores e criar novos segredos com expiração para maior segurança.
Clique para expandir as atualizações da API de Gestão
GET /api/applications/{applicationId}/secrets: Lista todos os segredos de uma aplicação.
POST /api/applications/{applicationId}/secrets: Cria um novo segredo para uma aplicação.
DELETE /api/applications/{applicationId}/secrets/{name}: Elimina um segredo de uma aplicação pelo nome.
PATCH /api/applications/{applicationId}/secrets/{name}: Atualiza um segredo de uma aplicação pelo nome.
DELETE /api/applications/{applicationId}/legacy-secret: Elimina o segredo legado de uma aplicação e substitui-o por um novo.
Clique para expandir as atualizações do Console
Para gerir os segredos da tua aplicação, vai a Logto Console -> Aplicações -> Detalhes da Aplicação -> Endpoints & Credenciais.
O campo de entrada de segredo da aplicação original, que era só de leitura, foi agora substituído por uma nova tabela de gestão de segredos. Nesta tabela, podes criar, atualizar e eliminar segredos.
Personalização de marca a nível de organização e aplicação#
Agora é possível definir logotipos claros e escuros para as organizações. Podes carregar os logotipos na página de definições da organização.
Também é possível sobrescrever o logotipo da experiência de início de sessão de uma organização. Basta adicionar o parâmetro organization_id ao pedido de autenticação. Na maioria dos SDKs 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 definições da organização.
Se não conseguires encontrar o campo extraParams no SDK que estás a usar, por favor informa-nos.
Agora podes definir logotipos, favicons, e cores para a tua app. Estas definições serão usadas na experiência de início de sessão quando a app iniciar o fluxo de autenticação. Para apps que não têm definições de marca, será usada a personalização da experiência de início de sessão omni.
Se organization_id for fornecido no pedido de autenticação, as definições de marca a nível de app serão sobrescritas pelas definições de marca da organização, se disponíveis.
Suporte à renderização do lado do servidor para a app de experiência#
Logto agora injeta as definições e frases da experiência de início de sessão no ficheiro index.html para um melhor desempenho na primeira tela. A app de experiência ainda irá buscar as definições e frases ao servidor se:
O servidor não tiver injetado as definições e frases.
Os parâmetros na URL forem diferentes dos dados renderizados pelo servidor.
Uso de tsup para construir os pacotes de conectores. Isto vai tornar o processo de build mais rápido, e não deverá afetar a funcionalidade dos pacotes.
Uso de Vite para transpilação e empacotamento dos pacotes @logto/console, @logto/demo-app e @logto/experience. Removido ParcelJS e substituído por Vite. Não são esperadas alterações incompatíveis.
Correção no comportamento de atualização de jsonb no endpoint PATCH /api/applications/{applicationId}#
Todos os campos jsonb do objeto Application devem ser atualizados no modo de replace em vez de merge. Esta alteração tornará o método PATCH mais previsível e consistente com o design da API Restful.
Atualizado o modo de atualização do campo jsonb de merge para replace no endpoint PATCH /api/applications/{applicationId}.
Atualizada a validação dos parâmetros de entrada jsonb na 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 estiveres a usar o console Logto para atualizar as definições da Application, não deves ser afetado por esta alteração. Os utilizadores da API que estão a usar o método PATCH para atualizar as definições do campo jsonb da Application devem estar cientes desta alteração. O método PATCH agora vai substituir todo o campo jsonb com os novos dados de entrada. Quaisquer dados de entrada parciais dos campos afetados serão rejeitados.
Correção de alguns problemas em que o payload do evento webhook retornava sempre o status de resposta da API 404#
Eventos de webhook afetados: Role.Scopes.Updated, Organizations.Membership.Updates.
O código de status da resposta da API retornado no payload do evento webhook era sempre 404. Isso foi causado pela inserção do payload do evento webhook antes do contexto de resposta da API ser definido.
Como só acionamos o webhook quando o evento é processado com sucesso, o código de status deve ser sempre 2xx.
Este problema foi corrigido movendo a inserção do payload do evento webhook após o contexto de resposta da API ser definido.
Agora é possível definir o favicon para o tema escuro nas definições de personalização da experiência de início de sessão.
Adicionados novos algoritmos de digest de senha: Argon2d e Argon2id. Utilizadores 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 está indicado no README.md.
Melhorada a descrição de autenticação no swagger. Uso do esquema de segurança OAuth2 nativo do OpenAPI em vez do esquema de segurança personalizado baseado em cabeçalhos HTTP.
