Разрешите повторное использование пароля на ваших сайтах с помощью запросов связанного происхождения.

Maud Nalpas

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

Это указывается в идентификаторе проверяющей стороны (RP ID), который для ключей доступа, созданных для домена example.com может быть www.example.com или example.com .

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

• Сайты с несколькими доменами : Пользователи не могут использовать один и тот же пароль для входа в систему на разных доменах, принадлежащих одной и той же компании и предназначенных для разных стран (например, example.com и example.co.uk ).
• Фирменные домены : Пользователи не могут использовать одни и те же учетные данные на разных доменах, принадлежащих одному бренду (например, acme.com и acmerewards.com ).
• Мобильные приложения : Мобильные приложения часто не имеют собственного домена, что затрудняет управление учетными данными.

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

Решение

С помощью функции «Запросы от связанных источников» веб-сайт может указать источники, которым разрешено использовать его идентификатор RP.

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

Для использования запросов от связанных источников необходимо предоставить специальный JSON-файл по определенному URL-адресу https://{RP ID}/.well-known/webauthn . Если example.com хочет разрешить дополнительным источникам использовать его в качестве RP ID, он должен предоставить следующий файл по адресу https://example.com/.well-known/webauthn:

{
  "origins": [
    "https://example.co.uk",
    "https://example.de",
    "https://example-rewards.com"
  ]
}

В следующий раз, когда любой из этих сайтов запросит создание пароля ( navigator.credentials.create ) или аутентификацию ( navigator.credentials.get ), используя example.com в качестве идентификатора источника запроса (RP ID), браузер обнаружит, что RP ID не соответствует запрашивающему источнику. Если браузер поддерживает запросы от связанных источников (Related Origin Requests), он сначала ищет файл webauthn по https://{RP ID}/.well-known/webauthn . Если файл существует, браузер проверяет, находится ли источник, отправляющий запрос, в списке allowlist . Если да, он переходит к этапу создания пароля или аутентификации.

Если браузер не поддерживает запросы от связанных источников (Related Origin Requests), он выдает ошибку SecurityError .

Поддержка браузеров

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

Настройка связанных запросов происхождения

В приведенной ниже демонстрации используются два сайта: https://ror-1.glitch.me и https://ror-2.glitch.me . Чтобы пользователи могли входить в систему с одним и тем же паролем на обоих сайтах, используются запросы к связанным источникам (Related Origin Requests), позволяющие ror-2.glitch.me использовать ror-1.glitch.me в качестве своего идентификатора RP.

Демо

https://ror-2.glitch.me реализует запросы от связанных источников (Related Origin Requests) для использования ror-1.glitch.me в качестве идентификатора RP, поэтому как ror-1 , так и ror-2 используют ror-1.glitch.me в качестве идентификатора RP при создании пароля или аутентификации с его помощью. Мы также внедрили общую базу данных паролей для всех этих сайтов.

Ознакомьтесь со следующим пользовательским интерфейсом:

• Вы можете успешно создать пароль и пройти аутентификацию с его помощью на ror-2 — даже несмотря на то, что его идентификатор точки доступа (RP ID) — ror-1 (а не ror-2 ).
• После создания пароля на ror-1 или ror-2 ror-2 вы можете пройти аутентификацию с его помощью на обоих ror-1 . Поскольку ror-2 указывает ror-1 в качестве идентификатора точки доступа (RP ID), создание пароля или запрос на аутентификацию с любого из этих сайтов эквивалентны запросу на ror-1. Идентификатор точки доступа (RP ID) — это единственное, что связывает запрос с источником.
• После создания пароля на устройствах ror-1 или ror-2 ror-2 Chrome сможет автоматически заполнять его на обоих ror-1 .
• Учетные данные, созданные на любом из этих сайтов, будут иметь идентификатор RP ID ror-1 .

См. код:

• См. файл /.well-known/webauthn , настроенный в кодовой базе ror-1 .
• См. случаи появления RP_ID_ROR в кодовой базе ror-2 .

Шаг 1: Внедрить базу данных общих учетных записей.

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

Шаг 2: Настройте свой JSON-файл .well-known/webauthn на сайте site-1.

Сначала настройте site-1.com таким образом, чтобы site-2.com мог использовать его в качестве идентификатора участника процесса. Для этого создайте JSON-файл веб-аутентификации:

{
    "origins": [
        "https://site-2.com"
    ]
}

Объект JSON должен содержать ключ с именем origins, значением которого является массив из одной или нескольких строк, содержащих веб-источники.

Важное ограничение: максимум 5 меток.

Каждый элемент этого списка будет обработан для извлечения метки eTLD + 1. Например, метки eTLD + 1 для example.co.uk и example.de — это example . Но метка eTLD + 1 для example-rewards.com — это example-rewards . В Chrome максимальное количество меток — 5.

Шаг 3: Разместите ваш JSON-файл .well-known/webauthn на сайте site-1.

Затем разместите свой JSON-файл по адресу site-1.com/.well-known/webauthn .

Например, в Express:

app.get("/.well-known/webauthn", (req, res) => {
  const origins = {
    origins: ["https://site-2.com"],
  };
  return res.json(origins);
});

Здесь мы используем express res.json , который уже задаёт правильный content-type ( 'application/json' );

Шаг 4: Укажите идентификатор RP в site-2

В коде вашего site-2 везде, где это необходимо, укажите site-1.com в качестве идентификатора RP:

• При создании учетных данных:
  • В options создания учетных данных, передаваемых в вызов navigator.credentials.create на стороне клиента и обычно генерируемых на стороне сервера, укажите site-1.com в качестве идентификатора участника процесса.
  • Укажите site-1.com в качестве ожидаемого идентификатора RP, поскольку перед сохранением в базу данных выполняется проверка учетных данных.
• После аутентификации:
  • В options аутентификации, передаваемых в вызов navigator.credentials.get на стороне клиента и обычно генерируемых на стороне сервера, укажите site-1.com в качестве идентификатора участника процесса (RP ID).
  • Укажите site-1.com в качестве ожидаемого идентификатора участника рынка (RP ID), который необходимо проверить на сервере, поскольку проверка учетных данных выполняется перед аутентификацией пользователя.

Поиск неисправностей

Другие соображения

Делитесь ключами доступа на разных сайтах и ​​в мобильных приложениях.

Запросы с использованием связанных источников позволяют пользователям повторно использовать один и тот же пароль на нескольких сайтах . Чтобы разрешить пользователям повторно использовать один и тот же пароль на веб-сайте и в мобильном приложении , используйте следующие методы:

• В Chrome: Ссылки на цифровые активы . Подробнее см. в разделе «Добавить поддержку ссылок на цифровые активы» .
• В Safari: Связанные домены .

Обмен паролями между сайтами

Функция «Связанные запросы источника» позволяет пользователям повторно использовать пароль на разных сайтах. Решения для обмена паролями между сайтами различаются в зависимости от менеджера паролей. Для Google Password Manager используйте функцию «Ссылки на цифровые активы ». В Safari используется другая система .

Роль менеджеров учетных данных и пользовательских агентов

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