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

Maud Nalpas

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

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

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

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

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

Решение

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

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

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

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

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

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

В следующей демонстрации используются два сайта: https://ror-1.glitch.me и https://ror-2.glitch.me . Чтобы пользователи могли входить на оба сайта с одним и тем же ключом доступа, используются запросы Related Origin, позволяющие 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 — ror-1 (а не ror-2 ).
• Создав ключ доступа на ror-1 или ror-2 , вы сможете пройти аутентификацию с его помощью как на ror-1 , так и ror-2 . Поскольку ror-2 указывает ror-1 в качестве идентификатора RP, запрос на создание ключа доступа или аутентификацию с любого из этих сайтов аналогичен запросу на ror-1. Идентификатор RP — единственное, что связывает запрос с источником.
• После создания ключа доступа на ror-1 или ror-2 он может быть автоматически заполнен Chrome как на ror-1 , так и ror-2 .
• Учетные данные, созданные на любом из этих сайтов, будут иметь идентификатор RP 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 мог использовать его в качестве идентификатора RP. Для этого создайте JSON-файл webauthn:

{
    "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 .

Например, в экспрессе:

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 на сайте 2

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

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

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

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

Обмен ключами доступа между сайтами и мобильными приложениями

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

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

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

Запросы Related Origin позволяют пользователям повторно использовать один и тот же ключ доступа на разных сайтах. Решения для обмена паролями между сайтами различаются в зависимости от менеджера паролей. Для Google Password Manager используйте Digital Asset Links . В Safari используется другая система .

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

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