Дефрагментация междоменных входов в систему

Eiji Kitamura

Современные бизнес-архитектуры часто охватывают несколько различных областей. Организации поддерживают выделенные среды для различных функций — например, brand.example для маркетинга, service-app.example для основного продукта и support-portal.example для обслуживания клиентов. В идеале необходимо обеспечить единый интерфейс авторизации для пользователей при переходе между этими ресурсами. Однако инженерные команды часто интегрируют эти области, используя несистематизированные методы, что приводит к фрагментации. Это нарушает встроенное управление учетными данными браузера, разрушая процессы автозаполнения менеджеров паролей и замедляя внедрение паролей.

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

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

Распространенные обходные пути

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

Запросы на получение данных через CORS

Когда домены работают независимо, интерфейсы часто полагаются на междоменные запросы fetch() , направленные на централизованный API аутентификации, которые можно безопасно разрешить с помощью протокола CORS (Cross-Origin Resource Sharing) . Поскольку браузеры часто блокируют или ограничивают межсайтовые файлы cookie, разработчики могут явно настроить эти API так, чтобы они возвращали токены аутентификации, такие как JSON Web Tokens (JWT), в составе JSON-данных, а не полагались на заголовки Set-Cookie .

Совместное использование базы данных учетных записей

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

Проблемы с разрозненными входами в систему.

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

фрагментация менеджера паролей

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

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

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

Фишинговый шлюз

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

Блокпост с ключом доступа

При использовании паролей возникают дополнительные сложности. Основная архитектура безопасности WebAuthn криптографически привязывает пароли строго к указанному идентификатору проверяющей стороны (RP ID) .

Это создает «ловушку RP ID». Пароль, зарегистрированный на brand.example , неприменим на service-app.example поскольку браузер запрещает доступ между доменами. Чтобы избежать необходимости запрашивать у пользователей регистрацию отдельных паролей для каждого сайта, необходимо объединить эти свойства в один RP ID.

Рекомендуемые подходы

Для обеспечения непрерывности идентификации необходимо отказаться от несистематизированных интеграций для входа в систему и принять общепризнанные архитектурные стандарты:

• Используйте файлы конфигурации метаданных : размещайте файлы метаданных, такие как ссылки на цифровые активы и запросы на подтверждение происхождения, для создания криптографической цепочки доверия. Это обеспечивает беспрепятственный обмен учетными данными и ключами доступа между различными доменами и мобильными приложениями. Такой подход представляет собой недорогое и незаметное решение проблемы фрагментации идентификационных данных, не требующее сложной перестройки существующей веб-инфраструктуры.
• Используйте iframe-элементы, работающие с разными источниками : встройте централизованный источник аутентификации в виде iframe-элемента в зависимую сторону, чтобы связать сохраненные учетные данные и ключи доступа между различными сайтами. Этот подход использует политику разрешений и разделенные файлы cookie для обеспечения бесперебойного входа в систему в контексте, сохраняя при этом строгие границы безопасности за счет политики конфиденциальности и обмена сообщениями между документами.
• Следуйте стандартной федерации идентификации : используйте стандартные отраслевые протоколы, такие как OpenID Connect, для централизации аутентификации в выделенном домене поставщика идентификационных данных (IdP). Это формализует процесс входа в систему с помощью безопасных перенаправлений, заменяя ненадежные интеграции надежным и масштабируемым решением на основе собственных данных.
• Объединение поддоменов : переход к поддоменам под общим корневым доменом. Это обеспечивает бесперебойное совместное использование сессий с помощью файлов cookie с подстановочными знаками и непрерывность ключей доступа на всем регистрируемом домене. Многие менеджеры паролей могут распознавать общий корневой домен и автоматически предлагать сохраненные учетные данные для связанных поддоменов.

Используйте файлы конфигурации метаданных.

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

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

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

• Менеджер паролей Google на Android и Chrome : разместите JSON-файл цифровых ссылок на активы (DAL) по адресу /.well-known/assetlinks.json , чтобы установить проверяемые доверительные отношения между связанными приложениями и веб-сайтами организации. Это доверие позволяет создавать глубокие ссылки в приложениях и обеспечивает бесшовное совместное использование учетных данных , когда пароли, сохраненные в интернете, автоматически заполняют связанные веб-сайты (хотя совместное использование ключей доступа в нескольких веб-доменах по-прежнему требует запросов на определение связанного источника ). Подробнее см. в руководстве по бесшовному совместному использованию учетных данных .

