Связанные источники WebAuthn: руководство по междоменным Passkeys

Passkeys — это новый стандарт безопасной и удобной для пользователя аутентификации. Основанные на стандартах FIDO/WebAuthn, они используют криптографию с открытым ключом, чтобы обеспечить встроенную защиту от фишинга и атак с подстановкой учетных данных. Это значительно повышает уровень безопасности и упрощает процесс входа для пользователей. Для организаций это означает ощутимые бизнес-преимущества: снижение операционных расходов на сброс паролей и SMS OTP, уменьшение финансовых рисков от захвата аккаунтов и рост выручки за счет более высоких показателей конверсии.

Однако одна из главных сильных сторон WebAuthn в плане безопасности — строгая привязка к источнику (origin) — создает серьезную проблему для глобальных брендов и компаний с разнообразным цифровым присутствием. По своей сути, Passkey, созданный для определенного веб-домена, криптографически привязан к этому домену. Это фундаментальный принцип, предотвращающий фишинговые атаки. Хотя это мощная функция безопасности, она приводит к фрагментированному и запутанному пользовательскому опыту, когда один бренд работает на нескольких доменах.

Ярким примером этой проблемы является ребрендинг Twitter в X. Пользователь, создавший Passkey на twitter.com, не смог бы использовать его на x.com. Это вынудило компанию внедрять громоздкие перенаправления или требовать от пользователей повторной регистрации, что создает неудобства и мешает внедрению технологии. И это не единичный случай. Крупные компании, такие как Amazon, работают на множестве национальных доменов верхнего уровня (ccTLD), например amazon.com, amazon.de и amazon.co.uk, при этом используя общую систему учетных записей. В мире до Passkeys менеджеры паролей легко справлялись с этой сложностью, но стандартное поведение WebAuthn потребовало бы отдельного Passkey для каждого домена, что расстраивало бы пользователей и подрывало идею бесшовного входа.

Чтобы решить эту критическую проблему, W3C представил новую функцию в стандарте WebAuthn: Запросы связанных источников (Related Origin Requests, ROR). Этот мощный механизм предоставляет стандартизированный и безопасный способ для группы доверенных доменов использовать один и тот же Passkey, создавая единый и бесшовный опыт аутентификации во всей цифровой экосистеме бренда. В этой статье мы подробно рассмотрим технические основы ROR, предоставим практическое руководство по его внедрению и проанализируем его стратегическое значение для современной архитектуры аутентификации.

Появление ROR знаменует собой важный этап в развитии стандарта WebAuthn. В первоначальных спецификациях основной упор делался на ключевые криптографические принципы и принципы безопасности, где строгая привязка учетных данных к идентификатору проверяющей стороны (rpID) была краеугольным камнем защиты от фишинга. По мере того как крупномасштабные корпоративные внедрения компаниями вроде Amazon и Google стали реальностью, практические неудобства, вызванные этой жесткостью, стали очевидны. Эти неудобства напрямую препятствуют широкому принятию пользователями, что является главным мерилом успеха любого проекта с Passkeys. Разработка ROR — это прямой ответ на отзывы корпоративных пользователей, демонстрирующий прагматичную эволюцию стандарта. Он признает, что для широкого успеха протокола безопасности его удобство использования должно масштабироваться, чтобы соответствовать сложным бизнес-реалиям и брендинговым стратегиям организаций, которые его внедряют.

Это подробное руководство отвечает на пять ключевых вопросов по внедрению запросов связанных источников WebAuthn:

1. Почему Passkeys не работают на нескольких доменах? Разбираемся в модели безопасности WebAuthn, привязанной к источнику, и ее практических недостатках.
2. Как технически работают запросы связанных источников? Глубокое погружение в процесс проверки браузером и механизм URI .well-known.
3. Что нужно для внедрения ROR? Пошаговая настройка на стороне сервера и клиента с практическими примерами кода.
4. Когда выбирать ROR, а когда — федеративный вход? Стратегическая основа для принятия решений, сравнивающая ROR с подходами OIDC/SAML.
5. Как обеспечить совместимость с браузерами и учесть соображения безопасности? Текущая матрица поддержки и лучшие практики безопасности.

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

