Возможности клиента WebAuthn

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

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

В этой статье мы ответим на следующие вопросы:

1. Что такое возможности клиента WebAuthn?
2. Какие возможности клиента WebAuthn существуют?
3. Как возможности клиента WebAuthn улучшают внедрение Passkeys?
4. Почему возможности клиента WebAuthn важны как для разработчиков, так и для менеджеров по продукту?

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

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

Например, если браузер сообщает, что он поддерживает биометрическую аутентификацию (например, Touch ID), разработчики могут спроектировать свои процессы входа так, чтобы предложить пользователям возможность войти с помощью отпечатка пальца. И наоборот, если браузер не поддерживает определенные функции, разработчики могут предоставить запасные варианты, такие как пароль или одноразовый код по SMS.

Стандарт WebAuthn Level 3 вводит несколько новых возможностей клиента, которые делают внедрение Passkeys более универсальным и удобным для пользователя. Первая поддержка вызова API getClientCapabilities() была представлена в Safari 17.4.

Для определения поддержки в браузере может быть полезен следующий фрагмент кода:

// Check if PublicKeyCredential is supported in the current browser
if (typeof PublicKeyCredential === "undefined") {
    console.log("PublicKeyCredential is not supported in this browser.");
}
 
// Check if getClientCapabilities method exists on PublicKeyCredential
if (typeof PublicKeyCredential.getClientCapabilities === "function") {
    try {
        let capabilities = await PublicKeyCredential.getClientCapabilities();
        console.log(capabilities);
    } catch (error) {
        console.error("Error getting client capabilities:", error);
    }
} else {
    console.log("getClientCapabilities is not supported in this browser");
}

getClientCapabilities() позволяет веб-сайтам и приложениям запрашивать у клиента (например, браузера или устройства) информацию о том, какие функции WebAuthn он поддерживает. Понимая возможности клиента, разработчики могут оптимизировать процессы аутентификации, чтобы использовать доступные функции, такие как биометрическая аутентификация, и предоставлять альтернативные методы, если определенные возможности отсутствуют.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Давайте подробнее рассмотрим возможности клиента WebAuthn и их влияние на интеграцию Passkeys:

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

Подобно conditionalCreate, conditionalGet автоматически запускает вход с помощью ключа доступа. Это полезно в сценариях, где требуется наилучший пользовательский опыт с Passkeys, делая вход не только беспарольным, но и без имени пользователя (пользователи просто нажимают на выбранный ключ доступа в модальном окне / выпадающем списке и могут пройти аутентификацию). Используя эту возможность, разработчики могут обеспечить, чтобы аутентификация с помощью ключа доступа происходила только тогда, когда это уместно, минимизируя ненужные запросы и улучшая пользовательский опыт.

hybridTransport обеспечивает возможность использования ключей доступа на разных устройствах, позволяя осуществлять бесшовную межплатформенную аутентификацию (через QR-коды и Bluetooth). Например, пользователь может использовать ключ доступа, хранящийся на его смартфоне, для входа в сервис на своем настольном компьютере. Эта возможность позволяет пользователям безопасно аутентифицироваться без необходимости вручную переносить ключи доступа или полагаться на традиционные методы входа для каждого устройства, создавая единый опыт аутентификации.

Платформенные аутентификаторы, такие как Windows Hello, Face ID или Touch ID, встроены непосредственно в устройства и предлагают более быстрый, плавный и безопасный опыт использования Passkeys, позволяя пользователям аутентифицироваться с помощью биометрии или другого встроенного в устройство метода (например, PIN-кода или графического ключа).

Become part of our Passkeys Community for updates & support.

Join

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

Возможность relatedOrigins позволяет осуществлять бесшовную аутентификацию между различными доменами, принадлежащими одной организации (например, amazon.com и amazon.de). Например, если компания управляет несколькими доменами или имеет разные поддомены, пользователи могут войти один раз и получить доступ ко всем ресурсам без повторной аутентификации на каждом из них. Эта возможность упрощает пользовательский опыт, уменьшая трение, и особенно ценна для предприятий в международной среде или с многосервисными платформами.

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

Давайте рассмотрим пример. Пользователь (userId: A) имеет 2 ключа доступа с идентификаторами учетных данных, которые в кодировке Base64URL выглядят как X и Y. Затем пользователь удаляет ключ доступа X в настройках учетной записи веб-сервиса (example.com) (таким образом, открытый ключ удаляется). Теперь выполним следующий фрагмент кода:

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "A", // WebAuthn User Handle, Base64URL.
    allAcceptedCredentialIds: ["Y"],
});

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

Ключи доступа, не присутствующие в allAcceptedCredentialIds, будут удалены или скрыты, возможно, безвозвратно. Поэтому важно, чтобы проверяющие стороны следили за тем, чтобы действительные идентификаторы учетных данных WebAuthn никогда не удалялись из списка. Если действительный идентификатор учетных данных был случайно удален, проверяющая сторона должна немедленно включить его в другой вызов signalAllAcceptedCredentials(options) как можно скорее, чтобы «показать» ключ доступа. Если ключ доступа не скрыт, а удален, то исправить ситуацию будет практически невозможно.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

Метод signalCurrentUserDetails(options) сообщает текущее имя пользователя и его отображаемое имя WebAuthn. Когда вызывается signalCurrentUserDetails(options), клиент выполняет определенный набор шагов для выполнения этого действия.

