Logto v1.43.0 добавляет динамические приложения с документами метаданных OAuth Client ID, подписанные SAML-запросы на аутентификацию, ограниченный по ресурсам runtime для Custom JWT и Actions, более строгую валидацию обмена токенов и расширенную защиту SSRF для вебхуков и корпоративного SSO.
CharlesDeveloper
Хватит тратить недели на аутентификацию пользователей
Запускайте безопасные приложения быстрее с Logto. Интегрируйте аутентификацию пользователей за считанные минуты и сосредоточьтесь на вашем основном продукте.
Logto v1.43.0 расширяет возможности соединения приложений и корпоративных провайдеров идентичности, усиливая границы безопасности вокруг токенов и исходящих запросов. Введены динамические приложения с документами метаданных OAuth Client ID, подписанные SAML-запросы на аутентификацию и консолидированный runtime для Custom JWT и Actions. В этом релизе также ужесточены обмен токенов, вебхуки и корпоративный SSO, улучшен Account Center, добавлена поддержка испанского (Мексика) и исправлены ошибки стабильности. Вот что нового.
Вход теперь поддерживает es-MX (испанский, Мексика).
Для пользователей, выбравших язык испанский (Мексика), по умолчанию в телефонных полях устанавливается код страны Мексика (+52). В этом релизе также исправлены плейсхолдеры форматирования списков и оставшееся непереведённое MFA-сообщение в испанских локалях.
Исходящие запросы, настроенные через Management API, теперь блокируются, если они приводят к loopback, приватным, link-local, cloud metadata или другим специальным адресам.
Защита распространяется на:
Доставку вебхуков, включая POST /api/hooks/:id/test.
OIDC discovery, запросы токенов и userinfo для корпортивного SSO.
В дополнение к требованию токенов субъектов только для first-party, Logto теперь проверяет, что JWT, предоставляемый как субъект access_token, действительно является токеном доступа.
JWT должен содержать:
Header типа RFC 9068 at+jwt.
Claim client_id.
OIDC ID токены и другие JWT от этого tenant больше нельзя подменять под access token. Неправильные токены субъектов отклоняются с ошибкой invalid_grant.
Ограничения API аккаунтов для сторонних приложений#
Сторонние приложения больше не могут изменять данные аккаунта через Account API или Verification API. Такие запросы теперь возвращают:
First-party приложения, включая Account Center и Console, не затрагиваются.
Проверка всегда "fail-closed" для неизвестных идентификаторов клиента. Это включает удалённые приложения, access tokens которых всё ещё активны, и CIMD-клиенты, идентификатор которых является URL метаданных.
Ни один маршрут только для чтения не получил новый прямой guard. Тем не менее, следующие операции чтения требуют verification records, созданных через защищённые маршруты, и теперь недоступны для сторонних приложений:
GET /api/my-account/grants
GET /api/my-account/sessions
GET /api/my-account/mfa-verifications/backup-codes
Заблокированные пользователи не могут получать новые токены#
Выдача токенов и userinfo теперь отклоняют заблокированных пользователей с ошибкой invalid_grant, что соответствует существующему поведению для удалённых пользователей.
Это применимо для всех сценариев — refresh token, authorization code, device code и обмен токенами — даже если предыдущий токен или отзыв сессии не был завершён.
Удаление скоупа пользователя из конфигурации согласия стороннего приложения теперь влияет как на существующие grants, так и на новые запросы авторизации.
Обмен refresh-токена удаляет скоупы, которые больше не разрешены.
Запросы авторизации, возобновляющие существующий grant, завершаются с invalid_scope при необходимости.
Запросы токенов организации завершаются с insufficient_scope, если скоуп organizations был удалён.
Передача согласия больше не даёт скоуп, который был удалён во время открытого экрана согласия.
Lockout по идентификаторам использует нормализованные идентификаторы#
Счётчики Sentinel lockout теперь используют такую же нормализацию идентификаторов, как и при поиске пользователя:
Email-адреса приводятся к нижнему регистру.
Номера телефонов канонизируются.
Usernames приводятся к одному регистру только если политика tenant на username регистронезависимая.
Это предотвращает создание отдельных "bucket" попыток для разных написаний одного идентификатора и ослабления ограничения maxAttempts.
Ручная разблокировка также очищает все эквивалентные написания, если они относятся к одной учётке. После обновления существующая блокировка, записанная под альтернативным написанием, может закончиться раньше, но никто не станет более заблокированным, чем раньше.
Safari и другие менеджеры паролей теперь могут предлагать и сохранять надёжный пароль на экранах установки и сброса пароля с корректным идентификатором аккаунта.
Accept-Language с quality с пробелами, например en; q=0.7, теперь парсится корректно. Некорректные quality значения безопасно приводятся к дефолту вместо NaN.
Алгоритмы сопоставления кастомного allowlist и blocklist для Gmail теперь считают gmail.com и googlemail.com эквивалентными и игнорируют точки в локальной части.
Консоль теперь даёт более понятные примеры, описания и сокращённые плейсхолдеры для кастомных email-правил.
Сохранение настроек Account Center или signup теперь убирает ссылки на удалённые кастомные поля профиля вместо ошибки custom_profile_fields.entity_not_exists_with_names.
Удалённые поля можно удалить в Console даже если permission control для них выключен.
Endpoints relation Management API теперь принимают пустой массив scope или roles как no-op вместо 500-й ошибки. Это касается, например:
POST /applications/:applicationId/user-consent-scopes
POST /organizations/:id/users/:userId/roles
Валидация даты теперь сравнивает всё поле и отклоняет лишние символы после допустимой даты.
Коннектор Microsoft Azure AD теперь поддерживает опцию disableEmailSync.
По умолчанию коннектор копирует атрибут Microsoft Graph mail в профиль пользователя Logto. Включите эту настройку, если нужно, чтобы коннектор только аутентифицировал пользователя без синхронизации email, как уже возможно для Azure OIDC enterprise SSO.
Требуется действие — защита исходящих запросов: Если ваши webhook или корпоративные SSO-коннекторы специально работают с сервисами в приватной сети, добавьте нужные IP или CIDR в SSRF_ALLOWED_ADDRESSES перед обновлением:
Добавлять только нужные адреса безопаснее, чем выключать защиту глобально.
Совместимость динамических приложений: Настройка SSRF_ALLOWED_ADDRESSES отключает CIMD, чтобы неаутентифицированные динамические клиенты не могли использовать allowlist для доступа к приватным сервисам. Переменная SSRF_PROTECTION_DISABLED=true тоже отключает CIMD.
Совместимость конфигурации: OIDC_PROVIDER_SSRF_PROTECTION_DISABLED по-прежнему поддерживается как алиас для SSRF_PROTECTION_DISABLED. Эти переменные применяются только для self-hosted развертываний.
Ограничения на выполнение скриптов: Скрипты Custom JWT и Actions должны завершиться за 5 секунд, уложиться в лимит памяти воркера 128 MB и возвращать значения, сериализуемые в JSON.
Требуется миграция БД: В релизе новые изменения схемы БД и индексов. После обновления обязательно выполните команду по изменению БД (npm run alteration deploy в образе @logto/cli/core либо logto db alteration deploy) перед запуском новой версии. Подробнее смотрите руководство по обновлению.