Чтобы в полной мере оценить изящество решения на основе запросов связанных источников, необходимо сначала понять основополагающие технические концепции, которые делают его необходимым: политику одного источника в вебе и правила определения области действия идентификатора проверяющей стороны (rpID) в WebAuthn. Эти механизмы лежат в основе веб-безопасности, но именно они создают те неудобства, которые призваны устранить ROR.

«Источник» (origin) в вебе — это критически важное понятие безопасности, определяемое уникальной комбинацией протокола (например, https), домена (например, app.example.com) и порта (например, 443), с которого доставляется контент. Политика одного источника (Same-Origin Policy) — это механизм безопасности, применяемый браузерами, который ограничивает взаимодействие скрипта, загруженного с одного источника, с ресурсом с другого источника. Это важный элемент веб-безопасности, который эффективно изолирует потенциально вредоносные документы и предотвращает, например, чтение конфиденциальных данных из аутентифицированной сессии веб-почты пользователя в другой вкладке мошенническим сайтом.

В экосистеме WebAuthn «проверяющая сторона» (Relying Party, RP) — это веб-сайт или приложение, в котором пользователь пытается пройти аутентификацию. Каждый Passkey в момент создания криптографически привязывается к идентификатору проверяющей стороны (rpID). rpID — это доменное имя, которое определяет область действия и границы для этих учетных данных.

По умолчанию rpID — это действующий домен источника, на котором создается Passkey. Правила WebAuthn позволяют источнику устанавливать rpID, который либо равен его собственному домену, либо является регистрируемым суффиксом домена. Например, скрипт, работающий на https://www.accounts.example.co.uk, может создать Passkey с rpID:

• www.accounts.example.co.uk (полный домен)
• accounts.example.co.uk
• example.co.uk

Эта гибкость позволяет использовать Passkey, созданный на одном поддомене, на других поддоменах того же родительского домена, что является распространенной и необходимой практикой. Однако правила строго запрещают устанавливать rpID, который не является суффиксом. Тот же скрипт на www.accounts.example.co.uk не смог бы создать Passkey с rpID example.com, потому что .com — это другой домен верхнего уровня.

Эта строгая привязка служит важной цели: разделению учетных данных по областям доменов. Passkey, созданный для mybank.com, не может быть использован на phishing-site.com, потому что вредоносный сайт не может заявить легитимный rpID mybank.com. Браузер даже не предложит такой Passkey в качестве варианта.

Однако сам по себе rpID не является основным средством защиты от фишинга. Защита от фишинга в WebAuthn на самом деле обеспечивается проверкой источника (origin verification) в объекте clientDataJSON. Во время каждой церемонии WebAuthn браузер создает JSON-объект, содержащий критически важный контекст, включая точный источник, инициировавший запрос. Затем весь этот объект криптографически подписывается закрытым ключом аутентификатора. Сервер (проверяющая сторона) ОБЯЗАН проверить эту подпись и, что крайне важно, убедиться, что поле origin в подписанном clientDataJSON соответствует ожидаемому, доверенному значению. Именно эта проверка источника предотвращает фишинговые атаки.

С появлением запросов связанных источников область действия rpID становится менее строгой — позволяя bar.com легитимно заявлять rpID foo.com после того, как браузер проверит файл .well-known/webauthn, — но требование проверки источника остается неизменным. clientDataJSON по-прежнему будет правдиво сообщать, что источник — bar.com. Сервер foo.com получает эти подписанные данные, проверяет их и видит, что запрос пришел от bar.com. Затем сервер должен убедиться, что bar.com является ожидаемым связанным источником, прежде чем принять аутентификацию. Это демонстрирует многоуровневый подход, который обеспечивает большую гибкость без ущерба для основного принципа проверки источника.

