• release

Logto produktuppdateringar (augusti 2024)

Utforska vår augusti 2024-version med användarimitering, hantering av applikationshemligheter, varumärkesprofilering på organisations- och applikationsnivå för inloggningsupplevelser och mycket mer.

Simeng
Simeng
Developer

Användarimitering (RFC 8693: OAuth 2.0-tokenutbyte)

Lagt till stöd för användarimitering via tokenutbyte:

  • Ny Management API-endpoint POST /subject-tokens för att begära en subject_token för användning i tokenutbyte.
  • Uppdaterat OIDC POST /oidc/token endpoint med en ny tilldelningstyp urn:ietf:params:oauth:grant-type:token-exchange för att byta en subject_token mot en användarimiterad access_token.

Se Användarimitering för mer information.

Applikationsnivå custom_data

Lagt till ett nytt godtyckligt objektfält custom_data till applikationer. Detta fält kan lagra ytterligare information som inte definieras i standardapplikationsschemat Application.

Klicka för att expandera Management API-uppdateringar
  • Ny PATCH /api/applications/{applicationId}/custom-data endpoint för att uppdatera custom_data-fältet i en applikation.
  • Uppdatera PATCH /api/applications/{applicationId} endpoint för att tillåta överskrivning av custom_data-fältet.
Klicka för att expandera Konsoluppdateringar

Lagt till en ny JSON-redigerare för anpassade data på applikationsdetaljsidan (förutom för skyddade appar).

Hantering av flera apphemligheter

Säkra appar (maskin-till-maskin, traditionell web, skyddade) kan nu ha flera apphemligheter med utgångsdatum. Detta möjliggör rotationshemligheter och ger en ännu säkrare upplevelse.

Obs: Den äldre hemligheten som skapats före denna funktion kan fortfarande användas för klientautentisering. Det rekommenderas dock att radera de gamla och skapa nya hemligheter med utgångsdatum för förbättrad säkerhet.

Klicka för att expandera Management API-uppdateringar
  • GET /api/applications/{applicationId}/secrets: Lista alla hemligheter för en applikation.
  • POST /api/applications/{applicationId}/secrets: Skapa en ny hemlighet för en applikation.
  • DELETE /api/applications/{applicationId}/secrets/{name}: Ta bort en hemlighet för en applikation med namn.
  • PATCH /api/applications/{applicationId}/secrets/{name}: Uppdatera en hemlighet för en applikation med namn.
  • DELETE /api/applications/{applicationId}/legacy-secret: Ta bort den äldre hemligheten för en applikation och ersätt den med en ny.
Klicka för att expandera Konsoluppdateringar

För att hantera dina applikationshemligheter, gå till Logto Console -> Applikationer -> Applikationsdetaljer -> Endpoints & Credentials.

Det ursprungliga inmatningsfältet för apphemlighet är nu ersatt med en ny hanteringstabell för hemligheter. Du kan skapa, uppdatera och ta bort hemligheter i denna tabell.

Varumärkesprofilering på organisations- och applikationsnivå

Organisationslogotyp

Nu går det att ställa in ljusa och mörka logotyper för organisationer. Du kan ladda upp logotyperna på organisationsinställningssidan.

Dessutom är det möjligt att åsidosätta inloggningsupplevelse-logotypen från en organisation. Lägg bara till parametern organization_id i autentiseringsbegäran. I de flesta Logto SDK:er kan det göras med hjälp av fältet extraParams i metoden signIn.

Till exempel, i JavaScript-SDK:

Värdet <organization-id> kan hittas på organisationsinställningssidan.

Om du inte kunde hitta fältet extraParams i SDK:en du använder, vänligen låt oss veta.

Applikationsnivå varumärkesprofilering

Du kan nu ställa in logotyper, favicons och färger för din app. Dessa inställningar kommer att användas i inloggningsupplevelsen när appen initierar autentiseringsflödet. För appar som saknar varumärkesinställningar kommer omni inloggningsupplevelse-varumärket att användas.

Om organization_id tillhandahålls i autentiseringsbegäran kommer appens varumärkesinställningar att åsidosättas av organisationens varumärkesinställningar, om de är tillgängliga.

Prestandaförbättringar

Stöd för renderingsserver på appens serversida

Logto injicerar nu inställningarna och fraserna för inloggningsupplevelsen i index.html-filen för bättre prestations på första skärmen. Upplevelseappen kommer fortfarande att hämta inställningarna och fraserna från servern om:

  • Servern inte injicerade inställningarna och fraserna.
  • Parametrarna i URL:en är olika från servergenererad data.

Förbättrat paketbyggande

  • Använd tsup för att bygga anslutningspaketen. Detta kommer att göra byggprocessen snabbare och bör inte påverka funktionaliteten av paketen.
  • Använd Vite för transpilation och sammanställning av @logto/console, @logto/demo-app och @logto/experience paket. ParcelJS har tagits bort och ersatts med Vite. Inga brytförändringar bör förväntas.

Bugfixar

Åtgärda jsonb-uppdateringsbeteendet i PATCH /api/applications/{applicationId} endpoint

Alla jsonb-fält i objektet Application bör uppdateras i replace-läge istället för merge-läge. Denna förändring kommer att göra PATCH-metoden mer förutsägbar och konsekvent med Restful API-designen.

  • Uppdatera jsonb-fältets uppdateringsläge från merge till replace i PATCH /api/applications/{applicationId} endpoint.
  • Uppdatera API jsonb-fältets inparameterverifiering från partial till full i PATCH /api/applications/{applicationId} endpoint.
  • Påverkade fält: oidc_client_metadata, custom_client_metadata, protected_app_metadata och custom_data.

Obs: Om du använder Logto-konsolen för att uppdatera inställningarna för Application, bör du inte påverkas av denna förändring. API-användare som använder PATCH-metoden för att uppdatera inställningarna för jsonb-fältet Application bör vara medvetna om denna förändring. PATCH-metoden kommer nu att ersätta hela jsonb-fältet med de nya indatavärdena. All partiell indatavärde av de berörda fälten kommer att avvisas.

Åtgärda problemet där händelselasten för vissa webhooks alltid returnerar API-svarstatus 404

Påverkade webhook-händelser: Role.Scopes.Updated, Organizations.Membership.Updates.

API-svarstatuskoden som returnerades från webhook-händelsebelastningen var alltid 404. Det berodde på att webhook-händelsebelastningen infogades innan API-svarskontexten var satt.

Eftersom vi endast utlöser webhooken när händelsen bearbetas framgångsrikt bör statuskoden alltid vara 2xx.

Detta problem har lösts genom att flytta infogningen av webhook-händelsebelastningen efter att API-svarskontexten är inställd.

Andra förbättringar

  • Favikonen för mörkt tema kan nu ställas in i inloggningsupplevelse-varumärkesinställningar.
  • Lägg till nya lösenordsdigestalgoritmer: Argon2d och Argon2id. Användare med dessa algoritmer kommer att migreras till Argon2i vid lyckad inloggning.
  • Konfigurationen av webbläsarlistan för @logto/experience har synkroniserats med vad som anges i README.md.
  • Förbättra beskrivningen av swagger-auktorisering. Använd det inhemska OpenAPI OAuth2-säkerhetsschemat istället för det anpassade HTTP-huvudbaserade säkerhetsschemat.