Utforska vår augusti 2024-version med användarimitering, hantering av applikationshemligheter, varumärkesprofilering på organisations- och applikationsnivå för inloggningsupplevelser och mycket mer.
Lagt till stöd för användarimitering via tokenutbyte:
POST /subject-tokens för att begära en subject_token för användning i tokenutbyte.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.
custom_dataLagt till ett nytt godtyckligt objektfält custom_data till applikationer. Detta fält kan lagra ytterligare information som inte definieras i standardapplikationsschemat Application.
PATCH /api/applications/{applicationId}/custom-data endpoint för att uppdatera custom_data-fältet i en applikation.PATCH /api/applications/{applicationId} endpoint för att tillåta överskrivning av custom_data-fältet.Lagt till en ny JSON-redigerare för anpassade data på applikationsdetaljsidan (förutom för skyddade appar).
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.
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.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.
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.
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.
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:
tsup för att bygga anslutningspaketen. Detta kommer att göra byggprocessen snabbare och bör inte påverka funktionaliteten av paketen.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.PATCH /api/applications/{applicationId} endpointAlla 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.
merge till replace i PATCH /api/applications/{applicationId} endpoint.partial till full i PATCH /api/applications/{applicationId} endpoint.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änderPATCH-metoden för att uppdatera inställningarna för jsonb-fältetApplicationbö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.
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.
Argon2d och Argon2id. Användare med dessa algoritmer kommer att migreras till Argon2i vid lyckad inloggning.@logto/experience har synkroniserats med vad som anges i README.md.