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