Как работает вход без пароля под капотом

Вы нажимаете «Войти», телефон запрашивает отпечаток пальца — и вы аутентифицированы. Никакого ввода пароля, никакого копирования кода из письма. Если вы раньше реализовывали потоки аутентификации, это, вероятно, кажется магией — или, что ещё хуже, чёрным ящиком, который вы должны интегрировать, не понимая его устройства.

Эта статья объясняет, как на самом деле работают passkeys и WebAuthn под API браузера. Вы поймёте поток аутентификации, используемые криптографические примитивы и свойства безопасности, которые делают аутентификацию без пароля на основе FIDO2 принципиально отличной от старых подходов вроде magic links или OTP.

Почему passkeys заменили более ранние методы входа «без пароля»

Magic links и одноразовые пароли убрали поле пароля из форм входа, но они не устранили общие секреты. Magic link — это всё ещё bearer-токен, передаваемый через email, — его можно перехватить, воспроизвести и использовать для фишинга, если пользователи переходят по ссылкам на поддельных доменах. OTP, отправленные через SMS, уязвимы для атак с подменой SIM-карты.

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

Это ключевая идея FIDO2 и WebAuthn: аутентификация происходит через криптографическое доказательство владения, а не через передачу секретов.

Поток аутентификации WebAuthn

Когда пользователь аутентифицируется с помощью passkey, обычно взаимодействуют четыре компонента: ваш фронтенд-код, WebAuthn API браузера, аутентификатор (часто это связка ключей ОС, телефон или аппаратный ключ безопасности) и ваш сервер.

Регистрация: создание учётных данных

Во время регистрации ваш сервер генерирует challenge — случайную последовательность байтов — и отправляет её в браузер вместе с вашим relying party ID (обычно это ваш домен). Ваш фронтенд вызывает navigator.credentials.create() с этими параметрами.

Браузер передаёт этот запрос аутентификатору через CTAP (Client to Authenticator Protocol). Аутентификатор генерирует новую пару ключей, безопасно сохраняет приватный ключ и возвращает публичный ключ вместе с подписанной аттестацией.

Ваш сервер получает и сохраняет публичный ключ, credential ID и метаданные, такие как счётчик подписей. Никакого хеша пароля, никакого общего секрета — только публичный ключ, привязанный к вашему домену.

Аутентификация: доказательство владения

Когда пользователь возвращается, ваш сервер генерирует новый challenge. Ваш фронтенд вызывает navigator.credentials.get(), и браузер обращается к аутентификатору.

Аутентификатор находит учётные данные, соответствующие вашему RP ID, требует верификацию пользователя (биометрия, PIN или подтверждение присутствия), затем подписывает challenge приватным ключом. Эта подпись вместе с данными аутентификатора возвращается на ваш сервер.

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

Привязка к источнику: механизм защиты от фишинга

Вот что делает passkeys действительно устойчивыми к фишингу, а не просто «сложнее поддающимися фишингу». Аутентификатор криптографически привязывает учётные данные к источнику relying party.

При подписании challenge аутентификатор включает хеш relying party ID (полученный из вашего домена) в подписанные данные. Если злоумышленник создаст похожий сайт на g00gle.com, учётные данные для google.com просто не будут работать — источники не совпадают, и аутентификатор не создаст действительную подпись.

Это не предупреждение в интерфейсе, которое пользователи могут проигнорировать. Это криптографически обеспечивается на уровне протокола.

Синхронизируемые и привязанные к устройству passkeys

Современные passkeys обычно синхронизируются между устройствами через связки ключей ОС — iCloud Keychain от Apple, Google Password Manager или сторонние менеджеры вроде 1Password. Это значительно улучшает удобство использования, так как пользователи не теряют доступ при смене телефона.

Привязанные к устройству passkeys (например, аппаратные ключи безопасности) предлагают более строгие гарантии — приватный ключ доказуемо существует ровно на одном устройстве. Для большинства веб-приложений синхронизируемые passkeys обеспечивают достаточную безопасность с лучшим UX. Ваша модель угроз определяет, что важнее.

Современные паттерны UX: Conditional UI

Вы, вероятно, видели, как подсказки passkey появляются в предложениях автозаполнения поля имени пользователя. Это conditional UI — браузер проактивно предлагает доступные passkeys до того, как пользователь явно запросит вход без пароля.

Реализуйте это, вызвав navigator.credentials.get() с mediation: 'conditional' и добавив autocomplete="username" к вашему полю ввода.

Браузер обрабатывает обнаружение и представление.

Многие приложения теперь используют conditional UI для обновления существующих пользователей: после успешного входа с паролем предлагают пользователям зарегистрировать passkey для будущих сессий.

Свойства безопасности и границы доверия

Passkeys значительно уменьшают поверхность атаки, но они не волшебство. Безопасность приватного ключа зависит от реализации аутентификатора — обычно это secure enclave устройства или TPM. Если само устройство скомпрометировано на аппаратном уровне, все гарантии теряются.

Восстановление аккаунта остаётся проблемой проектирования. Когда пользователи теряют все свои устройства, вам нужны резервные механизмы, которые не возвращают уязвимости, устранённые passkeys.

WebAuthn продолжает развиваться — Level 3 является текущим поколением спецификации — с продолжающейся работой над аутентификацией между устройствами и корпоративной аттестацией. Основы, рассмотренные здесь, остаются стабильными.

Заключение

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

Для фронтенд-разработчиков практический вывод прост: изучите церемонии регистрации и аутентификации WebAuthn API, реализуйте conditional UI для бесшовного обнаружения и спроектируйте пути обновления, которые постепенно переводят пользователей с паролей на passkeys.

Часто задаваемые вопросы

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.