Опубликовано: 13 ноября 2024 г.
Начиная с Chrome 132, настольная версия Chrome (macOS, Windows, Linux и ChromeOS) поддерживает Signal API, который позволяет поддерживать соответствие ключей доступа поставщиков ключей доступа с учетными данными открытого ключа на сервере проверяющей стороны.
При создании ключа доступа ( обнаруживаемых учетных данных ) метаданные, такие как имя пользователя и отображаемое имя, сохраняются поставщику ключа доступа (например, диспетчеру паролей) вместе с закрытым ключом, а учетные данные открытого ключа сохраняются в хранилище проверяющей стороны. (RP) сервер. Сохранение имени пользователя и отображаемого имени помогает пользователю определить, какой ключ доступа следует использовать для входа, поскольку пользователю предлагается выбрать ключ доступа при входе в систему. Это особенно полезно, когда у него есть более двух ключей доступа от разных поставщиков ключей доступа.
Однако в некоторых случаях различия между списком ключей доступа у поставщика ключей и списком учетных данных на сервере могут вызвать путаницу.
В первом случае пользователь удаляет учетные данные на сервере, оставляя ключ доступа в поставщике ключей доступа нетронутым. В следующий раз, когда пользователь попытается войти в систему с помощью ключа доступа, поставщик ключа доступа все равно будет предоставлен пользователю. Однако попытка входа завершится неудачей, поскольку сервер не сможет выполнить проверку с помощью удаленного открытого ключа.
Второй случай — когда пользователь обновляет свое имя пользователя или отображаемое имя на сервере. В следующий раз, когда пользователь попытается войти в систему, ключ доступа в поставщике ключей доступа продолжит отображать старое имя пользователя и отображаемое имя, даже если они были обновлены на сервере. В идеале они должны быть синхронизированы.
Сигнальный API
API сигналов WebAuthn позволяет RP передавать существующие учетные данные подключенным поставщикам ключей доступа. Это позволяет поддерживающему поставщику ключей доступа обновлять или удалять неверные или отозванные ключи доступа из своего хранилища, чтобы они соответствовали серверу.
Например, когда пользователю не удается войти в систему RP, поскольку соответствующие учетные данные на сервере RP больше не существуют, RP может использовать Signal API, чтобы сигнализировать поставщику ключа доступа о том, что удаленные учетные данные больше не действительны, поэтому поставщик ключа доступа может удалить связанный ключ доступа.
Другой пример: когда пользователь переходит на страницу настроек RP и удаляет существующие учетные данные, RP может использовать Signal API для передачи списка доступных учетных данных поставщику ключей доступа, чтобы поставщик ключей доступа мог синхронизировать связанные ключи доступа.
Он также может сигнализировать об обновлении имени пользователя и отображаемого имени, чтобы можно было обновить метаданные ключа доступа, хранящиеся для того же пользователя.
Например, когда пользователь обновляет свое имя пользователя или отображаемое имя на RP, RP может использовать Signal API для передачи обновленной информации о пользователе поставщику ключей доступа, чтобы поставщик ключей доступа мог синхронизировать пользовательскую информацию связанных ключей доступа.
Менеджер паролей Google на настольном компьютере Chrome реализует Signal AP. Поставщики ключей доступа на основе расширений Chrome сами решают, будут ли они отражать сигнал или нет.
В будущем мы планируем поддерживать Signal API в Android Chrome.
Чтобы узнать, как интегрировать WebAuthn Signal API, прочтите статью Синхронизация списка паролей с сервером с помощью Signal API .