v1.19.0

<p align="center">
<img src="https://github.com/user-attachments/assets/21b5695d-4b21-4703-b4b2-71507899366c" witdh="800" />
</p>

## 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](https://docs.logto.io/docs/recipes/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.

<details>
<summary>Click to expand Management API updates</summary>

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

</details>

<details>
<summary>Click to expand Console updates</summary>

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

</details>

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

<details>
<summary>Click to expand management API updates</summary>

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

</details>

<details>
<summary>Click to expand Console updates</summary>

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.

</details>

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

```js
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.