## 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](https://docs.logto.io/docs/recipes/impersonation/) 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: ```js import LogtoClient from '@logto/client'; const logtoClient = new LogtoClient(/* din konfiguration */); logtoClient.signIn({ redirectUri: 'https://your-app.com/callback', extraParams: { organization_id: '', }, }); ``` Värdet `` 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.