WebAuthn Signal API: Обновление и удаление Passkeys на стороне клиента

Экосистема Passkeys постоянно развивается. Чтобы способствовать этим изменениям, базовый стандарт WebAuthn также быстро развивается. Новые функции часто начинаются с технического объяснения на GitHub, а затем, после достаточного обсуждения, превращаются в pull request к стандарту. Недавно этот pull request был добавлен в черновик стандарта как WebAuthn Signal API. В этой статье мы рассмотрим:

• Зачем нужен WebAuthn Signal API: Какие сценарии использования он поддерживает?
• Как работает WebAuthn Signal API: Как именно он функционирует? Какие рекомендации существуют для доверяющих сторон?

На момент обновления этого поста в январе 2025 года, WebAuthn Signal API включен по умолчанию начиная с Chrome 132. Ранее он был известен как Reporting API, но был переименован, чтобы избежать конфликтов с другим API с таким же названием.

WebAuthn Signal API решает конкретные задачи, связанные с управлением Passkeys на стороне клиента. В частности, он помогает синхронизировать информацию между доверяющей стороной (RP) и аутентификаторами, которые являются частью операционных систем на стороне клиента. Существуют следующие важные сценарии использования:

Subscribe to our Passkeys Substack for the latest news.

Subscribe

При создании ключа доступа (passkey) он включает в себя несколько частей информации: user.id, user.name и user.displayName. Сам ключ доступа идентифицируется по уникальному Credential ID.

• user.id: это уникальный идентификатор, представляющий учетную запись, к которой привязан ключ доступа. Этот user.id имеет решающее значение, поскольку он используется для фактического сопоставления ключа доступа с учетной записью пользователя.
• user.name и user.displayName: это метаданные, используемые исключительно для отображения в пользовательском интерфейсе.

Следующая иллюстрация показывает типичную простую структуру базы данных, которая объясняет, какая информация обычно хранится в каждом поле:

Важно понимать, что хотя user.name (часто адрес электронной почты) и user.displayName (более дружелюбное, читаемое имя) помогают пользователю идентифицировать свою учетную запись в интерфейсе выбора, реальная связь между ключом доступа и учетной записью поддерживается через user.id и Credential ID:

• Учетная запись может иметь несколько ключей доступа, но каждый ключ уникально идентифицируется и сопоставляется с учетной записью с помощью user.id.
• Каждый ключ доступа сам по себе имеет уникальный Credential ID, который генерируется аутентификатором.

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

Обходной путь для этой проблемы — создать новый ключ доступа с обновленным user.name и тем же user.id, а затем перезаписать существующий ключ. Однако этот подход неудобен по нескольким причинам:

1. Избыточность: Каждый user.id может иметь только один ключ доступа на один ID доверяющей стороны, что означает, что старый ключ должен быть заменен новым, а это дополнительный шаг.
2. Пользовательский опыт: Пользователи не поймут, зачем им нужно создавать новый ключ доступа. Именно поэтому этот обходной путь не получил широкого распространения.
3. Сложность: Управление созданием ключей доступа и их заменой только для обновления метаданных — это излишняя сложность.

Адреса электронной почты, номера телефонов и другие идентификаторы могут регулярно меняться. Без простого способа прямого обновления user.name и user.displayName на аутентификаторе пользователи могут столкнуться с постоянной проблемой, когда они видят и вынуждены выбирать ключ доступа, связанный с их старым адресом электронной почты. Эта ситуация подрывает бесшовный опыт, который призваны обеспечить Passkeys. WebAuthn Signal API решает эту проблему, позволяя доверяющим сторонам сообщать об обновлениях метаданных ключей доступа, не требуя создания новых. Прежде чем мы объясним, как реализовать Signal API, мы рассмотрим второй важный сценарий использования, который он решает.

Become part of our Passkeys Community for updates & support.

Join

Еще один важный сценарий использования — удаление ключей доступа на аутентификаторе на стороне клиента. Со временем пользователи могут отзывать учетные данные через список управления ключами доступа или удалять свои учетные записи, и становится необходимым обеспечить удаление этих учетных данных с аутентификатора на стороне клиента, чтобы они не появлялись в будущих интерфейсах выбора учетных данных (Conditional UI / автозаполнение с помощью ключей доступа).

Необходимость в этой функциональности возникает в нескольких сценариях:

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

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

2. Удаление учетной записи: Когда пользователь удаляет свою учетную запись, все связанные с ней ключи доступа также должны быть удалены.
3. Политики безопасности: У доверяющих сторон могут быть политики безопасности, требующие отзыва учетных данных после периодов неактивности или из-за обнаруженных проблем с безопасностью.

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

Реализация WebAuthn Signal API включает в себя несколько шагов и соображений, чтобы обеспечить правильную и безопасную интеграцию функциональности. Signal API позволяет доверяющим сторонам (RP) обновлять или удалять учетные данные ключей доступа на аутентификаторе на стороне клиента. В этом разделе изложены ключевые соображения и шаги для реализации.

При реализации WebAuthn Signal API крайне важно учитывать следующие моменты:

• Сохранение конфиденциальности: WebAuthn Signal API разработан с учетом конфиденциальности пользователей, поскольку это один из основополагающих принципов WebAuthn. Это означает, что RP не получает обратной связи о том, было ли обработано запрошенное изменение. API работает в фоновом режиме, чтобы предотвратить любую потенциальную утечку информации о состоянии учетных данных.

• Доступность аутентификатора: Эффективность WebAuthn Signal API зависит от доступности аутентификатора. Это включает как физическую доступность (например, наличие ключа безопасности), так и программную поддержку (например, совместимость браузера и операционной системы). Браузер может выполнять действия только в том случае, если аутентификатор доступен и поддерживает необходимые операции без необходимости биометрической аутентификации.

• Ограничения по домену: API гарантирует, что только доверяющая сторона, связанная с определенным доменом, может запрашивать изменения в учетных данных, относящихся к этому домену. Это мера безопасности для предотвращения несанкционированных изменений третьими лицами.

• Credential ID как ключ: При обращении к ключам доступа Credential ID является основным ключом, используемым WebAuthn Signal API. Этот ID уникально идентифицирует ключ доступа на аутентификаторе на стороне клиента. API позволяет RP изменять метаданные, связанные с ключами доступа, или сигнализировать о том, что определенные ключи больше не должны использоваться, но только через Credential ID. Если аутентификатор не знает определенный Credential ID, он просто проигнорирует его.

Эти соображения необходимы для понимания наиболее важных аспектов правильной работы WebAuthn Signal API.

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

Обновление метаданных с помощью signalCurrentUserDetails(options)

Метод signalCurrentUserDetails(options) в Signal API специально разработан для обновления метаданных ключей доступа. Этот метод позволяет RP предоставлять текущие значения для user.name и user.displayName.

Вот как работает этот процесс (см. также стандарт WebAuthn Level 3).

1. Структура метода: Метод signalCurrentUserDetails(options) включает rp.id, user.id и обновленные значения для user.name и user.displayName.

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    name: "New user name",
    displayName: "New display name",
});

2. Обновление локальных метаданных: Поиск локально доступных (на аутентификаторе) учетных данных, которые соответствуют rpId и userId. Для всех совпадающих учетных данных аутентификатор обновит name и displayName.

3. Сохранение конфиденциальности: Процесс разработан с учетом сохранения конфиденциальности. Signal API не предоставляет RP обратной связи о том, были ли обновления успешно обработаны, что предотвращает утечку информации о состоянии учетных данных.

4. Согласованность на разных устройствах: Регулярно запуская методы signalCurrentUserDetails(options), RP могут обеспечить согласованность метаданных для ключей доступа на разных устройствах и платформах, где пользователь может проходить аутентификацию. Этот подход снижает вероятность отображения устаревшей или неверной информации в интерфейсе выбора учетных данных.

На скриншоте выше вы можете видеть, как Google Chrome сообщает пользователю о таком обновлении. WebAuthn Signal API является частью Chrome 130 и может быть протестирован с помощью Google Password Manager на десктопе, если активирован флаг экспериментальных веб-функций.

WebAuthn Signal API предоставляет механизмы для доверяющих сторон (RP) для сигнализации об удалении ключей доступа с аутентификаторов на стороне клиента. Это необходимо для того, чтобы устаревшие или недействительные учетные данные не появлялись в интерфейсе выбора, поддерживая тем самым оптимизированный и безопасный пользовательский опыт. Существует два метода для локального удаления ключей доступа: signalUnknownCredential(options) и signalAllAcceptedCredentials(options). Первый можно использовать в ситуациях, когда пользователь не аутентифицирован, а второй — когда пользователь аутентифицирован. Поэтому по соображениям конфиденциальности предпочтение следует отдавать второму методу.

Вот как работают эти два метода:

1. Структура метода: Метод signalUnknownCredential(options) включает rpId (ID доверяющей стороны) и credentialId (уникальный идентификатор учетных данных, которые нужно удалить).

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "aabbcc", // credential id the user just tried, base64url
});

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

3. Обработка метода: Когда вызывается метод signalUnknownCredential(options), аутентификатор на стороне клиента пытается найти учетные данные, соответствующие указанным rpId и credentialID, для исключения. В зависимости от возможностей аутентификатора, учетные данные удаляются или применяется специфичная для аутентификатора процедура для их скрытия в будущих церемониях аутентификации.

1. Структура метода: Метод signalAllAcceptedCredentials(options) включает rpId (ID доверяющей стороны), userId и список действительных Credential ID allAcceptedCredentialIds (список уникальных идентификаторов учетных данных, которые следует сохранить).

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    allAcceptedCredentialIds: ["bb"],
});

2. Вызов метода: RP вызывают этот метод, когда обнаруживают, что учетные данные должны быть удалены, и передают список действительных учетных данных. Этот метод предпочтительнее signalUnknownCredential(options) для удаления учетных данных.

