Чем ключ доступа отличается от пароля и одноразового кода

Пароль — общий секрет. Его знают пользователь и сервер (в идеале — только хеш на сервере). Его можно выманить формой на похожем домене, подсмотреть, вытащить из утечки, подобрать. Одноразовый код из SMS или приложения улучшает второй фактор, но код тоже можно перехватить или уговорить отдать. Оба механизма опираются на то, что человек передаёт секрет каналом, который атакующий умеет имитировать.

Ключ доступа строится на паре ключей. Закрытый ключ не покидает аутентификатор: Secure Enclave, TPM, модуль телефона, аппаратный ключ. Открытый ключ лежит у вас в базе. При входе сервер выдаёт одноразовый challenge. Аутентификатор подписывает его только для вашего сайта (точнее — для зарегистрированного идентификатора доверия) и только после локального подтверждения пользователя. Подпись нельзя «ввести» на поддельной странице: браузер не отдаст учётные данные чужому origin.

Практический смысл для продукта:

«Высокая устойчивость к фишингу» не значит «невозможно отобрать аккаунт». Украденный ноутбук с разблокированной сессией, социальная инженерия службы поддержки, слабое восстановление — всё это остаётся. Но классический сценарий «форма на evil-login.example» перестаёт работать так, как с паролем.

Словарь, без которого спецификация читается как шум

WebAuthn — веб-API (navigator.credentials.create / get) и модель проверки на сервере. Это язык браузера.

FIDO2 / CTAP — как аутентификатор общается с платформой. Вам редко нужно трогать CTAP руками, если вы пишете обычный сайт.

Relying Party (RP) — ваш сервис. У него есть rpId: обычно домен без схемы и порта, например example.com. Ключ, созданный для example.com, не сработает на evil.com.

Authenticator — то, что хранит закрытый ключ: платформа (телефон, ноутбук) или внешний ключ (USB/NFC/BLE).

Credential — конкретная пара: credentialId + открытый ключ + счётчик/флаги + привязка к пользователю.

Discoverable credential (resident key) — учётные данные, которые аутентификатор может предложить без предварительного ввода логина. На этом стоит «войти с ключом доступа» одной кнопкой и Conditional UI.

User verification (UV) — локальная проверка человека: биометрия или PIN. Флаг в ответе показывает, была ли она.

Attestation — доказательство модели аутентификатора. В потребительских продуктах её часто не требуют: достаточно проверки подписи. В корпоративных сценариях attestation иногда нужна для белого списка устройств.

Синхронизированный passkey — закрытый ключ копируется экосистемой (iCloud Keychain, Google Password Manager, менеджер паролей). Удобно при смене телефона.

Device-bound passkey — закрытый ключ не уезжает с железа. Строже для регулируемых контуров, больнее при поломке устройства.

Две церемонии: регистрация и вход

Регистрация

1. Пользователь уже как-то доказал, что это его аккаунт (сессия после пароля, письмо, приглашение).
2. Сервер генерирует случайный challenge (≥16 байт), сохраняет его у себя с коротким TTL и отдаёт PublicKeyCredentialCreationOptions: rp, user, challenge, pubKeyCredParams, authenticatorSelection, attestation.
3. Браузер вызывает navigator.credentials.create({ publicKey: options }).
4. Пользователь подтверждает на устройстве.
5. Клиент возвращает объект аттестации / credentials. Сервер проверяет challenge, origin, rpId, флаги, сохраняет credentialId, открытый ключ, transports, счётчик.
6. Challenge удаляют — и при успехе, и при ошибке. Повторное использование того же challenge запрещено.

Вход

1. Сервер снова выдаёт свежий challenge и PublicKeyCredentialRequestOptions. Для discoverable credentials поле allowCredentials может быть пустым массивом — аутентификатор сам предложит подходящие ключи.
2. Браузер вызывает navigator.credentials.get.
3. Пользователь подтверждает.
4. Сервер находит credential по id, проверяет подпись challenge, origin, rpId, флаги UP/UV, при необходимости счётчик, затем создаёт сессию приложения.
5. Challenge снова одноразовый.

На Node.js и в других стеках не собирайте проверку «с нуля из MDN». Берите поддерживаемую FIDO-библиотеку (@simplewebauthn/server и аналоги). Спецификация длинная, углы острые, обновления приходят пакетом. Библиотека не снимает с вас обязанности правильно задать rpId и origin — она снимает риск неправильно разобрать CBOR.

Что обязан сделать сервер (и что нельзя доверить клиенту)

Клиент может прислать что угодно. Доверять можно только тому, что вы перепроверили.

Минимальный контур проверки на входе:

