Русский
  • Пользовательские домены
  • Несколько доменов
  • Аутентификация

Что такое пользовательский домен для аутентификации и почему важны несколько доменов

Узнайте, как пользовательские домены для аутентификации и несколько доменов повышают конверсию, безопасность и узнаваемость бренда; и как Logto помогает управлять ими без головной боли с DNS.

Ran
Ran
Product & Design

Хватит тратить недели на аутентификацию пользователей
Запускайте безопасные приложения быстрее с Logto. Интегрируйте аутентификацию пользователей за считанные минуты и сосредоточьтесь на вашем основном продукте.
Начать
Product screenshot

Если вы когда-либо выпускали продукт чуть быстрее, чем следовало бы, эта история покажется знакомой.

Ваше приложение отлично работает на example.com. Маркетинг запускает кампании, пользователи регистрируются — всё выглядит безупречно. Затем новый пользователь нажимает Войти.

Вместо привычного URL вроде auth.example.com браузер перебрасывает пользователя на адрес, похожий на тестовую среду: my-tenant-123.app.logto

Технически всё в порядке. Страница защищена. Вход работает. Но первая реакция пользователя:

"Постой, куда меня только что отправили?"

Эта секунда сомнений — момент, когда пользователи уходят.

  • С точки зрения конверсии, вход в систему — самое узкое место вашей воронки. Любой лишний момент "Что это за домен?" создает трение.
  • С позиции безопасности пользователям годами внушали "проверяйте адрес сайта". Если домен для входа не совпадает с брендом, он выглядит больше как фишинг, чем "боевая" версия.

Не зря почти каждая крупная компания использует:

  • login.company.com
  • auth.company.com
  • accounts.company.com

Они делают это не ради забавы. Логин-домен — часть пользовательского опыта продукта.

В этой статье мы разберём:

  • Что такое пользовательский домен для аутентификации
  • Когда одного домена для входа достаточно — и когда стоит задуматься о нескольких
  • Самые частые ошибки с доменами входа (и как избежать ада "redirect URI не совпадает")
  • Как поддержка пользовательских доменов в Logto помогает решить все эти задачи без превращения вас в инженера по DNS

Что такое пользовательский домен для аутентификации?

Объясним просто.

Каждый клиент Logto получает домен по умолчанию: {{tenant-id}}.app.logto. То есть раньше пользователей отправляло вот сюда: https://my-tenant-123.app.logto/sign-in.

Пользовательский домен для аутентификации заменяет этот видимый URL на ваш собственный — например, auth.example.com. Теперь пользователи остаются на вашем бренде: https://auth.example.com/sign-in.

Служба аутентификации — та же самая "под капотом". Впечатление — совсем другое.

Почему поддомены, а не корневые домены?

В Logto пользовательские домены реализованы как поддомены, например:

  • auth.example.com
  • auth.us.example.com

Практически, так и нужно для аутентификации:

  • Корневой домен обычно резервируется под главный сайт (example.com).
  • Для "зоны апекса" DNS нельзя использовать CNAME, а хостинговый логин Logto требует CNAME на domains.logto.app для маршрутизации трафика.
  • Logto управляет сертификатами через Cloudflare. Для завершения TLS на корневом домене пришлось бы контролировать всю зону (включая ваши A, MX, TXT и др.), что невозможно для мультиарендных SaaS.

Apex-записи с выравниванием (ALIAS/ANAME) по-прежнему резолвятся на IP, которыми мы не владеем, поэтому нельзя использовать наши управляемые сертификаты. Коротко: хостинговый логин должен быть на поддомене. Пропишите на него CNAME — Logto займётся верификацией, SSL и стабильностью; ваш апекс-домен останется свободным для основного сайта.

Почему недостаточно "просто добавить CNAME"

Очень частое заблуждение:

"Я просто добавлю CNAME в DNS и всё готово, да?"

К сожалению, нет.

Изменение увиденного пользователем домена входа — лишь часть истории. С момента, как вы включаете собственный домен для аутентификации, вы затрагиваете:

  • URL страницы входа и регистрации Пользователи теперь посещают https://auth.example.com/... для хостинговых страниц.

  • OIDC/OAuth redirect URI Ваши приложения и коннекторы должны использовать тот же домен в redirect/callback-URL, иначе получите ошибку типа redirect_uri_mismatch.

  • Вход через соцсети и корпоративные SSO (IdP) Google, GitHub, Azure AD, Okta и другие валидируют redirect URI или ACS URL, включая домен.

  • Passkeys (WebAuthn) Passkeys привязаны к точному домену, на котором были зарегистрированы. Если изменить домен — passkeys работать не будут.

  • Конфигурация SDK Ваши SDK Logto используют endpoint, указывающий на домен клиента. Если endpoint использует неверный домен, приложение и идентификационный слой рассинхронизируются.

DNS? Конечно, он нужен. Но если мыслить только как "Я добавил CNAME — и дело с концом", почти наверняка что-то сломается в другом месте.

Мысленная схема: как домен входа проходит через стек