Механизм запросов связанных источников представляет собой изящный и стандартизированный способ для доменов публично заявлять о доверительных отношениях с целью совместного использования Passkeys. Он использует хорошо зарекомендовавший себя веб-паттерн — URI /.well-known/ — для создания проверяемого и машиночитаемого «белого списка», который могут использовать браузеры.

Основная концепция проста: домен, который служит основным, каноническим rpID для набора связанных сайтов, может размещать специальный JSON-файл по стандартизированному, «хорошо известному» URL: https://{rpID}/.well-known/webauthn. Этот файл действует как публичный манифест, явно перечисляя все другие источники, которые официально уполномочены создавать и использовать Passkeys под этим основным rpID.

Процесс проверки в браузере запускается всякий раз, когда он обнаруживает несоответствие между текущим источником и запрошенным rpID:

1. Пользователь на «связанном» сайте, например https://example.co.uk, инициирует операцию с Passkey (создание или аутентификацию), где клиентский код указывает другой домен в качестве rpID, например, example.com.
2. Браузер обнаруживает это несоответствие. По старым правилам это немедленно привело бы к ошибке SecurityError.
3. При поддержке ROR браузер, прежде чем выдать ошибку, выполняет безопасный HTTPS GET-запрос к well-known URL заявленного rpID: https://example.com/.well-known/webauthn. Этот запрос выполняется без учетных данных пользователя (таких как cookie) и без заголовка Referrer для защиты конфиденциальности пользователя и предотвращения отслеживания.
4. Браузер получает JSON-ответ от сервера. Он анализирует файл и проверяет, присутствует ли текущий источник (https://example.co.uk) в массиве origins внутри JSON-объекта.
5. Если источник найден в белом списке, операция WebAuthn может продолжаться с использованием example.com в качестве действительного rpID. Если источник не найден, или если файл отсутствует или имеет неверный формат, операция завершается неудачей, как и раньше.

Выбор URI /.well-known/ не случаен и соответствует устоявшимся веб-стандартам для обнаружения служб и проверки контроля над доменом. Этот путь URI, определенный в RFC 8615, уже используется множеством критически важных протоколов, включая acme-challenge для выдачи SSL-сертификатов Let's Encrypt и assetlinks.json для связывания веб-сайтов с приложениями Android. Применяя это соглашение, W3C использует паттерн, который по своей сути подразумевает владение доменом. Чтобы разместить файл по этому конкретному, стандартизированному пути, необходимо иметь административный контроль над веб-сервером для этого домена. Это обеспечивает простое, но эффективное доказательство контроля, делая заявление о доверии проверяемым. Когда владелец example.com размещает файл, в котором example.co.uk указан как связанный источник, это является проверяемым утверждением. Этот нативный веб-подход гораздо проще и надежнее, чем альтернативы, которые рассматривались и были отклонены в процессе стандартизации, такие как использование криптографических ключей для подписи авторизаций (RP Keys) или случайных идентификаторов, не основанных на доменах (RP UUIDs). ROR основывает доверительные отношения на существующей, хорошо понятной модели контроля доменов в вебе.

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

Сервер, на котором размещен основной rpID, отвечает за публикацию белого списка связанных источников.

Файл авторизации должен быть размещен по точному пути /.well-known/webauthn относительно корня домена основного rpID. Крайне важно, чтобы этот файл отдавался при следующих условиях:

• Протокол: Он должен отдаваться по HTTPS.
• Content-Type: HTTP-заголовок ответа Content-Type должен быть установлен в application/json.
• Расширение файла: URL не должен содержать расширение .json. Правильный путь — /webauthn, а не /webauthn.json.

Файл должен содержать один JSON-объект с одним ключом origins, значением которого является массив строк. Каждая строка в массиве — это полный источник (протокол, домен и необязательный порт), который авторизуется.

{
    "origins": ["https://example.co.uk", "https://example.de", "https://example.fr"]
}

Пример: Для rpID example.com файл должен быть доступен по адресу https://example.com/.well-known/webauthn (обратите внимание: без расширения .json).

После того как сервер настроен с файлом .well-known/webauthn, все связанные домены должны последовательно использовать один и тот же общий rpID в своих вызовах WebAuthn API. Эта координация критически важна для правильной работы ROR.

Ключевые требования к координации:

1. Ответственность бэкенда: Сервер генерирует криптографический вызов (challenge) и указывает общий rpID как в запросах на создание учетных данных, так и в запросах на аутентификацию.
2. Ответственность фронтенда: Все клиентские приложения (example.com, example.co.uk, example.de) должны передавать один и тот же общий rpID в API браузера navigator.credentials.
3. Управление конфигурацией: Общий rpID должен рассматриваться как критически важное глобальное значение конфигурации, применяемое последовательно на всех связанных сайтах.

Неправильная конфигурация даже на одном сайте — когда он по умолчанию использует свой собственный источник в качестве rpID вместо общего значения — нарушит единый опыт использования Passkeys для пользователей на этом домене.

Важно: Сервер ОБЯЗАН проверять поле origin в clientDataJSON для каждого запроса, убеждаясь, что оно соответствует одному из авторизованных связанных источников. Эта проверка источника является основным механизмом защиты от фишинга.

Запросы связанных источников (ROR) и протоколы федеративной идентификации (OIDC/SAML) решают разные проблемы. ROR не является заменой единого входа (Single Sign-On) — это дополнение, которое решает конкретный, узкий сценарий использования.

ROR подходит для одного логического приложения, распределенного по нескольким связанным доменам, которые используют одну и ту же базу данных пользователей:

• Один бренд, работающий на нескольких национальных доменах верхнего уровня (например, amazon.com, amazon.de, amazon.co.uk)
• Все домены используют одну и ту же бэкенд-систему аутентификации и базу данных пользователей
• Вы хотите избежать потоков на основе перенаправлений и сохранить контекст аутентификации для каждого домена
• Ваши домены укладываются в ограничение из 5 меток (labels)
• Пользователи должны воспринимать все домены как единый целостный сервис

Что предоставляет ROR: Один и тот же Passkey работает на всех связанных доменах, избавляя пользователей от необходимости создавать отдельные Passkeys для каждого регионального сайта.

Используйте протоколы федеративной идентификации для настоящего единого входа (SSO) между различными приложениями:

• Несколько сервисов с отдельными базами данных пользователей или системами идентификации
• Корпоративные сценарии, где пользователям нужен доступ ко многим различным приложениям (Salesforce, Office 365, внутренние инструменты)
• Интеграция со сторонними приложениями
• Вам нужен централизованный контроль доступа, журналы аудита и управление идентификационными данными
• Вы превышаете ограничение в 5 меток для связанных источников

Что предоставляют OIDC/SAML: Централизованную аутентификацию, при которой пользователи входят один раз у поставщика удостоверений (Identity Provider) (IdP) и получают доступ к нескольким поставщикам услуг (Service Providers, SP) через защищенные токены.

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

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

Ключевым ограничением ROR является «лимит меток». «Метка» (label) в этом контексте относится к эффективному домену верхнего уровня плюс один уровень (eTLD+1), то есть к регистрируемой части доменного имени. Например:

• shopping.com, shopping.co.uk и shopping.ca все используют одну метку «shopping»
• myshoppingrewards.com вводит новую, отличную метку: «myshoppingrewards»
• travel.shopping.com по-прежнему относится к метке «shopping»

Спецификация WebAuthn Level 3 требует, чтобы реализации в браузерах поддерживали минимум пять уникальных меток в списке origins. По состоянию на 2025 год ни один из известных браузеров не поддерживает больше этого минимума в пять меток. Поэтому организациям следует проектировать свои развертывания ROR с учетом этого жесткого ограничения — рассматривайте пять как фактический максимум.

Это ограничение является преднамеренным механизмом защиты от злоупотреблений. Оно не позволяет таким сущностям, как провайдеры общего хостинга (например, wordpress.com), создавать универсальный Passkey, который мог бы работать на тысячах несвязанных поддоменов клиентов, что подорвало бы модель безопасности.

Для большинства организаций, даже для крупных международных брендов, этого лимита в пять меток достаточно. Например, различные национальные домены Amazon (amazon.com, amazon.de, amazon.co.uk и т.д.) все используют метку «amazon», оставляя четыре дополнительных слота для других брендов в их портфолио, таких как «audible» или «zappos».

Сложность внедрения ROR сильно зависит от того, вводится ли он в новую систему или дорабатывается в существующей.

• Новые проекты (Greenfield): Для новых проектов стратегия проста. С самого начала следует выбрать единый, канонический домен в качестве общего rpID (например, основной домен .com). Этот rpID затем должен последовательно использоваться в конфигурации всех связанных веб-сайтов и приложений с первого дня.
• Существующие системы: Доработка ROR в системе, где уже развернуты Passkeys с разными rpID на разных доменах, значительно сложнее. Прямая миграция невозможна, так как существующие Passkeys навсегда привязаны к своим первоначальным rpID. Рекомендуемый подход в этом сценарии — внедрение процесса входа с предварительным вводом идентификатора («identifier-first»). Сначала пользователю предлагается ввести свое имя пользователя или email. Затем бэкенд выполняет поиск, чтобы определить, с каким rpID связан его существующий Passkey. Наконец, пользователь перенаправляется на правильный источник, соответствующий этому rpID, для завершения церемонии аутентификации. После успешного входа его можно перенаправить обратно на исходный сайт. Это значительная архитектурная задача, требующая тщательного планирования и реализации.

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

Microsoft использует ROR для своей инфраструктуры аутентификации. Фактическая конфигурация на login.microsoftonline.com включает:

// https://login.microsoftonline.com/.well-known/webauthn
{
    "origins": ["https://login.microsoftonline.com", "https://login.live.com"]
}

Этот консервативный подход позволяет совместно использовать Passkeys между корпоративным и потребительским порталами входа Microsoft, сохраняя при этом сфокусированный периметр безопасности.

Shopify внедряет ROR для объединения аутентификации на избранных доменах:

// https://shopify.com/.well-known/webauthn
{
    "origins": ["https://shopify.com", "https://shop.app"]
}

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

У Amazon довольно большой файл:

// https://amazon.com/.well-known/webauthn
{
    "origins": [
        "https://www.amazon.com",
        "https://www.amazon.com.br",
        "https://www.amazon.com.mx",
        "https://www.amazon.ca",
        "https://www.amazon.co.uk",
        "https://www.amazon.de",
        "https://www.amazon.it",
        "https://www.amazon.es",
        "https://www.amazon.nl",
        "https://www.amazon.se",
        "https://www.amazon.sa",
        "https://www.amazon.pl",
        "https://www.amazon.com.tr",
        "https://www.amazon.fr",
        "https://www.amazon.com.au",
        "https://www.amazon.sg",
        "https://www.amazon.ae",
        "https://www.amazon.eg",
        "https://www.amazon.co.za",
        "https://www.amazon.in",
        "https://brandregistry.amazon.com",
        "https://sellercentral.amazon.com",
        "https://sellercentral.amazon.com.br",
        "https://sellercentral.amazon.com.mx",
        "https://sellercentral.amazon.ca",
        "https://sellercentral.amazon.co.uk",
        "https://sellercentral.amazon.de",
        "https://sellercentral.amazon.it",
        "https://sellercentral.amazon.es",
        "https://sellercentral.amazon.nl",
        "https://sellercentral.amazon.se",
        "https://sellercentral.amazon.sa",
        "https://sellercentral.amazon.pl",
        "https://sellercentral.amazon.com.tr",
        "https://sellercentral.amazon.fr",
        "https://sellercentral.amazon.com.au",
        "https://sellercentral.amazon.sg",
        "https://sellercentral.amazon.ae",
        "https://sellercentral.amazon.eg",
        "https://sellercentral.amazon.co.za",
        "https://sellercentral.amazon.in",
        "https://na.account.amazon.com",
        "https://vendorcentral.amazon.com",
        "https://vendorcentral.amazon.com.br",
        "https://vendorcentral.amazon.com.mx",
        "https://vendorcentral.amazon.ca",
        "https://vendorcentral.amazon.co.uk",
        "https://vendorcentral.amazon.de",
        "https://vendorcentral.amazon.it",
        "https://vendorcentral.amazon.es",
        "https://vendorcentral.amazon.nl",
        "https://vendorcentral.amazon.se",
        "https://vendorcentral.amazon.pl",
        "https://vendorcentral.amazon.com.tr",
        "https://vendorcentral.amazon.fr",
        "https://vendorcentral.amazon.com.au",
        "https://vendorcentral.amazon.co.za"
    ]
}

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

Эти реальные примеры выявляют несколько ключевых паттернов:

1. Основной домен как rpID: Все компании используют свой основной домен .com в качестве канонического rpID.
2. Логическая группировка: Источники группируются по бизнес-функциям, а не по технической архитектуре.
3. Консервативный охват: Большинство реализаций не выходят за рамки лимита в 5 меток, обычно используя 3-4 источника.
4. Стратегия поддоменов: Многие используют поддомены основного домена для поддержания консистентности бренда.

Как современный веб-стандарт, ROR был разработан с учетом безопасности в качестве основного приоритета и активно внедряется в основных браузерах.

Запросы связанных источников не компрометируют основные гарантии защиты от фишинга в WebAuthn. Механизм тщательно разработан для поддержания высокого уровня безопасности:

• Проверка источника: Как уже обсуждалось, браузер по-прежнему включает истинный источник запроса в подписанный clientDataJSON. Сервер проверяющей стороны ОБЯЗАН проверить этот источник, чтобы убедиться, что запрос исходит из ожидаемого источника, предотвращая возможность того, что скомпрометированный связанный источник сможет выдать себя за другой.
• Безопасная загрузка: Запрос браузера к файлу .well-known/webauthn выполняется по HTTPS. Кроме того, спецификация предписывает, чтобы эта загрузка выполнялась без учетных данных (например, cookie) и без заголовка Referer. Это предотвращает использование запроса для утечки информации о пользователе или для межсайтового отслеживания.
• Безопасность сервера: Сам файл .well-known/webauthn становится критически важным активом безопасности. Злоумышленник, получивший контроль над веб-сервером, на котором размещен основной rpID, потенциально может изменить этот файл, чтобы добавить свой вредоносный домен в белый список. Поэтому обеспечение безопасности инфраструктуры, которая обслуживает этот файл, имеет первостепенное значение.

Запросы связанных источников — это функция спецификации WebAuthn Level 3. Поддержка в браузерах начала появляться в конце 2024 года:

Ключевые факты:

• Chrome и Edge: Добавили поддержку ROR в версии 128 (август 2024 года).
• Safari: Добавил поддержку ROR в Safari 18, доступном на macOS 15 и iOS 18 (сентябрь 2024 года).
• Firefox: В настоящее время поддержка ROR отсутствует; необходимо определять наличие функции и реализовывать запасные сценарии.

Для приложений, которым необходимо поддерживать старые браузеры или Firefox, реализуйте запасную стратегию:

1. Определение поддержки функции: Проверьте поддержку ROR с помощью PublicKeyCredential.getClientCapabilities().
2. Процесс входа с предварительным вводом идентификатора: Запросите имя пользователя/email, найдите связанный с пользователем rpID, а затем перенаправьте на соответствующий источник для аутентификации.
3. Плавная деградация: Разрешите пользователям создавать отдельные Passkeys для каждого домена, если ROR недоступен.

Данные основаны на текущих матрицах поддержки по состоянию на октябрь 2025 года.

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

Corbado берет на себя техническую сложность запросов связанных источников через:

• Автоматическую конфигурацию: Наша платформа автоматически генерирует и размещает необходимые файлы .well-known/webauthn с правильными заголовками безопасности и форматированием JSON.
• Панель управления для нескольких доменов: Централизованный интерфейс управления для настройки связанных источников для всего вашего портфеля доменов.
• Инструменты валидации: Встроенное тестирование и валидация для обеспечения правильной работы вашей конфигурации ROR во всех браузерах и на всех платформах.

Помимо технической реализации, Corbado предоставляет фреймворк безопасности, необходимый предприятиям:

• Проверка источника: Автоматическая валидация источников из clientDataJSON для предотвращения злоупотреблений со связанными доменами.
• Журналирование аудита: Комплексное отслеживание использования Passkeys на всех связанных доменах для мониторинга безопасности и соответствия требованиям.
• Реагирование на инциденты: Оповещения в реальном времени и автоматизированные ответы на подозрительные попытки междоменной аутентификации.

Для организаций с существующими развертываниями Passkeys Corbado предлагает:

• Инструменты миграции устаревших систем: Автоматический анализ существующих конфигураций rpID и рекомендации по путям миграции.
• Процессы входа с предварительным вводом идентификатора: Готовые компоненты входа, которые обрабатывают сложные сценарии с несколькими rpID в переходные периоды.
• Интеграция через API: RESTful API и SDK, которые легко интегрируются с вашей существующей инфраструктурой аутентификации.

Готовы внедрить запросы связанных источников в вашей организации? Команда экспертов Corbado поможет вам спроектировать и развернуть единый опыт использования Passkeys во всей вашей цифровой экосистеме. Свяжитесь с нашей командой по решениям, чтобы обсудить ваши конкретные требования и сроки.

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

Запросы связанных источников WebAuthn (ROR) предоставляют стандартизированное, безопасное и изящное решение этой проблемы. Позволяя одному Passkey бесшовно работать на доверенном наборе связанных доменов, ROR устраняет основную причину путаницы и разочарования пользователей.

Это руководство ответило на пять критически важных вопросов по внедрению запросов связанных источников WebAuthn:

1. Почему Passkeys не работают на нескольких доменах? Модель безопасности WebAuthn, привязанная к источнику, криптографически привязывает Passkeys к конкретным доменам для предотвращения фишинга, но это создает неудобства, когда бренды работают на нескольких доменах, например, с разными национальными TLD.
2. Как технически работают запросы связанных источников? ROR использует стандартизированный файл .well-known/webauthn для создания проверяемого белого списка связанных доменов, позволяя браузерам проверять междоменное использование Passkeys через безопасный процесс HTTPS-запроса.
3. Что требуется для внедрения ROR? Внедрение требует настройки на стороне сервера манифеста .well-known/webauthn и координации на стороне клиента для последовательного использования общего rpID на всех связанных источниках.
4. Когда выбирать ROR, а когда — федеративный вход? Используйте ROR для единого брендового опыта на связанных доменах с общей базой пользователей; используйте OIDC/SAML для настоящего SSO между различными приложениями или при превышении лимита в 5 меток.
5. Как обеспечить совместимость с браузерами и учесть соображения безопасности? ROR поддерживается в основных браузерах, начиная с Chrome/Firefox 128+, Safari на macOS 15+ и iOS 18+, с запасными стратегиями для старых браузеров через процессы входа с предварительным вводом идентификатора.

Для технических команд и руководителей продуктов важны следующие моменты:

• ROR обеспечивает единый опыт использования Passkeys для одного логического приложения, распределенного по нескольким доменам, например, с разными национальными TLD или альтернативным брендингом.
• Внедрение требует скоординированных усилий: на домене основного rpID должен быть опубликован серверный файл .well-known/webauthn, и все клиентские приложения должны быть настроены на использование этого общего rpID.
• Решение об использовании ROR является стратегическим. Это отличный инструмент для конкретных сценариев, но его следует сопоставлять с более традиционной архитектурой федеративного входа (OIDC/SAML), особенно в сценариях, включающих настоящий единый вход (Single Sign-On) между разрозненными приложениями.

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