Давайте посмотрим на пример. Пользователь с идентификатором пользователя WebAuthn A обновляет свое имя в настройках учетной записи на веб-сайте (example.com). Затем проверяющая сторона может выполнить следующий код:

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "A", // user ID, Base64URL.
    name: "New user name",
    displayName: "New display name",
});

Аутентификатор затем обновит метаданные локально сохраненного ключа доступа. Большое преимущество заключается в том, что в будущих запросах Conditional UI / автозаполнения ключей доступа в меню выбора Conditional UI / выпадающем списке будет отображаться обновленное имя и отображаемое имя WebAuthn.

Метод signalUnknownCredential(options) сообщает, что идентификатор учетных данных WebAuthn не распознан проверяющей стороной WebAuthn, например, если ключ доступа был удален пользователем. В отличие от signalAllAcceptedCredentials(options), этот метод не требует предоставления полного списка принятых идентификаторов учетных данных и идентификатора пользователя WebAuthn, тем самым предотвращая потенциальные утечки конфиденциальности для неаутентифицированных вызывающих сторон.

Давайте посмотрим на пример. Пользователь удаляет ключ доступа с идентификатором учетных данных X в настройках учетной записи на веб-сайте (example.com) (таким образом, открытый ключ удаляется). Однако закрытый ключ все еще доступен на устройстве пользователя. Это означает, что в будущих запросах на вход с помощью Conditional UI / автозаполнения ключей доступа (с пустым списком allowCredentials) этот ключ доступа все еще может быть выбран. Попытка входа, однако, завершится неудачей, так как открытый ключ уже удален, поэтому проверяющая сторона должна выполнить:

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "X", // credential ID the user just tried, Base64URL
});

Аутентификатор затем удалит или скроет ключ доступа с идентификатором учетных данных X от будущих процедур аутентификации.

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

Темпы внедрения, вероятно, ускорятся по мере созревания Level 3 и появления этих функций в большем количестве браузеров. Если вы хотите узнать, сколько пользователей могут воспользоваться getClientCapabilities() прямо сейчас, вы можете проверить реальные данные с помощью бесплатного Passkeys Analyzer. Следите за примечаниями к выпускам браузеров и соответствующей документацией, чтобы планировать более широкую совместимость по мере ее развития.

Are your users passkey-ready?

Test Passkey-Readiness

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

Однако имейте в виду, что не все браузеры пока поддерживают вызов API getClientCapabilities() (по состоянию на ноябрь 2024 года). Существует полифилл, доступный здесь, который можно использовать до тех пор, пока все браузеры не догонят.

Используйте getClientCapabilities() в начале вашего кода, чтобы определить поддерживаемые клиентом функции в начале загрузки страницы / процесса аутентификации. Это позволит вам динамически настраивать пользовательский опыт и предоставлять функции Passkeys, которые работают на данном устройстве / в браузере, например, предлагая платформенную аутентификацию, если она поддерживается, или альтернативные методы (например, одноразовые коды по SMS или аппаратные ключи безопасности), если нет.

Если вы добавляете Passkeys на веб-сайт / в приложение, которое в настоящее время использует пароли, функция conditionalCreate может стать настоящим стимулом для внедрения Passkeys. В фоновом режиме, во время автозаполнения пароля с помощью подходящего менеджера учетных данных (на октябрь 2024 года только Apple Passwords), ключ доступа генерируется автоматически и будет предпочтителен при будущих автозаполнениях.

Чтобы обеспечить не только высокое внедрение Passkeys, но и частое использование Passkeys для входа, старайтесь проверять, может ли устройство / браузер использовать Conditional UI / автозаполнение Passkeys, проверив наличие conditionalGet. Таким образом, вы будете подталкивать пользователей к использованию созданного ключа доступа для входа, так как он проактивно предлагается операционной системой / браузером и требует еще меньше усилий, чем автозаполнение пароля.

Используйте hybridTransport для обеспечения межплатформенной аутентификации (через QR-код и Bluetooth), позволяя пользователям беспрепятственно входить со своего смартфона, даже если они получают доступ к вашему сервису на настольном компьютере.

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

1. Что такое возможности клиента WebAuthn? Мы объяснили, как эти функции позволяют браузерам и платформам сообщать о своей поддержке определенных функциональностей, предоставляя разработчикам больше контроля над процессами аутентификации.
2. Какие возможности клиента WebAuthn существуют? Мы предоставили обзор новых возможностей, представленных в стандарте Level 3, включая getClientCapabilities, conditionalCreate, hybridTransport и другие.
3. Как возможности клиента WebAuthn улучшают внедрение Passkeys? Мы обсудили, как эти возможности упрощают интеграцию, улучшают межплатформенное использование и повышают безопасность.
4. Почему возможности клиента WebAuthn важны для разработчиков? Эти функции помогают создавать бесшовные и безопасные процессы аутентификации, соответствующие современным ожиданиям пользователей, делая внедрение проще и эффективнее.

Мы призываем вас изучить новые функции WebAuthn Level 3 и следить за их внедрением в браузерах. Если вы хотите внедрить Passkeys и воспользоваться этими передовыми возможностями, свяжитесь с нами для получения экспертных рекомендаций и поддержки.