## Gebruikersnabootsing (RFC 8693: OAuth 2.0 Token Exchange) Ondersteuning toegevoegd voor gebruikersnabootsing via Token Exchange: - Nieuwe Management API-eindpunt `POST /subject-tokens` om een `subject_token` aan te vragen voor gebruik bij tokenuitwisseling. - Het OIDC `POST /oidc/token` eindpunt bijgewerkt met een nieuw toestemmingsstype `urn:ietf:params:oauth:grant-type:token-exchange` om een `subject_token` uit te wisselen voor een gebruiker-gegenereerde `access_token`. Zie [Gebruikersnabootsing](https://docs.logto.io/docs/recipes/impersonation/) voor meer details. ## Applicatieniveau `custom_data` Een nieuw willekeurig objectveld `custom_data` toegevoegd aan applicaties. Dit veld kan alle aanvullende informatie opslaan die niet is gedefinieerd in het standaard `Application` schema.

Klik om Management API-updates uit te vouwen

- Nieuw `PATCH /api/applications/{applicationId}/custom-data` eindpunt om het `custom_data` veld van een applicatie bij te werken. - Update `PATCH /api/applications/{applicationId}` eindpunt om het `custom_data` veld te overschrijven.

Klik om Console-updates uit te vouwen

Nieuwe JSON-editor voor aangepaste data toegevoegd aan de applicatiedetailpagina (behalve voor beveiligde apps).

## Meerdere app geheimenbeheer Veilige apps (machine-to-machine, traditionele web, beveiligde) kunnen nu meerdere app geheimen met vervaldatum hebben. Dit maakt geheimenrotatie mogelijk en biedt een nog veiligere ervaring. > **Opmerking**: Het oude geheim dat vóór deze functie is aangemaakt, kan nog steeds worden gebruikt voor clientauthenticatie. Het is echter aan te raden om de oude te verwijderen en nieuwe geheimen met een vervaldatum aan te maken voor verbeterde beveiliging.

Klik om Management API-updates uit te vouwen

- `GET /api/applications/{applicationId}/secrets`: Lijst van alle geheimen van een applicatie. - `POST /api/applications/{applicationId}/secrets`: Maak een nieuw geheim voor een applicatie. - `DELETE /api/applications/{applicationId}/secrets/{name}`: Verwijder een geheim van een applicatie op naam. - `PATCH /api/applications/{applicationId}/secrets/{name}`: Werk een geheim van een applicatie op naam bij. - `DELETE /api/applications/{applicationId}/legacy-secret`: Verwijder het oude geheim van een applicatie en vervang het door een nieuw.

Klik om Console-updates uit te vouwen

Om je applicatiegeheimen te beheren, ga je naar Logto Console -> Applicaties -> Applicatiedetails -> Eindpunten & Referenties. Het oorspronkelijke invoerveld voor alleen-lezen-appgeheim is nu vervangen door een nieuwe geheime beheertabel. Je kunt geheimen maken, bijwerken en verwijderen in deze tabel.

