Skip to content

v1.19.0

Compare
Choose a tag to compare
@silverhand-bot silverhand-bot released this 08 Aug 06:59
· 253 commits to master since this release
v1.19.0
ddfa7aa

User impersonation (RFC 8693: OAuth 2.0 Token Exchange)

Added support for user impersonation via Token Exchange:

  • New Management API endpoint POST /subject-tokens to request a subject_token for token exchange use.
  • Updated the OIDC 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.

Application level custom_data

Added a new arbitrary object field custom_data to applications. This field can store any additional information not defined in the standard Application schema.

Click to expand Management API updates
  • New PATCH /api/applications/{applicationId}/custom-data endpoint to patch update the custom_data field of an application.
  • Update PATCH /api/applications/{applicationId} endpoint to allow overwriting the custom_data field.
Click to expand Console updates

Added a new custom data JSON editor to the application details page (except for Protected Apps).

Multiple app secrets management

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.

Click to expand management API updates
  • 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.
Click to expand Console updates

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.

Organization and application level branding

Organization logo

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:

import LogtoClient from '@logto/client';

const logtoClient = new LogtoClient(/* your configuration */);

logtoClient.signIn({
  redirectUri: 'https://your-app.com/callback',
  extraParams: {
    organization_id: '<organization-id>',
  },
});

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.

Application level branding

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.

Performance improvements

Support experience app server-side rendering

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:

  • The server didn't inject the settings and phrases.
  • The parameters in the URL are different from server-rendered data.

Package build improvements

  • Use tsup to build the connector packages. This will make the build process faster, and should not affect the functionality of the packages.
  • User 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.

Bug fixes

Fix the jsonb update behavior of the PATCH /api/applications/{applicationId} endpoint

All the jsonb fields of the Application object should be updated in the replace mode instead of the merge mode. This change will make the PATCH method more predictable and consistent with the Restful API design.

  • Update the jsonb field update mode from merge to replace in the PATCH /api/applications/{applicationId} endpoint.
  • Update the API jsonb field input parameters validation from partial to full in the PATCH /api/applications/{applicationId} endpoint.
  • Affected fields: oidc_client_metadata, custom_client_metadata, protected_app_metadata and custom_data.

Note

If you are using Logto console to update the Application settings, you should not be affected by this change. API users who are using the PATCH method to update the Application jsonb field settings should be aware of this change. The PATCH method will now replace the whole jsonb field with the new input data. Any partial input data of the affected fields will be rejected.

Fix some of the webhooks event payload always return API response status 404 bug

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, 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.

Other improvements

  • The favicon for the dark theme now can be set in the sign-in experience branding settings.
  • Add new password digest algorithms: Argon2d and Argon2id. Users with those algorithms will be migrated to Argon2i upon successful sign-in.
  • The browser list configuration for @logto/experience has been synced with what is stated in README.md.
  • Improve swagger auth description. Use the native OpenAPI OAuth2 security scheme instead of the custom HTTP header-based security schema.