Ontdek onze release van augustus 2024 met gebruikersnabootsing, applicatiegeheimenbeheer, organisatie- en applicatieniveaus voor inlogervaring branding, en veel meer.
Ondersteuning toegevoegd voor gebruikersnabootsing via Token Exchange:
POST /subject-tokens om een subject_token aan te vragen voor gebruik bij tokenuitwisseling.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.
custom_dataEen nieuw willekeurig objectveld custom_data toegevoegd aan applicaties. Dit veld kan alle aanvullende informatie opslaan die niet is gedefinieerd in het standaard Application schema.
PATCH /api/applications/{applicationId}/custom-data eindpunt om het custom_data veld van een applicatie bij te werken.PATCH /api/applications/{applicationId} eindpunt om het custom_data veld te overschrijven.Nieuwe JSON-editor voor aangepaste data toegevoegd aan de applicatiedetailpagina (behalve voor beveiligde apps).
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.
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.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.
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.
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.
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:
tsup om de connectorpakketten te bouwen. Dit zal het bouwproces sneller maken, en zou de functionaliteit van de pakketten niet moeten beïnvloeden.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.PATCH /api/applications/{applicationId} eindpuntAlle 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.
samenvoegen naar vervang in het PATCH /api/applications/{applicationId} eindpunt.gedeeltelijk naar volledig in het PATCH /api/applications/{applicationId} eindpunt.oidc_client_metadata, custom_client_metadata, protected_app_metadata en custom_data.Opmerking: Als je Logto console gebruikt om de
Applicationinstellingen bij te werken, zou je niet beïnvloed moeten worden door deze wijziging. API-gebruikers die dePATCHmethode gebruiken om deApplicationjsonb-veldinstellingen bij te werken, moeten zich bewust zijn van deze wijziging. DePATCHmethode zal nu het hele jsonb veld vervangen door de nieuwe invoergegevens. Elke gedeeltelijke invoergegevens van de beïnvloede velden zal worden afgewezen.
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.
Argon2d en Argon2id. Gebruikers met die algoritmen worden gemigreerd naar Argon2i na succesvolle inlog.@logto/experience is gesynchroniseerd met wat vermeld staat in README.md.