• Пароли Apple на iOS и Safari : Разместите файл Apple App Site Association (AASA) по адресу /.well-known/apple-app-site-association , чтобы установить криптографическую цепочку доверия, необходимую для связи состояний паролей Apple между приложениями iOS и Safari. Для поддержки сторонних экосистем вы можете централизованно объявлять эти связанные домены, используя краудсорсинговый репозиторий . Это гарантирует, что независимые инструменты (такие как 1Password, которые явно используют этот репозиторий) также распознают общий контекст идентификации. Чтобы узнать больше об Apple App Site Association, прочитайте раздел «Поддержка связанных доменов» .

Чтобы разрешить использование паролей на разных веб-доменах и устранить проблему с паролями, разработчики могут разместить файл Related Origin Requests (ROR) по адресу /.well-known/webauthn . В файле ROR явно указываются авторизованные домены, которым разрешено безопасно использовать один и тот же идентификатор RP-ключа. Подробнее о Related Origin Requests можно узнать в статье «Разрешите повторное использование паролей на ваших сайтах с помощью Related Origin Requests» .

• Плюсы:
  • Фоновое исправление для конечных пользователей: оно работает полностью в фоновом режиме, автоматически устраняя фрагментацию автозаполнения и обеспечивая непрерывность ввода пароля на уровне операционной системы или браузера без каких-либо видимых изменений в пользовательском интерфейсе.
  • Простая реализация: это недорогое решение, требующее лишь размещения статических JSON-файлов. Оно не требует перепроектирования бэкэнда или сложной логики обмена токенами.
  • Сохраняет существующую инфраструктуру: вы можете значительно улучшить взаимодействие между доменами, не меняя свой бренд и не объединяя домены.
• Минусы:
  • Ограничения платформы: Платформы обычно устанавливают строгие ограничения на ROR (Rewards Rewards). Например, Chrome ограничивает количество связанных меток eTLD+1 для одного RP ID максимум пятью. Для иллюстрации: example.co.uk и example.de используют одну и ту же метку example eTLD+1; однако example-rewards.com использует отдельную метку example-rewards . Если вы управляете обширным или разнообразным портфелем доменов, этих ограничений может быть недостаточно.
  • Увеличение задержки при выполнении операций: для разрешения файлов метаданных требуется дополнительный сетевой запрос, что приводит к задержке при обработке аутентификации браузером.

Используйте iframe, работающие с другими источниками.

Если из-за ограничений домена ROR вы не можете использовать подход с файлами конфигурации метаданных, элементы iframe работающие с другими источниками, предлагают надежный, поддерживаемый стандартами способ решения проблем входа в систему между доменами.

Встраивая централизованный источник аутентификации (например, auth.brand.example ) в виде iframe внутри зависимой стороны (например, brand.example ), вы можете взаимодействовать как с обычными полями форм, так и с современными API. Для паролей менеджер учетных данных браузера связывает действия автозаполнения с источником iframe ( auth.example ). Это позволяет пользователям беспрепятственно получать доступ к своим централизованным учетным данным на разных сайтах.

Для паролей родительское окно должно предоставить iframe доступ, используя структуру политики разрешений (Permissions Policy ), что позволит iframe вызвать WebAuthn для аутентификации по идентификатору RP своего собственного источника. В обоих случаях политика безопасности контента (CSP) полезна для защиты пользователей от таких атак, как кликджекинг и межсайтовый скриптинг. После успешной аутентификации устанавливается сессия с использованием разделенного cookie , и токен безопасно передается обратно в родительское окно с помощью postMessage() .

• Плюсы:
  • Централизованное управление учетными данными: позволяет избежать фрагментации учетных данных. Единый централизованный источник управляет как сохраненными паролями, так и единым идентификатором точки доступа (RP ID), что позволяет различным доменам совместно использовать эти учетные данные без необходимости их объединения.
  • Контекстная аутентификация: весь процесс входа в систему — будь то автоматическое заполнение пароля или проверка с помощью ключа доступа — происходит плавно и контекстно на родительской странице, избегая нарушающих работу федеративных перенаправлений.
  • Устойчивость к средствам защиты от отслеживания: Этот подход корректно работает даже при строгой защите от отслеживания между сайтами с использованием разделенных файлов cookie .
