Logto v1.42.0 добавляет файлы для проверки пользовательских доменов, allowlist-списки email с поддержкой wildcard-шаблонов, магические ссылки для сброса пароля, webhook Grant.LimitExceeded и обновление протокола с node-oidc-provider v9, Koa 3 и включённой по умолчанию защитой от SSRF.
SimengDeveloper
Хватит тратить недели на аутентификацию пользователей
Запускайте безопасные приложения быстрее с Logto. Интегрируйте аутентификацию пользователей за считанные минуты и сосредоточьтесь на вашем основном продукте.
Logto v1.42.0 — это релиз, сфокусированный на доменах и протоколах. Теперь команды могут подтверждать владение доменом без запуска отдельного хоста, точнее контролировать, какие email могут попадать в tenant, а также обеспечивать более плавный процесс сброса пароля для конечных пользователей. Внутри теперь Logto работает на node-oidc-provider v9 и Koa 3, а защита от SSRF для исходящих OIDC-запросов включена по умолчанию. Вот что нового.
Сторонние сервисы часто проверяют владение доменом, предлагая разместить небольшой файл по определённому пути. До этого для этого требовалось запускать отдельный хост рядом с пользовательским доменом Logto.
Теперь ты можешь прикреплять файлы подтверждения к активному пользовательскому домену через Console > Tenant settings > Domains. Каждый файл имеет:
Путь, который либо является именем файла на корневом уровне с расширением (например, /verify.txt), либо путем внутри /.well-known/.
Тип содержимого: text/plain или application/json. JSON содержимое валидируется при сохранении.
Размер содержимого до 16 КБ.
Можно настроить до 10 файлов на домен, и пути должны быть уникальными. Logto отдаёт точные совпадения GET и HEAD с настроенным типом содержимого и защитой ответа. Существующие маршруты Logto всегда имеют приоритет над файлом подтверждения на том же пути, так что неправильно настроенный файл никогда не перекроет настоящий endpoint. Консоль локализована на все поддерживаемые языки.
Так как Logto не вникает в содержимое файлов, это работает для любых схем подтверждения провайдеров без необходимости реализовывать поведение под каждого.
Правила доступа к email: allowlist и wildcard-шаблоны#
Политика blocklist для email расширяется в полный набор правил доступа, настраиваемых в Console > Security > Email blocklist.
Пользовательский allowlist email. Настрой свой список разрешённых адресов, доменов или wildcard-шаблонов. Когда allowlist установлен, только совпадающие email принимаются при новых регистрациях и при добавлении новых email — как при регистрации по email, так и при обновлении email аккаунта.
Wildcard-шаблоны. Allowlist и blocklist принимают wildcard-шаблоны адресов и доменов, например foo*@example.com, *@example.com и @*.example.com, а также точные адреса ([email protected]) и домены (@example.com).
Предупреждения о конфликтах. Консоль предупреждает, если запись в allowlist также подходит под правило blocklist, если запись в allowlist содержит плюс, а subaddressing выключен, либо если комбинированные правила не пропустят ни одного нового email.
Логика проверки и валидации реализована через общие помощники из @logto/core-kit, так что одни и те же правила используются везде, где email попадает в tenant.
Теперь приложение Experience поддерживает сценарии сброса пароля с проверкой магических ссылок с одноразовым токеном прямо со страницы сброса пароля, в дополнение к кодам подтверждения.
Когда OIDC-гранты удаляются потому, что приложение превысило максимальное количество разрешенных грантов, Logto теперь отправляет событие webhook Grant.LimitExceeded, которое можно выбрать в настройках Console webhook как и любое другое событие.
Payload содержит userId, applicationId, revokedGrantIds, maxAllowedGrants и preRevocationActiveGrantCount. Доставка идет по принципу "fire-and-forget": сбои записываются как TriggerHook.Grant.LimitExceeded в журнал аудита и никогда не блокируют ответ аутентификации.
Главное изменение — это исправление безопасности при отзыве токенов.
Отзыв непрозрачного access token теперь также отзывает все токены из того же гранта, включая refresh token. В v8 refresh token оставался рабочим после отзыва и мог запрашивать новые access token.
Другие обновления протокола в v9:
Endpoint для отзыва теперь отклоняет JWT access token c ошибкой unsupported_token_type, вместо возврата успешного ответа без фактического отзыва, как было в v8.
Метаданные authorization server согласно RFC 8414 доступны по адресу /oidc/.well-known/oauth-authorization-server.
Лишний claim at_hash убран из ID-токенов, выдаваемых на token endpoint.
ID-токены больше не содержат опциональный заголовок typ: "JWT". OpenID Connect определяет ID-токены как JWT и не требует проверки этого заголовка клиентами.
Требуется действие для собственной проверки ID токена. Если ты используешь официальный Logto SDK — ничего делать не надо. Если твоя интеграция выполняет свою валидацию ID токена, обнови её, чтобы позволять отсутствовать claim at_hash и заголовку typ: "JWT".
Теперь Logto работает на Koa 3 — актуальной версии, получающей патчи безопасности в первую очередь. Поведения не меняются: все endpoint, OIDC-потоки и API-ответы ведут себя так же, как раньше.
Внутренние секреты приложений больше не раскрываются через Management API.
Политика email blocklist больше не возвращается в публичных ответах процессов входа.
Для получения сохранённых access token сторонних провайдеров через Account API теперь требуется скоуп identities, соответственно другим social и enterprise SSO endpoint.
Коды подтверждения по API аккаунта больше не отправляются на заблокированные email-адреса.
Валидация email и домена email теперь учитывает полное значение и требует более строгие лейблы домена.
Если процесс социальной или SSO-регистрации отклонён по правилам доступа email, после подтверждения ошибки пользователь возвращается на страницу входа Logto, а не на внешний identity provider.
MFA теперь автоматически включается после привязки фактора через Account API.
При создании нового email- или SMS-коннектора теперь вставка и удаление старых коннекторов происходит в одной транзакции БД. Раньше сбой между этими операциями мог привести к дублированию коннекторов.
Учётные данные кластера Redis теперь percent-decoded, что позволяет успешно подключаться, если имя пользователя или пароль содержат специальные URL-символы.
TLS теперь корректно включается для соединений кластера Redis с протоколом rediss.
jose v6: Коннекторы Apple, Google, OAuth и OIDC теперь используют jose 6, который работает на Web Crypto API вместо Node crypto. Подпись токенов и проверка ID токенов не изменились.
GitLab: Удалена неиспользуемая зависимость jose, так что установка коннектора больше не подтягивает лишний пакет.
Aliyun SMS: Номера Гонконга теперь считаются зарубежными.
Aliyun SMS authentication service (MAS): Подпись теперь вводится свободным текстом, а не выбором из списка, чтобы продолжать работать при ротации подписей у Aliyun.
Требуется действие — защита OIDC-провайдера от SSRF. Безопасность исходящих запросов усилена, и защита от SSRF включена по умолчанию. Self-hosted-развёртываниям, которым нужно обращаться к доверенным relying-party endpoint во внутренних сетях, требуется установить OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true перед запуском Logto; иначе просто оставь переменную неустановленной.
Требуется миграция базы данных. В этом релизе есть изменения схемы БД для файлов подтверждения доменов, а также внутренние индексы и таблицы. После обновления, выполни команду изменения БД (npm run alteration deploy в образе @logto/cli/core или logto db alteration deploy) перед запуском новой версии. Подробности смотри в гайде по обновлению.
Пользовательская проверка ID токенов. См. раздел выше про node-oidc-provider v9 и изменения по at_hash и заголовку typ.
