Explore our August 2024 release featuring user impersonation, application secrets management, organization and application level sign-in experience branding, and much more.
Added support for user impersonation via Token Exchange:
POST /subject-tokens to request a subject_token for token exchange use.POST /oidc/token endpoint with a new grant type urn:ietf:params:oauth:grant-type:token-exchange to exchange a subject_token for a user-impersonated access_token.See User impersonation for more details.
custom_dataAdded a new arbitrary object field custom_data to applications. This field can store any additional information not defined in the standard Application schema.
PATCH /api/applications/{applicationId}/custom-data endpoint to patch update the custom_data field of an application.PATCH /api/applications/{applicationId} endpoint to allow overwriting the custom_data field.Added a new custom data JSON editor to the application details page (except for Protected Apps).
Secure apps (machine-to-machine, traditional web, Protected) can now have multiple app secrets with expiration. This allows for secret rotation and provides an even safer experience.
Note: The legacy secret created before this feature can still be used for client authentication. However, it is recommended to delete the old ones and create new secrets with expiration for enhanced security.
GET /api/applications/{applicationId}/secrets: List all the secrets of an application.POST /api/applications/{applicationId}/secrets: Create a new secret for an application.DELETE /api/applications/{applicationId}/secrets/{name}: Delete a secret of an application by name.PATCH /api/applications/{applicationId}/secrets/{name}: Update a secret of an application by name.DELETE /api/applications/{applicationId}/legacy-secret: Delete the legacy secret of an application and replace it with a new one.To manage your application secrets, go to Logto Console -> Applications -> Application Details -> Endpoints & Credentials.
The original app secret read-only input field is now replaced with a new secrets management table. You can create, update, and delete secrets in this table.
Now it's able to set light and dark logos for organizations. You can upload the logos in the organization settings page.
Also, it's possible to override the sign-in experience logo from an organization. Simply add the organization_id parameter to the authentication request. In most Logto SDKs, it can be done by using the extraParams field in the signIn method.
For example, in the JavaScript SDK:
The value <organization-id> can be found in the organization settings page.
If you could not find the extraParams field in the SDK you are using, please let us know.
You can now set logos, favicons, and colors for your app. These settings will be used in the sign-in experience when the app initiates the authentication flow. For apps that have no branding settings, the omni sign-in experience branding will be used.
If organization_id is provided in the authentication request, the app-level branding settings will be overridden by the organization's branding settings, if available.
Logto now injects the sign-in experience settings and phrases into the index.html file for better first-screen performance. The experience app will still fetch the settings and phrases from the server if:
tsup to build the connector packages. This will make the build process faster, and should not affect the functionality of the packages.Vite for transpilation and bundling of the @logto/console, @logto/demo-app and @logto/experience packages. Removed ParcelJS and replaced with Vite. No breaking changes should be expected.PATCH /api/applications/{applicationId} endpointAll the jsonb fields of the Application object should be updated in the replace mode instead of merge mode. This change will make the PATCH method more predictable and consistent with the Restful API design.
merge to replace in the PATCH /api/applications/{applicationId} endpoint.partial to full in the PATCH /api/applications/{applicationId} endpoint.oidc_client_metadata, custom_client_metadata, protected_app_metadata and custom_data.Note: If you are using Logto console to update the
Applicationsettings, you should not be affected by this change. API users who are using thePATCHmethod to update theApplicationjsonb field settings should be aware of this change. ThePATCHmethod will now replace the whole jsonb field with the new input data. Any partial input data of the affected fields will be rejected.
Affected webhook events: Role.Scopes.Updated, Organizations.Membership.Updates.
The API response status code returned from the webhook event payload was always 404. That was caused by inserting the webhook event payload before the API response context was set.
Since we only trigger the webhook when the event is successfully processed, so the status code should always be 2xx.
This issue have been fixed by moving the webhook event payload insertion after the API response context is set.
Argon2d and Argon2id. Users with those algorithms will be migrated to Argon2i upon successful sign in.@logto/experience has been synced with what is stated in README.md.