## Organisatie- en applicatieniveau branding ### Organisatielogo Nu is het mogelijk om lichte en donkere logo's voor organisaties in te stellen. Je kunt de logo's uploaden op de pagina met organisatie-instellingen. Ook is het mogelijk om het logo van de inlogervaring van een organisatie te overschrijven. Voeg gewoon de `organization_id` parameter toe aan het authenticatieverzoek. In de meeste Logto SDK's kan dit worden gedaan door gebruik te maken van het `extraParams` veld in de `signIn` methode. Bijvoorbeeld in de JavaScript SDK: ```js import LogtoClient from '@logto/client'; const logtoClient = new LogtoClient(/* jouw configuratie */); logtoClient.signIn({ redirectUri: 'https://jouw-app.com/callback', extraParams: { organization_id: '', }, }); ``` De waarde `` kan worden gevonden op de pagina met organisatie-instellingen. Als je het `extraParams` veld niet kunt vinden in de SDK die je gebruikt, laat het ons dan weten. ### Applicatieniveau branding Je kunt nu logo's, favicons en kleuren voor je app instellen. Deze instellingen worden gebruikt in de inlogervaring wanneer de app de authenticatiestroom start. Voor apps die geen brandinginstellingen hebben, zal de omni inlogervaring branding worden gebruikt. Als `organization_id` wordt verstrekt in het authenticatieverzoek, zullen de app-niveau brandinginstellingen worden overschreven door de brandinginstellingen van de organisatie, indien beschikbaar. ## Prestatieverbeteringen ### Ondersteuning voor ervaring app server-side rendering Logto voegt nu de inlogervaring-instellingen en zinnen in het `index.html` bestand voor een betere eerste-schermprestatie. De ervaring app zal de instellingen en zinnen nog steeds van de server ophalen als: - De server de instellingen en zinnen niet heeft ingevoegd. - De parameters in de URL verschillen van server-gerenderde data. ### Pakket build verbeteringen - Gebruik `tsup` om de connectorpakketten te bouwen. Dit zal het bouwproces sneller maken, en zou de functionaliteit van de pakketten niet moeten beïnvloeden. - Gebruik `Vite` voor transpilatie en bundeling van de `@logto/console`, `@logto/demo-app` en `@logto/experience` pakketten. ParcelJS verwijderd en vervangen door Vite. Er zouden geen breaking changes verwacht moeten worden. ## Bugfixes ### Fix het jsonb-updategedrag van het `PATCH /api/applications/{applicationId}` eindpunt Alle jsonb-velden van het `Application` object zouden moeten worden bijgewerkt in de `vervang` modus in plaats van `samenvoegen` modus. Deze wijziging zal de `PATCH` methode voorspelbaarder maken en consistenter met het Restful API ontwerp. - Update de jsonb-veld-update modus van `samenvoegen` naar `vervang` in het `PATCH /api/applications/{applicationId}` eindpunt. - Update de API jsonb-veld-invoerparameters validatie van `gedeeltelijk` naar `volledig` in het `PATCH /api/applications/{applicationId}` eindpunt. - Beïnvloede velden: `oidc_client_metadata`, `custom_client_metadata`, `protected_app_metadata` en `custom_data`. > **Opmerking**: Als je Logto console gebruikt om de `Application` instellingen bij te werken, zou je niet beïnvloed moeten worden door deze wijziging. API-gebruikers die de `PATCH` methode gebruiken om de `Application` jsonb-veldinstellingen bij te werken, moeten zich bewust zijn van deze wijziging. De `PATCH` methode zal nu het hele jsonb veld vervangen door de nieuwe invoergegevens. Elke gedeeltelijke invoergegevens van de beïnvloede velden zal worden afgewezen. ### Fix sommige van de webhooks gebeurtenis payloads die altijd de API-responsestatus 404 problemen teruggeven Beïnvloede webhook-gebeurtenissen: `Role.Scopes.Updated`, `Organizations.Membership.Updates`. De API-responsstatuscode die werd geretourneerd door de webhook-gebeurtenis payload was altijd 404. Dat werd veroorzaakt door het invoegen van de webhook-gebeurtenis payload voordat de API-responscontext was ingesteld. Aangezien we de webhook alleen activeren wanneer de gebeurtenis met succes is verwerkt, zou de statuscode altijd 2xx moeten zijn. Dit probleem is opgelost door het invoegen van de webhook-gebeurtenis payload na de instelling van de API-responscontext. ## Andere verbeteringen - De favicon voor het donkere thema kan nu worden ingesteld in de inlogervaring brandinginstellingen. - Nieuwe wachtwoord digest algoritmen toegevoegd: `Argon2d` en `Argon2id`. Gebruikers met die algoritmen worden gemigreerd naar `Argon2i` na succesvolle inlog. - De browserlijstconfiguratie voor `@logto/experience` is gesynchroniseerd met wat vermeld staat in `README.md`. - Verbeter de swagger authenticatiebeschrijving. Gebruik het native OpenAPI OAuth2 beveiligingsschema in plaats van het aangepaste HTTP header-gebaseerde beveiligingsschema.