Представьте диаграмму, где браузер пользователя стартует с:

  1. Строка адреса в браузере

    • Пользователь кликает Войти на https://example.com.
    • Его перенаправляют на https://auth.example.com/sign-in.

  2. Authorization server и discovery-документ

    • Ваше приложение обращается к endpoint OpenID-конфигурации:
      https://auth.example.com/oidc/.well-known/openid-configuration
    • Это сообщает приложению, куда отправлять запросы аутентификации и где получать токены.

  3. Redirect-URI (callback OIDC/OAuth)

    • После входа в Logto пользователя перенаправляет обратно в ваше приложение, например:
      https://app.example.com/callback
    • IdP и приложение должны быть согласованы в этих URL.

  4. Переходы с соцсетями/корпоративным SSO

    • С сайта auth.example.com пользователь может перейти на Google, Microsoft Entra ID, Okta и др.
    • Эти сервисы также видят и валидируют redirect URI, включающие ваш пользовательский домен.

  5. Письма и магические ссылки / ссылки на сброс пароля

    • Ссылки в письмах также должны вести на ваш пользовательский домен, чтобы не сбивать с толку пользователей.

На каждом шаге домен важен. Подключив кастомный домен входа, вы хотите, чтобы он "проходил" по всей цепочке согласованно.

Поэтому продуманная стратегия пользовательских доменов — это не про трюки с DNS, а про целостный дизайн идентификации.

Один или несколько пользовательских доменов

Для многих команд одного пользовательского домена вроде auth.example.com вполне достаточно. Но по мере роста продукта, географии и клиентской базы вы быстро упрётесь в ограничения, если не подойти к этому заранее.

Вот как разные команды обычно сопоставляют домены аутентификации с пользовательским опытом:

СценарийПримеры доменовПочему это полезно
Один брендированный входauth.example.com, account.example.comСохраняет брендированный адрес, пока стандартный домен {{tenant-id}}.app.logto доступен для тестов.
По регионамauth.us.example.com, auth.eu.example.com, auth.apac.example.comЛокализовать контент, consent-страницы и уведомления по географии внутри одного клиента.
По окружениямauth.staging.example.com, auth.example.comИзолировать QA/preview-трафик без дублирования клиентов или коннекторов.
White-labeling по клиентамauth.customer-a.com, auth.customer-b.comПредлагать "белые метки" для крупных заказчиков, управляя пользователями и SSO централизованно.
По бренду/продуктамauth.shop.example.com, auth.app.example.com, auth.studio.example.comДля каждого бренда — свой целостный логин-экспириенс без фрагментации identity-стека.
Несколько TLDauth.foo.com, auth.foo.co.uk, auth.foo.devПоддержка различных региональных/целевых сайтов без копирования конфигов.
По инфраструктуреauth.edge.example.com, auth.api.example.comСовмещение с правилами CDN/edge-маршрутизации при сохранении Logto как identity-бэкенда.

Как Logto облегчает работу с пользовательскими доменами

Вот что Logto даёт "из коробки" — без необходимости становиться специалистом по DNS или PKI:

  • Один клиент — много доменов. Сопоставляйте регионы, окружения, клиентов или бренды со своими доменами логина без копирования клиентов. Лимиты тарифа существуют, но главное: одна идентификация, много точек входа.
  • Домен по умолчанию продолжает работать. Добавление auth.example.com не отключает {{tenant-id}}.app.logto. Используйте дефолтный для внутренних инструментов или плавного релиза, а продакшн-трафик ведите на брендированный домен.
  • Коннекторы подстраиваются сами. SDK направлен на правильный endpoint, а коннекторы SSO и социальных сетей включают все разрешённые redirect URI/ACS URL для каждого домена — никакой ручной подгонки.
  • SSL на автопилоте. После добавления CNAME Logto проверяет DNS, выпускает сертификаты и продлевает их автоматически. Не нужен ручной менеджмент ключей и нет риска внезапных просрочек.

Что делать дальше

Если вы дочитали до этого места, вы скорее всего в одной из двух ситуаций.

Уже используете Logto?

Можете сразу попробовать работу с несколькими пользовательскими доменами:

  • Откройте Console > Settings > Domains. Добавьте второй домен для нового региона или под крупного заказчика, который хочет свой фирменный логин и т. д.
  • Обновите endpoint в SDK, где это требуется.
  • Добавьте redirect URI и ACS URL для нового домена из настроек Social/SSO-коннекторов в ваши IdP.

Это простой способ улучшить логин-экспириенс и проверить влияние на доверие и конверсию пользователей.

Новичок в Logto?

Если вы только начинаете:

  • Зарегистрируйтесь на Logto и создайте клиента.
  • Откройте Console > Settings > Domains. Используйте бесплатную квоту для добавления auth.example.com как домена логина "с первого дня".
  • Оставьте дефолтный домен {{tenant-id}}.app.logto для внутренних нужд или тестов.

Вы с самого начала избежите проблемы "урл логина выглядит как staging", а когда появится рост — не придётся устраивать больную миграцию доменов.

Хотите подробную пошаговую инструкцию с DNS-записями и советами по отладке? Полный гайд в нашей документации: Пользовательские домены для Logto Cloud.