--- url: 'https://www.corbado.com/ru/blog/shpargalka-po-klyucham-dostupa' title: 'Шпаргалка для разработчиков по ключам доступа (passkeys)' description: 'Руководство для разработчиков по WebAuthn и внедрению ключей доступа. Скачайте шпаргалку в формате PDF или используйте этот сайт, где собрана вся информация.' lang: 'ru' author: 'Lukas R.' date: '2026-07-03T07:12:42.073Z' lastModified: '2026-07-03T07:12:54.800Z' keywords: 'шпаргалка, руководство разработчика, WebAuthn, ключи доступа, passkeys, аутентификация' category: 'Passkeys Implementation' --- # Шпаргалка для разработчиков по ключам доступа (passkeys) ## Скачать бесплатно Скачайте полную **Шпаргалку по ключам доступа бесплатно** и получите всю необходимую информацию. - ✅ Уже более 4000 скачиваний - ✅ По запросу команд разработчиков из Ally, Kmart, Octopus [Energy](https://www.corbado.com/passkeys-for-energy) и Stanford CS - ✅ Никакой маркетинговой воды — только технические подробности ## Key Facts - Аутентификация с помощью ключей доступа (passkeys) состоит из двух **церемоний**: регистрации (аттестации, attestation) и входа (утверждения, assertion), каждая из которых требует сгенерированного сервером случайного вызова (challenge), подписанного аутентификатором. - **PublicKeyCredentialCreationOptions** управляет регистрацией ключа доступа, в то время как **PublicKeyCredentialRequestOptions** управляет входом. Оба объекта генерируются на стороне сервера и содержат вызов для подписи аутентификатором. - **Условный UI (Conditional UI)** отображает доступные ключи доступа в виде подсказок для автозаполнения, но требует обнаруживаемых учетных данных (резидентных ключей, resident keys) и поддерживается не всеми комбинациями ОС и браузеров. - **Идентификатор проверяющей стороны (rpID, Relying Party ID)** привязывает ключ доступа к домену: аутентификация проходит успешно только в том случае, если URL совпадает или является непубличным поддоменом rpID. - Ключи доступа используют **алгоритмы COSE** для генерации ключей, при этом конкретный алгоритм записывается в атрибуте parsedCredentialPublicKey объекта аттестации. ## 1. Церемонии WebAuthn Аутентификация с помощью ключей доступа основана на двух процессах, также называемых церемониями: **регистрации** (также известной как **фаза аттестации**) и **входа** (также известного как **фаза утверждения**).\ Каждая фаза требует случайного вызова (challenge), сгенерированного сервером, который подписывается аутентификатором и отправляется обратно на сервер WebAuthn для проверки пользователя. ### 1.1 Регистрация (Аттестация) ![Процесс регистрации (церемония аттестации) в WebAuthn](https://www.corbado.com/website-assets/65fad0076e7b4367976ee993_cs_1_1_registration_flow_min_26eb12d652.png)_В церемонии регистрации используются два основных объекта: PublicKeyCredentialCreationOptions и attestation._ [Watch on YouTube](https://www.youtube.com/watch?v=0hRYXHESA24) ### 1.2 Вход (Утверждение) ![Процесс входа (церемония утверждения) в WebAuthn](https://www.corbado.com/website-assets/65fad0f2e412e9ad9d2a5bf1_cs_1_2_login_flow_min_2aaefc04dd.png)_В церемонии входа используются два основных объекта: PublicKeyCredentialRequestOptions и assertion._ ## 2. Важные объекты Для регистрации и входа с помощью ключей доступа используются четыре основных объекта: - PublicKeyCredentialCreationOptions - PublicKeyCredentialRequestOptions - attestation - assertion В этом разделе также объясняется объект authenticatorSelection, который используется в PublicKeyCredentialCreationOptions. ### 2.1 Параметры создания учетных данных с открытым ключом (Public Key Credential Creation Options) PublicKeyCredentialCreationOptions является центральным объектом фазы аттестации (Регистрации). Он создается и возвращается [сервером WebAuthn](#webauthn-server). ```json { "PublicKeyCredentialCreationOptions": { "rp": { "id": "passkeys.eu", "name": "Corbado Passkeys Demo" }, "user": { "displayName": "john.doe", "id": "dXNyLZ….DU10Tc", "name": "john@doe.com" }, "challenge": "888fix4Bus...pHHr3Y", "pubKeyCredParams": [ { "alg": -7, "type": "public-key" }, { "alg": -257, "type": "public-key" } ], "excludeCredentials": [], "authenticatorSelection": { "authenticatorAttachment": "platform", "residentKey": "required", "userVerification": "required" }, "attestation": "none", "extensions": {} } } ``` Объект содержит следующие атрибуты: - **rp:** Идентифицирует проверяющую сторону (Relying Party = сервер, который хочет аутентифицировать пользователя), см. раздел [4.2 Идентификатор проверяющей стороны (rpID).](#relying-party-id) - **user:** Содержит данные об учетной записи пользователя, запрашивающей аттестацию. ID представляет собой последовательность байтов, выбранную проверяющей стороной, которая не должна содержать личную информацию. Имя пользователя или адрес электронной почты сохраняется вместо этого в атрибуте name или displayName. Подробнее об этом читайте в разделе [4.1 Схема базы данных.](#database-schema) - **challenge:** Случайно сгенерированный объект BufferSource в кодировке base64URL, который должен быть подписан аутентификатором. - **pubKeyCredParams:** Заданные атрибуты создаваемых учетных данных, обычно это поддерживаемый алгоритм(ы). - **timeout:** Необязательное время в миллисекундах, в течение которого клиент должен ожидать завершения вызова. - **excludeCredentials:** Необязательный список учетных данных для ограничения создания нескольких ключей доступа на одном устройстве. - **authenticatorSelection:** Необязательный выбор используемого аутентификатора для метода, например, требуется ли residentKey. См. [2.5 authenticatorSelection](#authenticatorSelection). - **attestation:** Может использоваться для запроса передачи объекта аттестации проверяющей стороне в определенной форме. Возможные значения: none (по умолчанию), indirect, direct и enterprise. - **extensions:** Необязательный запрос(ы) на дополнительную обработку, например, конкретные возвращаемые значения. Например: - _credProbs_ запрашивает информацию о том, являются ли созданные учетные данные обнаруживаемыми (discoverable) - _prf_ позволяет проверяющей стороне использовать выходные данные псевдослучайной функции (PRF), связанной с учетными данными ### 2.2 Параметры запроса учетных данных с открытым ключом (Public Key Credential Request Options) PublicKeyCredentialRequestOptions является центральным объектом фазы утверждения (Входа). Он создается и возвращается [сервером WebAuthn](#webauthn-server). ```json { "publicKeyCredentialRequestOptions": { "challenge": "pT7HMA-…dFPHk", "timeout": 500, "rpId": "passkeys.eu", "userVerification": "preferred", "allowCredentials": [], "extensions": [] } } ``` Объект содержит следующие атрибуты: - **challenge, timeout, extensions:** см. [выше](#creationoptions). - **rpId:** Идентификатор проверяющей стороны для запроса утверждения, см. раздел [4.2 Идентификатор проверяющей стороны (rpID).](#relying-party-id) - **allowCredentials:** Необязательный список учетных данных, разрешенных для аутентификации, указывающий предпочтения вызывающей стороны в порядке убывания. Этот список будет заполнен объектами PublicKeyCredentialDescriptors. - **userVerification:** Необязательное значение для указания требований к проверке пользователя (user verification) во время операции. Возможные значения: preferred (по умолчанию), required или discouraged. ### 2.3 Аттестация (Attestation) Во время церемонии **аттестации** / регистрации аутентификатор возвращает этот **Ответ на регистрацию (Registration Response)**. Вы можете попробовать это сами в [Отладчике ключей доступа (Passkeys Debugger)](https://www.passkeys-debugger.io/). ```json { "authenticatorAttachment": "platform", "id": "JKZbixUfKN_aZtimefYT-OjH5dw", "rawId": "JKZbixUfKN_aZtimefYT-OjH5dw", "response": { "attestationObject": { "fmt": "none", "attStmt": {}, "authData": { "rpIdHash": "PpZrl-Wqt-OFfBpyy2SraN1m7LT0GZORwGA7-6ujYkM", "flags": { "userPresent": true, "userVerified": true, "backupEligible": true, "backupStatus": true, "attestedData": true, "extensionData": false }, "counter": 0, "aaguid": { "raw": "fbfc3007-154e-4ecc-8c0b-6e020557d7bd", "name": "iCloud Keychain" }, "credentialID": "JKZbixUfKN_aZtimefYT-OjH5dw", "credentialPublicKey": "pQECAyYgASFYIPWLalDzyxIDmAADvfK8iNM5To50kh7TyPH-teEz8RMdIlgg3D7bPIWQJ8z-WFn3zdYZzJw9c7mhPdmflQqD9vV7efA", "parsedCredentialPublicKey": { "keyType": "EC2 (2)", "algorithm": "ES256 (-7)", "curve": 1, "x": "9YtqUPPLEgOYAAO98ryI0zlOjnSSHtPI8f614TPxEx0", "y": "3D7bPIWQJ8z-WFn3zdYZzJw9c7mhPdmflQqD9vV7efA" } } }, "clientDataJSON": { "type": "webauthn.create", "challenge": "k2p6f-upzP_hc6NZvmMAxiI0VSTeQIeXXVRGW62LTj0", "origin": "https://www.passkeys-debugger.io", "crossOrigin": false }, "transports": ["hybrid", "internal"], "authenticatorData": "PpZrl-Wqt-OFfBpyy2SraN1m7LT0GZORwGA7-6ujYkNdAAAAAPv8MAcVTk7MjAtuAgVX170AFCSmW4sVHyjf2mbYpnn2E_jox-XcpQECAyYgASFYIPWLalDzyxIDmAADvfK8iNM5To50kh7TyPH-teEz8RMdIlgg3D7bPIWQJ8z-WFn3zdYZzJw9c7mhPdmflQqD9vV7efA", "publicKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE9YtqUPPLEgOYAAO98ryI0zlOjnSSHtPI8f614TPxEx3cPts8hZAnzP5YWffN1hnMnD1zuaE92Z-VCoP29Xt58A", "publicKeyAlgorithm": -7 }, "type": "public-key", "clientExtensionResults": {} } ``` **Аттестация** содержит некоторые важные компоненты, такие как [attestationObject](#attestationObject), [algorithm](#algorithm) и флаги [transport](#transport). #### 2.3.1 attestationObject ![Объект attestationObject является частью аттестации в WebAuthn](https://www.corbado.com/website-assets/65fad76914987b84f3ecf4cd_cs_2_3_attestation_Object_min_12a3b9e5cc.png) Взято из [Спецификации W3C Webauthn](https://www.w3.org/TR/webauthn-2/#attestation-object) **attestationObject** — это объект в кодировке CBOR, содержащий информацию о вновь созданных учетных данных, открытом ключе и другие соответствующие данные: - **fmt** обычно имеет значение "none" для ключей доступа - **attStmt** пуст для ключей доступа и заполнен для других аутентификаторов, например, аппаратных ключей безопасности - **authData** — это буфер значений, содержащий следующие данные: ![authData — это буфер значений, содержащий, например, флаги, счетчики и расширения](https://www.corbado.com/website-assets/65fc7c70babae11893e3e1e1_cs_2_3_auth_Data_min_7a7d39d083.png) Подробнее читайте о [расширениях](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API/WebAuthn_extensions). #### algorithm Ключи доступа генерируются с помощью **алгоритмов COSE**, при этом используемый алгоритм указывается в **атрибуте algorithm** объекта parsedCredentialPublicKey в [объекте аттестации](#attestation).\ Ниже представлен обзор наиболее важных алгоритмов COSE: ![Ключи доступа генерируются с помощью алгоритмов COSE](https://www.corbado.com/website-assets/65fade5ce80ed150f88b59fb_cs_2_3_COSE_algorithms_min_f0d1a5f931.png) #### 2.3.2 transport Свойство **transports** указывает механизмы, с помощью которых аутентификатор может связываться с клиентом. Некоторые общие, типичные комбинации значений: - **"transports": \["internal","hybrid"]**: Ключи доступа могут использоваться из платформенного аутентификатора (например, Face ID, Touch ID, Windows Hello) или через кроссплатформенную аутентификацию (с использованием QR-кода и Bluetooth). - **"transports": \["internal"]**: Ключи доступа могут использоваться только из платформенного аутентификатора (например, Face ID, Touch ID, Windows Hello). - **Свойство "transports" не установлено:** поведение по умолчанию, которое не дает никаких указаний. ### 2.4 Утверждение (Assertion) Во время церемонии **утверждения** / входа аутентификатор возвращает этот **Ответ на вход (Login Response)**. Вы можете попробовать это сами в [Отладчике ключей доступа (Passkeys Debugger)](https://www.passkeys-debugger.io/). ```json { "id": "JKZbixUfKN_aZtimefYT-OjH5dw", "rawId": "JKZbixUfKN_aZtimefYT-OjH5dw", "type": "public-key", "authenticatorAttachment": "platform", "response": { "authenticatorData": { "rpIdHash": "PpZrl-Wqt-OFfBpyy2SraN1m7LT0GZORwGA7-6ujYkM", "flags": { "userPresent": true, "userVerified": true, "backupEligible": true, "backupStatus": true, "attestedData": false, "extensionData": false }, "counter": 0 }, "clientDataJSON": { "type": "webauthn.get", "challenge": "GCVkITWbe2l2dttsn_DgJYvH9QPHPDo0ygWgcgI6B7U", "origin": "https://www.passkeys-debugger.io", "crossOrigin": false, "other_keys_can_be_added_here": "do not compare clientDataJSON against a template. See https://goo.gl/yabPex" }, "signature": "MEQCIA-orC8N2KKWOxyY17BWP8lB-Be5to9btXRnJZf2SLhXAiBGxJe5Eu5LwOTbsyzAYmIXHOhlC3pN7s7Q1fRLvEW57g", "userHandle": "_FKz1uwqmR_3yGq6hJntzoIFwFC_d1u_53YRELh0KlE" } } ``` **Утверждение** содержит некоторые важные компоненты, такие как flags, signature и userHandle. #### 2.4.1 flags Вот обзор наиболее важных **флагов (flags)** и их комбинаций: ![Наиболее важные флаги: userPresent, userVerified, backupEligible, backupStatus](https://www.corbado.com/website-assets/65fc7ca5a6a6fb1f3e66b514_cs_2_4_flags_min_19e5ddc4ce.png) #### 2.4.2 signature **Подпись (signature)** используется для проверки того, что пользователь, пытающийся войти в систему, действительно обладает закрытым ключом. Подпись создается путем конкатенации authenticatorData и clientDataHash (то есть версии ClientDataJSON в формате SHA-256) и подписания результата закрытым ключом (в аутентификаторе). Для проверки с помощью открытого ключа мы также конкатенируем authenticatorData и clientDataHash. Если результат проверки возвращает true, аутентификация прошла успешно. ![Подпись используется для проверки закрытого ключа](https://www.corbado.com/website-assets/65fae2ad96200e9576992209_cs_2_4_signature_min_36b9b8ccbe.png) #### 2.4.3 userHandle **userHandle** — это фактический user_id. Подробнее об user_id читайте в разделе [**4.1 Схема базы данных.**](#database-schema) ### 2.5 authenticatorSelection Объект **authenticatorSelection** позволяет серверу задавать настройки для аутентификатора и создания учетных данных со следующими значениями: #### 2.5.1 authenticatorAttachment - **Platform:** Аутентификатор привязан к платформе клиента и, следовательно, не является съемным. - **Cross-platform:** Аутентификатор не привязан к платформе клиента и может использоваться на нескольких устройствах. #### 2.5.2 residentKey - **Required:** Аутентификатор должен создать резидентный ключ (если это невозможно, операция должна завершиться ошибкой). - **Preferred:** Аутентификатор должен попытаться создать резидентный ключ (если это невозможно, он должен создать нерезидентный ключ). - **Discouraged:** Аутентификатор должен создать нерезидентный ключ (если это невозможно, операция должна завершиться ошибкой). > **Резидентные ключи (также называемые обнаруживаемыми учетными данными, Discoverable Credential):** Резидентные ключи хранятся в аутентификаторе и извлекаются во время аутентификации. Таким образом, клиент может обнаружить список возможных ключей; именно поэтому Условный UI (Conditional UI) требует резидентных ключей. > **Нерезидентные ключи (также называемые необнаруживаемыми учетными данными, Non-Discoverable Credential):** В случае нерезидентных ключей идентификатор учетных данных (credential ID) хранится на сервере и предоставляется во время аутентификации. Идентификатор учетных данных представляет собой [непрозрачный идентификатор](https://www.w3.org/TR/webauthn-3/#sctn-credential-id), внутренняя структура которого зависит от реализации: аутентификаторы могут хранить закрытые ключи напрямую, использовать зашифрованную обертку ключей или получать ключи из внутренних секретов. Точный механизм зависит от реализации аутентификатора. #### 2.5.3 userVerification - **Required:** Операция должна проверить пользователя (user verification). - **Preferred:** Операция должна проверить пользователя, но может быть продолжена без нее (стандартный вариант). - **Discouraged:** Операция не должна проверять пользователя. > **Предупреждение:** Если установлено значение "**Preferred**", пользователь или его устройство могут пропустить проверку пользователя в процессе аутентификации (подробнее читайте в этой [статье](https://web.dev/articles/passkey-form-autofill)). ## 3. Условный UI (Conditional UI) **Условный UI** (автозаполнение ключей доступа) отображает доступные ключи доступа в выпадающем списке для пользователя, когда у пользователя есть резидентный ключ, зарегистрированный у проверяющей стороны. Это повышает удобство использования ключей доступа, но требует дополнительных усилий по разработке и доступно не для всех комбинаций ОС / браузеров. ### 3.1 Поток входа с Условным UI ![Процесс входа с использованием Условного UI в WebAuthn](https://www.corbado.com/website-assets/65fae71a75d50f6ba14041d9_cs_3_1_conditional_ui_flow_min_394a12f521.png)_Как и обычный вход, Условный UI также использует объекты PublicKeyCredentialRequestOptions и assertion_ ### 3.2 Совместимость устройств Условный UI доступен не на всех комбинациях операционных систем и браузеров (пока). Вот обзор текущего охвата браузеров (март 2024 года): ![Таблица, показывающая доступность Условного UI в комбинациях ОС и браузеров](https://www.corbado.com/website-assets/65fae8d6321e72be11445913_cs_3_2_conditional_ui_compatibility_min_d5767f13b3.png) Актуальный обзор можно найти на [этом сайте.](https://caniuse.com/mdn-api_publickeycredential_isconditionalmediationavailable_static) ### 3.3 Примеры кода #### 3.3.1 Метод Условного UI Полный минималистичный код для метода Условного UI выглядит следующим образом: ```html Conditional UI ``` #### 3.3.2 Проверка совместимости браузера Условный UI работает только с **резидентными ключами** / обнаруживаемыми учетными данными.\ Рекомендуется предоставить **отдельную конечную точку сервера** для начала входа в систему через Условный UI.\ Клиент должен соответствовать ряду требований: - Браузер должен поддерживать Условный UI (см. [3.2 Совместимость устройств](#device-compatibility)). - JavaScript должен быть включен, и веб-страница должна содержать поле ввода HTML. - Параметры тайм-аута следует игнорировать. Во избежание ошибок сервер должен сначала проверить доступность клиента с помощью этой функции: В реальном трафике проблемы с обнаружением и жизненным циклом часто проявляются как `NotAllowedError` или `AbortError`. Используйте руководство по ошибкам WebAuthn для классификации ожидаемых и неожиданных ошибок, включая ошибки нативных менеджеров учетных данных для ключей доступа. ```javascript // источник: https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/isConditionalMediationAvailable#examples // Доступность `window.PublicKeyCredential` означает, что WebAuthn можно использовать. if (window.PublicKeyCredential && PublicKeyCredential.isConditionalMediationAvailable) { // Проверяем доступность условного посредничества (conditional mediation). const isCMA = await PublicKeyCredential.isConditionalMediationAvailable(); if (isCMA) { // Вызываем конечную точку начала аутентификации WebAuthn let options = await WebAuthnClient.getPublicKeyRequestOptions(); const credential = await navigator.credentials.get({ publicKey: options.publicKeyCredentialRequestOptions, mediation: "conditional", }); /* ... */ } } ``` #### 3.3.3 Токен автозаполнения в полях ввода Поле ввода должно получить HTML-токен автозаполнения (autofill token), который сигнализирует клиенту о необходимости подставить ключи доступа в текущий запрос. Помимо ключей доступа, токены автозаполнения могут быть сопряжены с существующими токенами, например, именами пользователей и паролями: - autocomplete="username webauthn": Помимо отображения ключей доступа, также предлагает автозаполнение имени пользователя. - autocomplete="current-password webauthn": Помимо отображения ключей доступа, дополнительно запрашивает автозаполнение пароля. ```html ``` ## 4. Сервер WebAuthn ### 4.1 Схема базы данных Обязательной или стандартизированной схемы базы данных для серверов WebAuthn не существует. Однако этот пример схемы базы данных может быть использован для хранения необходимой информации и обеспечения всех функций сервера WebAuthn: ![Пример схемы базы данных для сервера WebAuthn, содержащий данные для пользователя и учетных данных](https://www.corbado.com/website-assets/65fc7cda64ff7798cdbb2dfc_cs_4_1_database_schema_min_8ac4536120.png)_Выделенные жирным шрифтом атрибуты обязательны для минимально жизнеспособной реализации, в то время как другие нужны только для дополнительных, но полезных функций._ #### 4.1.1 Данные, релевантные для аутентификации - **Credential ID:** Это уникальный идентификатор, который генерируется аутентификатором во время регистрации ключа доступа. Он должен использоваться для поиска фактической учетной записи пользователя, связанной с ключом доступа. Кроме того, userHandle (из user_id) следует затем сравнить для проверки учетной записи, используемой для аутентификации. Не используйте атрибут user.name для сравнения, так как он может измениться со временем. - **User ID (user_id):** Уникальный идентификатор, указанный проверяющей стороной для представления учетной записи пользователя в своей системе. Возвращается как userHandle внутри объекта утверждения (assertion). #### 4.1.2 Метаданные для отображения и выбора ключей доступа: - **Отображаемое имя пользователя (user.displayName):** Удобное для пользователя, читаемое имя, которое обычно является полным именем пользователя. Оно отображается пользователю, но не используется во время аутентификации. - **Имя пользователя (user.name):** Уникальное и читаемое имя, которое обычно является адресом электронной почты или логином. Оно может быть показано пользователю, но не используется во время аутентификации. ### 4.2 Идентификатор проверяющей стороны (rpId) **Идентификатор проверяющей стороны (Relying Party ID, rpID)** — это домен, хранящийся внутри ключа доступа, который гарантирует, что ключ доступа работает только для правильного домена (URL-адрес браузера). Во время аутентификации rpID проверяется на соответствие URL-адресу браузера и допускается только в этих двух случаях: 1. URL-адрес точно совпадает с rpId ИЛИ 2. URL-адрес является поддоменом, который соответствует rpId, и родительский домен не находится в Public Suffix List Вот примеры разрешенных и запрещенных комбинаций: ![Примеры разрешенных и запрещенных комбинаций идентификаторов проверяющей стороны (Relying Party ID)](https://www.corbado.com/website-assets/65fc7d099bf36909d7f40495_cs_4_2_rpid_examples_min_55f5750e90.png) ## 5. Полезные веб-сайты и инструменты Вот список полезных инструментов и сайтов для внедрения ключей доступа. - [**Отладчик ключей доступа (Passkeys Debugger):**](https://www.passkeys-debugger.io/) Инструмент для отладки ответов WebAuthn в формате JSON и тестирования операций WebAuthn с различными параметрами. - **Глоссарий по ключам доступа:** Объяснение терминов и концепций, связанных с ключами доступа. - [**Спецификация WebAuthn:**](https://www.w3.org/TR/webauthn-2/) Это официальная спецификация WebAuthn. - [**Chrome Device Log:**](http://chrome://device-log) Инструмент для отображения журнала операций WebAuthn вашего устройства (доступен только в Chrome через `chrome://device-log`). Чтобы узнать о стратегиях оптимизации пользовательского опыта ключей доступа (UX) за рамками технической реализации, ознакомьтесь с нашими руководствами по лучшим практикам создания ключей доступа и лучшим практикам входа по ключам доступа. Если вы хотите внедрить ключи доступа всего несколькими строками кода в любое приложение, вы также можете использовать [Corbado Complete](https://docs.corbado.com/start) (для новых приложений) или [Corbado Connect](https://www.corbado.com/enterprise) (для существующих приложений). ## Часто задаваемые вопросы ### Как реализовать Условный UI (Conditional UI) для автозаполнения ключей доступа в моем веб-приложении? Для использования Условного UI требуется проверка поддержки браузером через `PublicKeyCredential.isConditionalMediationAvailable()` перед началом аутентификации. Поле ввода должно включать HTML-токен `autocomplete="username webauthn"`, а у пользователя должен быть зарегистрирован резидентный ключ (обнаруживаемые учетные данные). Рекомендуется выделить отдельную конечную точку сервера для обработки потока входа через Условный UI. ### Какой минимальный набор данных необходимо хранить в базе данных для поддержки аутентификации WebAuthn? Как минимум, необходимо хранить Credential ID (идентификатор учетных данных), генерируемый аутентификатором во время регистрации, и User ID (user_id), который возвращается в виде `userHandle` в объекте утверждения (assertion). Используйте Credential ID для поиска связанной учетной записи пользователя и сравнивайте `userHandle` для проверки аутентификации. Избегайте использования `user.name` для сравнения, так как оно может измениться со временем. ### В чем разница между резидентными и нерезидентными ключами в WebAuthn? Резидентные ключи (обнаруживаемые учетные данные) хранятся на самом аутентификаторе и извлекаются во время аутентификации; это необходимо для работы Условного UI. Нерезидентные ключи хранят идентификатор учетных данных (credential ID) на сервере и отправляют его аутентификатору во время аутентификации. Поле `residentKey` в `authenticatorSelection` управляет этим поведением с помощью значений "required", "preferred" или "discouraged". ### Как работает проверка пользователя (userVerification) и каковы риски установки значения preferred? Поле `userVerification` контролирует, должен ли аутентификатор проверять пользователя во время входа, принимая значения "required", "preferred" (по умолчанию) или "discouraged". Если установлено значение "preferred", пользователь или его устройство могут полностью пропустить проверку в процессе аутентификации, что потенциально ослабляет безопасность. Установка значения "required" гарантирует, что проверка всегда выполняется до завершения аутентификации.