3. Обработка метода: Когда вызывается метод signalAllAcceptedCredentials(options), аутентификатор на стороне клиента сопоставляет rpId и userId. Аутентификатор ищет все локальные учетные данные, соответствующие rpId и userId. Результат сравнивается с allAcceptedCredentialIds. Если есть локальные учетные данные, которых нет в allAcceptedCredentialIds, они удаляются локально (или скрываются, в зависимости от аутентификатора).

4. Восстановление скрытых учетных данных: Если учетные данные были только скрыты (в зависимости от аутентификатора) и теперь являются частью allAcceptedCredentialIds, они снова будут присутствовать в будущих церемониях аутентификации.

5. Полезные советы:

   • При использовании signalAllAcceptedCredentials(options) важно помнить, что аутентификаторы могут быть не подключены в момент выполнения этого метода. В результате доверяющим сторонам стоит рассмотреть возможность периодического запуска signalAllAcceptedCredentials(options), например, при каждом входе в систему, чтобы обеспечить актуальность всех учетных данных.
   • Доверяющие стороны должны быть осторожны при указании списка Credential ID (allAcceptedCredentialIds). Учетные данные, не включенные в этот список, могут быть скрыты или удалены аутентификатором, возможно, безвозвратно. Чтобы предотвратить случайное исключение действительных учетных данных, крайне важно убедиться, что список полон. Если действительный Credential ID был случайно пропущен, его следует как можно скорее снова добавить в signalAllAcceptedCredentials(options), чтобы он снова стал видимым, при условии, что аутентификатор это поддерживает.
   • По возможности аутентификаторам следует предпочитать временное скрытие учетных данных вместо их окончательного удаления. Этот подход может облегчить восстановление, если действительный Credential ID был случайно пропущен доверяющей стороной, позволяя восстановить его без необратимой потери.

На скриншоте выше вы можете видеть, как Google Chrome сигнализирует об удалениях. WebAuthn Signal API является частью Chrome 132 и может быть протестирован с помощью Google Password Manager на десктопе.

Чтобы эффективно реализовать WebAuthn Signal API и обеспечить бесшовную синхронизацию метаданных ключей доступа на аутентификаторах на стороне клиента, рассмотрите следующие рекомендации:

• Следите за обновлениями WebAuthn Signal API и его фактической реализацией: Будьте в курсе последних разработок и обновлений, связанных с Signal API. WebAuthn Signal API включен в Google Chrome 132, а за ним последуют и другие браузеры (например, Safari также объявил о поддержке). Регулярно проверяйте прогресс и обновления WebAuthn Signal API, чтобы ваша реализация соответствовала последним стандартам и практикам. Мы будем обновлять этот пост в будущем; в настоящее время он основан на информации, доступной на 14 января 2025 года.
• Начинайте с подхода signalAllAcceptedCredentials(options) после каждого успешного входа: Этот подход гарантирует, что все метаданные и Credential ID обновляются одним методом, что упрощает процесс, поддерживает согласованность на разных устройствах и платформах и одновременно деактивирует удаленные или устаревшие учетные данные.
• Обмен сообщениями в реальном времени с signalUnknownCredential(options) для крупномасштабных развертываний: Рассмотрите возможность использования обмена сообщениями в реальном времени с методом signalUnknownCredential(options) в крупномасштабных развертываниях или когда требуется немедленное обновление. Этот метод может повысить эффективность и точность управления учетными данными, обеспечивая быстрое удаление недействительных или устаревших учетных данных из интерфейса выбора.

Следуя этим рекомендациям, вы сможете эффективно реализовать WebAuthn Signal API, как только он получит поддержку, обеспечивая актуальность и согласованность метаданных ключей доступа на всех аутентификаторах на стороне клиента, тем самым предоставляя плавный и безопасный пользовательский опыт для Passkeys.

Стандарт WebAuthn постоянно развивается, ежемесячно становясь все более многофункциональным. Внедрение WebAuthn Signal API — это значительный шаг вперед в управлении метаданными и удалением ключей доступа на аутентификаторах на стороне клиента. Этот API решает важнейшие задачи по синхронизации информации между доверяющими сторонами (RP) и аутентификаторами, а также обеспечивает удаление недействительных или устаревших ключей доступа, тем самым улучшая пользовательский опыт.

• Зачем нужен Signal API? Signal API необходим для обновления метаданных и удаления ключей доступа на аутентификаторах на стороне клиента. Он решает проблемы, связанные с устаревшей информацией user.name и user.displayName, которая может вызывать путаницу при представлении учетных данных в интерфейсе выбора. Кроме того, он помогает поддерживать чистый и безопасный интерфейс выбора учетных данных, удаляя отозванные или удаленные ключи доступа.
• Как работает Signal API? Signal API работает, позволяя RP вызывать методы, сообщающие о текущем состоянии учетных данных, включая обновления метаданных и сигнализацию об удалении ключей доступа. Эти отчеты обрабатываются аутентификатором на стороне клиента, обеспечивая точность и актуальность информации, представляемой пользователям. API разработан с учетом сохранения конфиденциальности и работает, не предоставляя RP обратной связи об успехе обновлений.

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