1. Challenge существует, не истёк, не использован, привязан к этой попытке.
2. origin ответа совпадает с ожидаемым (https://app.example.com), без «похожих» доменов.
3. rpId совпадает с тем, под которым регистрировали.
4. Credential известен и принадлежит пользователю (или вы явно поддерживаете вход без логина и ищете по credentialId глобально — тогда особенно важны лимит частоты и антиперебор).
5. Подпись верна для сохранённого открытого ключа.
6. Флаг присутствия пользователя (UP) включён. Если вы требовали userVerification: "required", флаг UV тоже должен быть истинным. Уровень UV, который вы запросили, храните в серверной записи попытки, а не читайте с клиента.
7. Счётчик подписей (signCount), если аутентификатор его ведёт: новое значение не должно быть меньше предыдущего. Падение счётчика — сигнал клонирования ключа; политика обычно — насторожить или отозвать credential.

Отдельно: не принимайте alg: none и самодельные «упрощения» вокруг JWT сюда не тащите. После WebAuthn вы создаёте сессию. Как именно вы подпишете токен доступа — уже история из разбора JWT. Путать «доказали passkey» и «выдали вечный JWT в localStorage» — частая короткая дорога к инциденту.

Синхронизированные и привязанные ключи: продуктовый выбор

Синхронизированный ключ переживает смену телефона внутри экосистемы. Для потребительского SaaS это обычно правильное значение по умолчанию: меньше тикетов «не могу войти с нового iPhone». Цена — доверие к облаку вендора и к тому, что аккаунт Apple/Google тоже защищён.

Ключ, привязанный к устройству, не уезжает. Его любят корпоративные политики, регулируемые контуры, админские панели, где «этот YubiKey» важнее удобства. Цена — обязательный второй фактор восстановления и обучение людей не терять единственный токен.

На практике зрелые раскатки часто смешивают оба типа: synced для обычных пользователей, Device-bound для привилегированных ролей. Это совпадает с отраслевыми опросами 2026 года: половина организаций, которые внедряют ключи, не ставит на один-единственный тип.

authenticatorSelection и требования resident key задают тонкость поведения. Для «кнопки войти без логина» нужны discoverable credentials. Для сценария «сначала логин, потом подтверждаем известные ключи» можно передавать allowCredentials со списком id. Conditional UI (автозаполнение поля логина ключами) опирается на discoverable credentials и поддержку браузера — проверяйте возможности через PublicKeyCredential.getClientCapabilities, где она есть.

Восстановление: место, где умирают «идеальные» внедрения

Самый частый провал продукта: включили passkeys, отключили пароль, не продумали потерю телефона. Пользователь уезжает в отпуск без запасного входа — и поддержка заводит «временный пароль» вручную, открывая дыру шире, чем была.

Рабочие стратегии (их можно комбинировать):

1. Несколько ключей на аккаунт. Второй телефон, аппаратный ключ, ключ на рабочем ноутбуке. Интерфейс должен просить добавить запасной, а не прятать это в настройках.
2. Восстановление через уже доказанный канал. Письмо на подтверждённый адрес с одноразовой ссылкой, которая позволяет только зарегистрировать новый ключ, а не получить полную сессию без ограничений.
3. Аппаратный восстановление-код (набор одноразовых строк), показанный один раз при включении безпарольного режима. Хранить хеши, как пароли. rate limit жёсткий.
4. Сохранённый пароль как временный запасной путь на переходный период — с явным планом выключить и с антифишинговыми сигналами (не просить пароль на каждой странице).
5. Поддержка с ритуалом. Видеозвонок, проверка документов, задержка выдачи — дорого, но для банков и админок иногда неизбежно. Главное: поддержка не должна иметь кнопку «сбросить на пароль qwerty».

Отдельно про Signal API в новых браузерах: сервер может подсказывать аутентификатору, что credential неизвестен или что список принятых ключей изменился. Это синхронизация UX («не предлагай удалённый ключ»), а не замена вашей базы. Если браузер API не поддерживает — деградируйте мягко.

Миграция с пароля: как не устроить себе второй инцидент

Резко выключить пароли почти никто не может. Типичная лестница:

1. Добавить ключ доступа рядом с паролем. После обычного входа — мягкий запрос «создать ключ на этом устройстве».
2. Сделать ключ предпочтительным. На экране входа сверху — passkey / Conditional UI, пароль — ссылкой «другой способ».
3. Сузить пароль. Запретить пароль для админов. Требовать ключ для чувствительных действий (смена почты, вывод средств) даже если сессия уже есть — повторной проверки.
4. Выключить пароль для сегментов, где метрики показывают устойчивость: есть ≥2 ключа, есть восстановление, поддержка обучена.

Не смешивайте «обязательный passkey» с «мы удалили все остальные факторы» в один релиз. И не храните пароль «на всякий случай» в открытом виде в тикетах поддержки.

Для корпоративного SSO картина другая: часто ключ доступа живёт у провайдера личности (Google, Microsoft, Okta), а ваше приложение продолжает принимать OIDC. Тогда ваш код WebAuthn может вообще не понадобиться — но вам всё равно нужны повторной проверки и понимание, Device-bound ли ключ у IdP. Перекладывание на IdP не отменяет угрозы плохого восстановления у провайдера.

Клиентский контур на TypeScript (эскиз)

Ниже — не копипаста «вставьте в прод», а каркас ответственности. Опции всегда приходят с сервера.

// registration
const options = await fetch('/auth/webauthn/register/options', {
  method: 'POST',
  credentials: 'include',
}).then((r) => r.json())

const credential = await navigator.credentials.create({
  publicKey: PublicKeyCredential.parseCreationOptionsFromJSON
    ? PublicKeyCredential.parseCreationOptionsFromJSON(options)
    : options,
})

await fetch('/auth/webauthn/register/verify', {
  method: 'POST',
  credentials: 'include',
  headers: { 'content-type': 'application/json' },
  body: JSON.stringify(credential),
})

// authentication (discoverable)
const options = await fetch('/auth/webauthn/login/options', {
  method: 'POST',
  credentials: 'include',
}).then((r) => r.json())

const assertion = await navigator.credentials.get({
  publicKey: {
    ...options,
    allowCredentials: [], // discoverable
  },
  mediation: 'optional', // Conditional UI where supported
})

await fetch('/auth/webauthn/login/verify', {
  method: 'POST',
  credentials: 'include',
  headers: { 'content-type': 'application/json' },
  body: JSON.stringify(assertion),
})

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

Типичные ошибки в продакшене

1. Неверный rpId. Зарегистрировали на www.example.com, проверяете на example.com — или наоборот. Ключи «внезапно» не находятся.
2. Challenge в памяти одной ноды без привязки сессии. Пользователь получил параметры с инстанса A, а verify пришёл на B. Нужно общее хранилище (Redis и т.п.) с TTL.
3. Challenge без TTL и без одноразовости. Повторная проигрываемость — подарок для атак.
4. Доверие к userVerification с клиента. Храните требуемый уровень на сервере в записи попытки.
5. Один ключ на аккаунт и пароль выключен. Потеря устройства = потеря клиента.
6. Passkey «успешен», сессия вечная в localStorage. Вернитесь к короткому токену доступа и ротации refresh.
7. Игнор счётчика там, где аутентификатор его отдаёт. Клон ключа останется незамеченным.
8. Смешение стенда и продакшена rpId. Ключи с локального localhost не переносятся — и не должны. Для локальной разработки настройте отдельный контур, не «временно отключим проверку origin».
9. Слабый лимит частоты на входе без логина. Перебор credentialId / шум по challenge должен упираться в лимиты и мониторинг.
10. Attestation: required без причины. Ломаете пользовательские менеджеры ключей и синхронизацию ради галочки, которую не проверяете политикой.

Как тестировать

Ручной сценарий минимум:

1. Зарегистрировать ключ в чистом профиле браузера.
2. Выйти, войти только ключом.
3. Отозвать ключ в UI, убедиться, что вход им больше не проходит и Signal (если есть) не предлагает его.
4. Добавить второй ключ, удалить первый — вход жив.
5. Прогнать просроченный challenge и повторно использованный challenge — оба должны получить отказ.
6. Повторить на втором браузере / телефоне для synced-сценария.
7. Для Device-bound — убедиться, что ключ не появился на втором устройстве.

Автоматизация возможна через виртуальные аутентификаторы в Chrome DevTools Protocol и Playwright. Это не заменяет проверку на реальном телефоне, но ловит регрессии options/verify. Отдельно гоняйте мульти-инстанс verify: параметры на одной ноде, проверка на другой.

Где ключи доступа особенно уместны

• Потребительские кабинеты с частым входом с телефона.
• Админки и внутренние панели (часто Device-bound + аппаратный ключ).
• Повторная проверка перед деньгами, сменой почты, выгрузкой данных.
• Полевые приложения, где пароль на чужой клавиатуре — отдельный риск; здесь же смотрите связку с записью в режиме offline-first — сессия и локальная очередь ортогональны, но UX входа общий.

Где осторожнее: аудитории без смартфонов, киоски, общие компьютеры библиотек, регионы с жёстко ограниченными экосистемами. Там passkeys — дополнение, не единственная дверь.

Частые вопросы

Что почитать дальше

Соседние материалы по безопасности и клиентскому контуру: JWT в Node.js, укрепление npm-цепочки, запись в режиме offline-first, карта React-стека, элемент install для PWA. Внешние опоры: гиды Google по серверным ключам доступа и материалы альянса FIDO на сайте каталога библиотек.

Заключение

Passkeys переносят секрет с «строки, которую человек носит в голове и вводит в формы» на «закрытый ключ, который не покидает аутентификатор». WebAuthn — это церемония браузера плюс скучная, обязательная проверка на сервере. Продуктовая зрелость начинается там, где заканчивается демо: второй ключ, восстановление, правильный rpId, одноразовый challenge, честная миграция с пароля и сессия после входа без вечного токена в localStorage.

Если строить одним предложением: сначала докажите личность подписью, потом выдайте короткую сессию, всегда оставьте путь назад без унижения поддержки. Это скучнее рекламных роликов про «мир без паролей», зато переживает первый потерянный телефон.

Четыре вопроса к вашему контуру. Где лежит закрытый ключ? На аутентификаторе, не у вас. Что вы проверяете на verify? Challenge, origin, rpId, подпись, флаги. Что будет, если ключ один и телефон утонул? Заранее написанное восстановление. Что получает браузер после успеха? Сессия с конечным сроком, а не новый «вечный пароль» в другом формате.