Как настроить единый SSO для нескольких витрин на разных доменах с сохранением сессии

Что подготовить до начала работ

Прежде чем начинать настройку SSO, соберите исходные данные. Нужно иметь список доменов витрин и их точные redirect-URI, доступ к системе управления DNS, SSL-сертификаты для всех доменов и информацию о выбранном Identity Provider (IdP) — это может быть внешнее облачное решение или собственный сервер авторизации (например, IdentityServer/Keycloak). Подготовьте доступы к коду витрин и к серверной части, где будет происходить обмен токенов.

Также заранее определите требования к сессиям: как долго должна жить сессия на витрине, нужно ли продление без повторного логина и какие данные профиля нужны при передаче. Решите, где будут храниться refresh-токены: на сервере витрины, в центральном хранилище сессий или у IdP. От этого зависит безопасность и поведение при выходе пользователя.

Наконец, подготовьте инструменты для тестирования: отдельные тестовые домены или поддомены, набор пользователей для теста, доступ к логам и инструментам типа curl/Postman и браузерные инструменты разработчика. Желательно заранее продумать план отката, если при запуске возникнут ошибки.

• Список доменов и redirect-URI
• SSL-сертификаты
• Доступ к IdP и кладовой секретов
• Тестовые пользователи и тестовая среда
• Инструменты: Postman, браузер, логи

Кратко о вариантах реализации SSO для разных доменов

Если витрины находятся на одном общем домене второго уровня (например shop1.example.com и shop2.example.com), можно использовать cookie на уровне домена .example.com. Но для полностью разных доменов (shop1.ru, shop2.com) такой подход невозможен: браузер не позволяет делиться cookie между разными родительскими доменами.

При разных доменах стандартные варианты — OAuth2/OpenID Connect с централизованным IdP и token-based SSO: авторизация через перенаправление (authorization code) и выдача токенов доступа и refresh-тokens. Для бесшовного опыта применяют механизмы silent auth (prompt=none) в iframe или backchannel token exchange, когда при заходе на новую витрину проходит автоматическая проверка в IdP.

Каждый вариант имеет компромиссы: iframe silent-auth удобен, но требует корректной настройки CORS и SameSite; перенаправления проще реализовать, но видимы пользователю и требуют хорошей UX-обработки; хранение refresh-токенов на сервере повышает безопасность, но усложняет логику.

Рекомендуемая архитектура для витрин на разных доменах

Для большинства коммерческих витрин оптимальна архитектура с централизованным IdP и серверной обработкой refresh-токенов. Схема: пользователь переходит на витрину → если нет локальной сессии, витрина редиректит на IdP → после логина IdP возвращает код → витрина обменивает код на токены и создаёт локальную серверную сессию. Локальная сессия поддерживает cookie только для текущего домена, а долгосрочное состояние хранится в центральном хранилище refresh-токенов у IdP или в общесерверном секретном хранилище.

Чтобы обеспечить бесшовный вход на других доменах, используйте одну из двух стратегий: 1) при заходе на вторую витрину делать silent-redirect на IdP (prompt=none) для автоматического создания новой локальной сессии; 2) применять backchannel token exchange через доверенный сервер, который по безопасному идентификатору создаёт сессию на новой витрине. Оба подхода требуют корректно настроенных redirect-URI и CORS.

Ключевые требования безопасности: использовать Authorization Code Flow с PKCE для SPA и стандартный authorization code для серверных приложений, хранить refresh-токены в безопасном серверном хранилище (не в localStorage), выставлять cookie как HttpOnly, Secure и SameSite=None для корректной работы в кросс-доменных сценариях.

Конфигурация IdP и регистрация клиентов

Зарегистрируйте каждую витрину как отдельный клиент в IdP. Для каждого клиента укажите точные redirect-URI, список доверенных origins и способы выдачи токенов. Включите поддержку refresh-токенов для серверных клиентов и установите корректные тайм-ауты; при необходимости разрешите offline_access scope, но с ограничениями на срок жизни refresh-токена и политики ревока.

Настройте политики CORS на стороне IdP: разрешите origins тех доменов, с которых будут выполняться silent-запросы, и проверьте поддержку заголовков Authorization и cookie. Если используете внешние провайдеры (Auth0, Okta), проверьте ограничения по iframe и prompt=none — некоторые сервисы блокируют silent-авторизацию по настройкам приложения.

Проверьте настройки безопасности: включите HTTPS на всех endpoints, активируйте rate limiting и логирование попыток аутентификации. Убедитесь, что IdP поддерживает механизмы отзыва refresh-токенов и ведёт аудит действий (логин/логаут/обмен токенов) — это пригодится при расследовании инцидентов.

• Зарегистрировать каждый клиент в IdP
• Указать точные redirect-URI
• Разрешить нужные CORS-origin
• Включить refresh-токены для серверных клиентов
• Настроить логирование и ревокацию токенов

Как реализовать обмен токенов и сохранить сессию на витрине

При реализации авторизации на витрине используйте server-side flow: после получения authorization code сервер витрины обменивает его на access и refresh токены у IdP. Access-токен можно хранить в памяти сервера или в кратковременном session-хранилище; локальную cookie создавайте как HttpOnly и Secure, она содержит идентификатор серверной сессии, а не сам токен доступа.

