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.
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 ensubject_token
för användning i tokenutbyte. - Uppdaterat OIDC
POST /oidc/token
endpoint med en ny tilldelningstypurn:ietf:params:oauth:grant-type:token-exchange
för att byta ensubject_token
mot en användarimiteradaccess_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 uppdateracustom_data
-fältet i en applikation. - Uppdatera
PATCH /api/applications/{applicationId}
endpoint för att tillåta överskrivning avcustom_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
tillreplace
iPATCH /api/applications/{applicationId}
endpoint. - Uppdatera API jsonb-fältets inparameterverifiering från
partial
tillfull
iPATCH /api/applications/{applicationId}
endpoint. - Påverkade fält:
oidc_client_metadata
,custom_client_metadata
,protected_app_metadata
ochcustom_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änderPATCH
-metoden för att uppdatera inställningarna för jsonb-fältetApplication
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
ochArgon2id
. Användare med dessa algoritmer kommer att migreras tillArgon2i
vid lyckad inloggning. - Konfigurationen av webbläsarlistan för
@logto/experience
har synkroniserats med vad som anges iREADME.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.