Что такое пользовательский домен для аутентификации и почему важны несколько доменов
Узнайте, как пользовательские домены для аутентификации и несколько доменов повышают конверсию, безопасность и узнаваемость бренда; и как Logto помогает управлять ими без головной боли с DNS.
RanProduct & Design
Хватит тратить недели на аутентификацию пользователей
Запускайте безопасные приложения быстрее с Logto. Интегрируйте аутентификацию пользователей за считанные минуты и сосредоточьтесь на вашем основном продукте.
Если вы когда-либо выпускали продукт чуть быстрее, чем следовало бы, эта история покажется знакомой.
Ваше приложение отлично работает на 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 и стабильностью; ваш апекс-домен останется свободным для основного сайта.
Изменение увиденного пользователем домена входа — лишь часть истории. С момента, как вы включаете собственный домен для аутентификации, вы затрагиваете:
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 — и дело с концом", почти наверняка что-то сломается в другом месте.
Мысленная схема: как домен входа проходит через стек#
Представьте диаграмму, где браузер пользователя стартует с:
Строка адреса в браузере
Пользователь кликает Войти на https://example.com.
Его перенаправляют на https://auth.example.com/sign-in.
Authorization server и discovery-документ
Ваше приложение обращается к endpoint OpenID-конфигурации: https://auth.example.com/oidc/.well-known/openid-configuration
Это сообщает приложению, куда отправлять запросы аутентификации и где получать токены.
Redirect-URI (callback OIDC/OAuth)
После входа в Logto пользователя перенаправляет обратно в ваше приложение, например: https://app.example.com/callback
IdP и приложение должны быть согласованы в этих URL.
Переходы с соцсетями/корпоративным SSO
С сайта auth.example.com пользователь может перейти на Google, Microsoft Entra ID, Okta и др.
Эти сервисы также видят и валидируют redirect URI, включающие ваш пользовательский домен.
Письма и магические ссылки / ссылки на сброс пароля
Ссылки в письмах также должны вести на ваш пользовательский домен, чтобы не сбивать с толку пользователей.
На каждом шаге домен важен. Подключив кастомный домен входа, вы хотите, чтобы он "проходил" по всей цепочке согласованно.
Поэтому продуманная стратегия пользовательских доменов — это не про трюки с DNS, а про целостный дизайн идентификации.
Для многих команд одного пользовательского домена вроде auth.example.com вполне достаточно. Но по мере роста продукта, географии и клиентской базы вы быстро упрётесь в ограничения, если не подойти к этому заранее.
Вот как разные команды обычно сопоставляют домены аутентификации с пользовательским опытом:
Сценарий
Примеры доменов
Почему это полезно
Один брендированный вход
auth.example.com, account.example.com
Сохраняет брендированный адрес, пока стандартный домен {{tenant-id}}.app.logto доступен для тестов.
Для каждого бренда — свой целостный логин-экспириенс без фрагментации identity-стека.
Несколько TLD
auth.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, выпускает сертификаты и продлевает их автоматически. Не нужен ручной менеджмент ключей и нет риска внезапных просрочек.