Для сохранения сессии при переходе между доменами реализуйте автоматический silent-relogin: при заходе на вторую витрину выполняется неголосовый запрос на ваш центральный endpoint проверки сессии у IdP. Если IdP подтверждает активную сессию (prompt=none), вторая витрина инициирует обмен кода и создаёт собственную локальную сессию. Вариант с backchannel token exchange удобен для региональных витрин: доверенный сервер по API создаёт сессию на целевой витрине.

Не храните refresh-токены в клиентской части (localStorage). Либо храните их в защищённом серверном хранилище, либо используйте механизмы rotating refresh tokens, когда каждый refresh выдаёт новый и старый помечается как отозванный. Это минимизирует риск перехвата и упрощает принудительный logout пользователя на всех витринах.

Пошаговая настройка: от конфигурации до кода

1) Зарегистрируйте все витрины в IdP как отдельных клиентов с корректными redirect-URI и разрешёнными origins. 2) Настройте политики выдачи токенов: authorization code с PKCE для SPA, authorization code для серверных приложений, разрешите refresh-токены только для доверенных клиентов. 3) Подготовьте SSL и DNS для всех доменов.

4) Реализуйте на витринах логику входа: при отсутствии локальной сессии выполняйте redirect на IdP. 5) После возвращения authorization code обменивайте код на токены на сервере витрины, создавайте локальную сессию и ставьте HttpOnly Secure cookie с идентификатором сессии. 6) Для бесшовного входа на других витринах реализуйте silent-check: при заходе на новую витрину делайте запрос на IdP с prompt=none и, при успешном результате, инициируйте обмен кода для создания локальной сессии.

7) Настройте endpoint logout, который вызывает как локальную инвалидацию сессии, так и single logout (SLO) в IdP, если это поддерживается. 8) Внедрите мониторинг и логирование токенов и ошибок авторизации. 9) Тестируйте сценарии: первая авторизация, повторный вход на другом домене, истечение токенов, форсированный logout.

• 1–3: регистрация клиентов, SSL, DNS
• 4–6: реализация flows на витринах
• 7–9: logout, мониторинг, тестирование

Контрольные точки перед тестированием

Проверьте корректность всех redirect-URI и соответствие их в настройках IdP и в коде витрин — небольшая опечатка блокирует обмен кодов. Убедитесь, что в IdP для каждого клиента указаны точные origins для CORS и что включены протоколы HTTPS на всех endpoints. Сертификаты и цепочки доверия должны быть корректными, иначе браузеры и IdP будут блокировать запросы.

Проверьте cookie-флаги: HttpOnly, Secure и SameSite=None для тех случаев, когда cookie используется в кросс-доменных сценариях. Если вы используете iframe для silent-auth, проверьте, разрешены ли фреймы у IdP (X-Frame-Options) и не блокируется ли запрос политиками Content Security Policy. Также проверьте логи IdP на предмет успешных/отказанных обменов токенов.

Дополнительно убедитесь в наличии механизма ревокации refresh-токенов, настройках TTL для access/refresh токенов и политике rotation. Без механизмов отзыва вы не сможете быстро закрыть доступ при компрометации ключей или сессий.

• Корректность redirect-URI в IdP
• Настройки CORS и HTTPS
• Cookie-флаги: HttpOnly, Secure, SameSite=None
• Разрешения для iframe и CSP
• Механизмы ревокации и rotation refresh-токенов

Сценарии тестирования и отладка

Проведите тесты по ключевым сценариям: 1) новый пользователь входит через витрину A; 2) пользователь, имеющий активную сессию на витрине A, заходит на витрину B и автоматически получает сессию без ручного ввода логина; 3) истечение access-токена и корректное получение новых токенов через refresh; 4) принудительный logout из всех витрин. Для каждого сценария фиксируйте HTTP-запросы и ответы, коды ошибок и содержимое токенов (без разглашения секретов).

Используйте инструменты: браузерные DevTools для проверки cookie, заголовков и редиректов; Postman или curl для проверки обмена кодов и получения токенов; логирование на сервере для отслеживания ошибок обмена. При отладке смотрите на заголовки Set-Cookie, Location в редиректах и ответы от IdP (ошибки invalid_grant, invalid_client, access_denied).

Особое внимание уделите кросс-доменным кейсам: silent-auth в iframe может блокироваться браузером из-за настроек SameSite или X-Frame-Options. Если silent-flow не работает, временно переключитесь на явные редиректы с UX-индикатором для пользователя и исправьте политики по шагам.

Запуск и что проверить после релиза

Запускайте систему поэтапно: сначала тестовая группа пользователей или staging-окружение, затем постепенный переход на реальных пользователей. Во время запуска отслеживайте логи аутентификации и метрики отказов: увеличивающийся процент ошибок при обмене кодов или проблем с CORS укажет на проблемы конфигурации. Держите план отката: возможность быстро вернуть прежнюю схему входа, если критические ошибки затронут пользователей.

После релиза мониторьте поведение сессий: время жизни сессий, частоту обновления токенов, количество неудачных silent-auth попыток и случаи несинхронного logout. Настройте alertы на критичные события: повторные ошибки обмена токенов, несанкционированные попытки доступа, частые ревоки refresh-токенов.

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

Частые вопросы