Logto productupdates (augustus 2024)

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 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:

De waarde <organization-id> 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.