## Подмена пользователя (RFC 8693: OAuth 2.0 Обмен Токенами) Добавлена поддержка подмены пользователя через Обмен Токенами: - Новый конечный пункт в Management API `POST /subject-tokens` для запроса `subject_token` для использования в обмене токенов. - Обновлён конечный пункт OIDC `POST /oidc/token` с новым типом гранта `urn:ietf:params:oauth:grant-type:token-exchange` для обмена `subject_token` на `access_token` для подменённого пользователя. Смотрите [Подмена пользователя](https://docs.logto.io/docs/recipes/impersonation/) для получения дополнительных сведений. ## `custom_data` на уровне приложения Добавлено новое произвольное объектное поле `custom_data` для приложений. Это поле может хранить любую дополнительную информацию, не определённую в стандартной схеме `Application`.

Нажмите для просмотра обновлений Management API

- Новый конечный пункт `PATCH /api/applications/{applicationId}/custom-data` для частичного обновления поля `custom_data` приложения. - Обновление конечного пункта `PATCH /api/applications/{applicationId}` для возможности перезаписи поля `custom_data`.

Нажмите для просмотра обновлений Консоли

Добавлен новый JSON-редактор для пользовательских данных на странице сведений о приложении (за исключением защищённых приложений).

## Управление несколькими секретами приложения Защищённые приложения (машина-машина, традиционные веб, защищённые) теперь могут иметь несколько секретов приложений с истечением срока действия. Это позволяет выполнять ротацию секретов и обеспечивает ещё более безопасный опыт. > **Примечание**: Старые секреты, созданные до этой функции, всё ещё могут использоваться для аутентификации клиента. Однако рекомендуется удалить старые секреты и создать новые с истечением срока действия для усиления безопасности.

Нажмите для просмотра обновлений Management API

- `GET /api/applications/{applicationId}/secrets`: Перечислить все секреты приложения. - `POST /api/applications/{applicationId}/secrets`: Создать новый секрет для приложения. - `DELETE /api/applications/{applicationId}/secrets/{name}`: Удалить секрет приложения по имени. - `PATCH /api/applications/{applicationId}/secrets/{name}`: Обновить секрет приложения по имени. - `DELETE /api/applications/{applicationId}/legacy-secret`: Удалить старый секрет приложения и заменить его новым.

Нажмите для просмотра обновлений Консоли

Для управления секретами приложения перейдите в Logto Консоль -> Приложения -> Сведения о приложении -> Конечные пункты и Учётные данные. Поле для ввода старого секрета приложения теперь заменено на новую таблицу управления секретами. В этой таблице можно создавать, обновлять и удалять секреты.

## Брендинг на уровне организации и приложения ### Логотип организации Теперь можно установить светлые и тёмные логотипы для организаций. Вы можете загрузить логотипы на странице настроек организации. Также можно переопределить логотип для входа, установив логотип организации. Просто добавьте параметр `organization_id` в запрос аутентификации. В большинстве SDK Logto это можно сделать, используя поле `extraParams` в методе `signIn`. Например, в JavaScript SDK: ```js import LogtoClient from '@logto/client'; const logtoClient = new LogtoClient(/* ваш конфиг */); logtoClient.signIn({ redirectUri: 'https://your-app.com/callback', extraParams: { organization_id: '', }, }); ``` Значение `` можно найти на странице настроек организации. Если вы не нашли поле `extraParams` в используемом вами SDK, пожалуйста, дайте нам знать. ### Брендинг на уровне приложения Теперь вы можете установить логотипы, фавиконы и цвета для вашего приложения. Эти настройки будут использоваться в процессе входа, когда приложение инициирует аутентификационный процесс. Если для приложения не заданы настройки брендинга, будет использоваться общий брендинг для процесса входа. Если в запросе аутентификации указан параметр `organization_id`, настройки брендинга на уровне приложения будут переопределены настройками брендинга организации, если они доступны. ## Улучшения производительности ### Поддержка рендеринга на стороне сервера для приложения опыта Logto теперь внедряет настройки и фразы для процесса входа непосредственно в файл `index.html` для повышения производительности первой загрузки экрана. Приложение всё ещё будет запрашивать настройки и фразы с сервера, если: - Сервер не внедрил настройки и фразы. - Параметры в URL отличаются от данных, сгенерированных на сервере. ### Улучшения в процессе сборки пакетов - Использование `tsup` для сборки пакетов коннекторов. Это ускорит процесс сборки и не должно влиять на функциональность пакетов. - Использование `Vite` для транспиляции и сборки пакетов `@logto/console`, `@logto/demo-app` и `@logto/experience`. ParcelJS был удалён и заменён на Vite. Серьёзные изменения быть не должны. ## Исправления ошибок ### Исправлено поведение обновления jsonb в конечном пункте `PATCH /api/applications/{applicationId}` Все поля jsonb объекта `Application` теперь должны обновляться в режиме `replace` вместо `merge`. Это изменение сделает метод `PATCH` более предсказуемым и согласованным с проектированием RESTful API. - Обновление режима обновления поля jsonb с `merge` на `replace` в конечном пункте `PATCH /api/applications/{applicationId}`. - Обновление проверки параметров ввода jsonb поля в конечном пункте `PATCH /api/applications/{applicationId}` с `partial` на `full`. - Затронутые поля: `oidc_client_metadata`, `custom_client_metadata`, `protected_app_metadata` и `custom_data`. > **Примечание**: Если вы используете консоль Logto для обновления настроек `Application`, это изменение не должно вас затронуть. Пользователям API, использующим метод `PATCH` для обновления настроек jsonb поля приложения, следует учитывать это изменение. Метод `PATCH` теперь будет заменять всё поле jsonb новыми данными. Любые частичные данные для затронутых полей будут отклонены. ### Исправлено некорректное состояние статуса API в вебхуках Затронутые события вебхуков: `Role.Scopes.Updated`, `Organizations.Membership.Updates`. Статус API, возвращаемый из вебхука, всегда был 404. Это было вызвано вставкой данных перед установкой контекста API ответа. Поскольку вебхук срабатывает только при успешной обработке события, статус ответа должен всегда быть 2xx. Эта проблема была исправлена путём перемещения вставки данных вебхука после установки контекста API ответа. ## Другие улучшения - Теперь фавикон для тёмной темы можно установить в настройках брендинга процесса входа. - Добавлены новые алгоритмы дайджеста паролей: `Argon2d` и `Argon2id`. Пользователей с этими алгоритмами переведут на `Argon2i` при успешном входе. - Конфигурация списка браузеров для `@logto/experience` синхронизирована с тем, что указано в `README.md`. - Улучшено описание аутентификации в Swagger. Использована нативная схема безопасности OAuth2 OpenAPI вместо настраиваемой схемы безопасности на основе HTTP-заголовков.