• Минусы:
  • Ограничения реализации: Данная архитектура требует специализированных инженерных решений. Она требует строгого соблюдения CSP ( frame-ancestors ) для ограничения встраивания только доверенными родительскими доменами и предотвращения кликджекинга, настройки политик разрешений HTTP для включения API WebAuthn, а также безопасной и проверенной междокументной передачи сообщений ( postMessage() ) для смягчения последствий подмены источника и CSRF-атак. Ознакомьтесь с лучшими практиками использования ключей доступа внутри iframe .

Следуйте стандартной федерации идентификации.

Внедрение стандартной федерации идентификации, такой как OpenID Connect, — это надежный и устойчивый подход к поддержке вашей системы учетных записей. Этот подход формализует процесс аутентификации, объединяя его в одном выделенном домене поставщика идентификации (IdP), например, auth.brand.example . При наличии установленного протокола приложения перенаправляют пользователей в этот центральный узел для аутентификации, после чего безопасно получают токен для завершения входа в систему на целевом домене. Хотя стандартная федерация часто ассоциируется с авторизацией через сторонние сервисы (например, Sign-in with Google ), она вполне допустима и широко используется в качестве собственного решения для замены ненадежных обходных путей.

• Плюсы:
  • Единый инженерный язык: разработчикам не нужно изучать или поддерживать конкретный, специально разработанный протокол; они могут полагаться на устоявшиеся отраслевые знания и обширные библиотеки. Существуют также готовые решения.
  • Проверенная в боевых условиях надежность: стандартные протоколы доказали свою эффективность, безопасны и гораздо менее уязвимы, чем импровизированные реализации.
  • Легко масштабируемая: если организации потребуется интегрироваться с новым сторонним сервисом или в дальнейшем интегрировать приобретенную компанию, инфраструктура идентификации уже будет оснащена для предоставления учетных данных.
  • Единый пользовательский интерфейс: Пользователи воспринимают централизованную страницу поставщика идентификации как авторитетный источник информации о бренде, где точно указано, когда и где требуются учетные данные.
• Минусы:
  • Высокие затраты на интеграцию: разработка или миграция на централизованный поставщик идентификации (IdP) влечет за собой высокие затраты на интеграцию и требует специальных знаний в области безопасности. Организациям необходимо инвестировать в безопасную рефакторизацию всех подключенных приложений для поддержки безопасных схем на основе перенаправлений.
  • Нарушающие работу системы перенаправления: Процесс аутентификации требует перенаправления пользователей с исходного сайта на централизованную страницу поставщика идентификационных данных, что препятствует беспрепятственному входу в систему в контексте.

Объединить поддомены

Другой структурный подход заключается в объединении всех доменов путем переноса разрозненных цифровых ресурсов под общий регистрируемый корневой домен (eTLD+1) . Это предполагает преобразование отдельных доменов, таких как brand.example и service-app.example в поддомены, такие как www.brand.example и service.brand.example .

• Плюсы:
  • Единое управление учетными данными: менеджеры паролей могут распознавать корневой домен и рассматривать все поддомены как единую запись, исключая дублирование запросов и ручной ввод паролей.
  • Сохранение работоспособности пароля: разработчики могут изначально ограничить область действия идентификатора RP пароля только регистрируемым доменом, мгновенно распространяя поддержку пароля на все связанные поддомены. В этом случае идентификатор RP brand.example будет работать как на www.brand.example , так и на service.brand.example .
  • Простое совместное использование сессий: объединение доменной структуры позволяет совместно использовать одну сессию с помощью файлов cookie с подстановочными знаками (например, привязав файл cookie к Domain=brand.example ).
• Минусы:
  • Ограничения, связанные с брендингом и миграцией: Этот подход может наложить потенциальные ограничения на использование брендинга, если ваша организация требует наличия отдельных доменов верхнего уровня. Миграция сложна и требует тщательного управления HTTP-перенаправлениями и масштабной доработки устаревших междоменных конфигураций.

Заключение

Для обеспечения непрерывности идентификации необходимо перейти от несистематизированных интеграций для входа в систему к устоявшимся стандартам аутентификации. Оценивая бизнес-ограничения в сравнении с этими устоявшимися практиками — такими как федерация, консолидация доменов, iframe или метаданные — вы можете устранить неудобства пользовательского интерфейса и улучшить аутентификацию во всей вашей экосистеме.

Чтобы узнать больше по смежным темам, следите за нашим блогом и изучайте дополнительные ресурсы на портале идентификации Chrome .