Passkeys и WebAuthn: путь входа в браузере
Проследите путь passkey от регистрации до входа, узнайте, что проверяют браузер и сервер, и спланируйте переносимость, восстановление и доступные альтернативы.
Нужна структурированная документация по теме Идентичность?
Эта статья относится к редакционной библиотеке. Для пошаговой настройки, справки и постоянных обновлений переходите сразу в соответствующий раздел docs.
Вход с passkey представляет собой поток аутентификации с открытым ключом, который координируют сайт, браузер, аутентификатор и сервер. При регистрации аутентификатор создаёт учётные данные, привязанные к доверяющей стороне, а сервер сохраняет открытый ключ. При входе сервер выдаёт новый вызов, браузер просит доступный аутентификатор использовать соответствующий закрытый ключ, а сервер проверяет подписанный ответ перед созданием сеанса. Браузер помогает координировать выбор пользователя и границы безопасности, но не решает, разрешён ли доступ к учётной записи.
Спецификация Web Authentication W3C определяет операции с учётными данными и модель данных браузера. В руководстве MDN по Web Authentication описаны интерфейсы JavaScript, а обзор passkeys от FIDO Alliance рассказывает об использовании на устройствах и в менеджерах учётных данных. Эти источники помогают отделить способ подтвердить владение учётными данными для сайта от переносимого документа личности или гарантии, что любое устройство сможет предъявить те же данные.
Что Passkey Значит Для Браузера
Passkey представляет собой обнаруживаемые учётные данные WebAuthn. Используется пара ключей: закрытый ключ остаётся в аутентификаторе или менеджере учётных данных, а доверяющая сторона хранит связанный открытый ключ и идентификатор учётных данных. Интерфейс WebAuthn позволяет сайту запросить создание или использование учётных данных через navigator.credentials.create() и navigator.credentials.get(). Браузер и аутентификатор проводят пользовательскую церемонию, но сайт всё равно должен проверить результат и принять решение по учётной записи.
Доверяющая сторона (RP, relying party) представляет собой сайт или служба, которая просит аутентифицировать пользователя. Её origin и RP ID задают область действия учётных данных WebAuthn. Сайт не может просто попросить браузер использовать их для постороннего origin. WebAuthn предназначен для безопасных контекстов. Браузеры делают исключение для localhost при разработке. Для встроенных фреймов и фреймов с другим origin действуют дополнительные ограничения политик. Им не предоставляется неограниченный доступ лишь потому, что он есть у верхней страницы.
Слово «passkey» описывает пользовательский сценарий, а не единый способ хранения. Поставщик может синхронизировать учётные данные между устройствами одной учётной записи, оставить их на одном устройстве или ключе безопасности либо поддерживать церемонию между устройствами. У этих вариантов различаются доступность и восстановление. Наличие API, платформенного аутентификатора или возвращённых браузером учётных данных не устанавливает юридическую личность человека, не доказывает, кто коснулся общего устройства, и не показывает, существует ли учётная запись на конкретном сайте.
Важно также различать присутствие пользователя и его проверку. Присутствие означает, что аутентификатор заметил взаимодействие, проверка означает, что он выполнил локальную проверку, например PIN-кодом, кодом устройства или биометрией. Доверяющая сторона может запросить предпочтительный способ проверки и должна сопоставить возвращённые признаки со своей политикой. При обычной аутентификации WebAuthn сервер не получает биометрический шаблон. Он получает данные протокола, по которым можно проверить подпись и свойства учётных данных.
Сайтам следует описывать результат по этапам. «Passkey доступна» не означает «passkey зарегистрирована»; «учётные данные получены» не означает «учётная запись аутентифицирована»; а «подпись действительна» не означает «пользователь может выполнить любое действие». Такое разделение не позволяет интерфейсу преувеличить результат и упрощает диагностику. О конфиденциальности сигналов возможностей браузера рассказывает руководство по WebAuthn fingerprinting; эта статья посвящена регистрации, входу и восстановлению. В общем руководстве по входу через Credential Management рассматриваются пароли и федеративные учётные данные, опосредованные браузером, а не детали протокола WebAuthn.
Регистрация Учётных Данных Без Лишних Обещаний
Регистрация начинается с явного действия пользователя, например выбора «Создать passkey» в настройках безопасности учётной записи. Сервер создаёт короткоживущий вызов регистрации и возвращает браузеру необходимые параметры: вызов, RP ID и отображаемое имя, идентификатор пользователя, допустимые алгоритмы открытых ключей, предпочтения аутентификатора и существующие учётные данные, которые нужно исключить. Поскольку passkey должна обнаруживаться, запрос должен требовать обнаруживаемые учётные данные, например задавать authenticatorSelection.residentKey: "required". Нельзя незаметно принять необнаруживаемые данные и назвать их passkey. Сервер отвечает за вызов и связь с учётной записью. Клиент не должен незаметно придумывать или повторно использовать состояние регистрации.
Страница передаёт параметры в navigator.credentials.create({ publicKey }). Браузер проверяет, позволяют ли контекст, политика и доступные аутентификаторы выполнить запрос, после чего показывает собственный интерфейс. Пользователь может выбрать устройство или менеджер учётных данных, разблокировать его и подтвердить действие. При residentKey: "required" регистрация должна создать обнаруживаемые учётные данные либо завершиться ошибкой. Неспособность платформы выполнить запрос не оправдывает его незаметное ослабление. Пользователь может отменить запрос, выбрать другой способ или столкнуться с ограничением платформы. Страница должна считать все эти исходы обычными и сохранять задачу настройки учётной записи.
При успешной церемонии браузер возвращает ответ с данными клиента и объектом аттестации. Веб-приложение отправляет ответ серверу вместе с состоянием, которое связывает его с ожидающей регистрацией. Сервер проверяет совпадение и срок действия вызова, допустимость origin, ожидаемое значение хеша RP ID, тип ответа и формат данных учётных данных. Он также проверяет возможность связать их с нужной учётной записью и то, что политика регистрации требовала обнаруживаемые данные, если поддерживаемый ответ раскрывает свойства учётных данных, сервер подтверждает это перед регистрацией passkey. Аттестацию он валидирует только в объёме, требуемом документированной политикой.
Аттестация может раскрыть сведения о происхождении аутентификатора. Сайт не должен запрашивать или хранить больше данных аттестации, чем оправдывают его модель угроз и уведомление пользователей. Многие потребительские службы могут принимать широкий набор аутентификаторов, не определяя их модели. Более строгая политика может исключить добросовестных пользователей, создать дополнительные обязанности по работе с данными и устареть по мере изменения платформ. Если организации действительно требуется особый уровень гарантий, его нужно объяснить до регистрации и проверить сценарий на поддерживаемых устройствах.
После проверки сервер хранит идентификатор учётных данных, открытый ключ, связь с учётной записью и только те метаданные, которые нужны для дальнейшей проверки и управления. Закрытый ключ хранить не следует: WebAuthn не возвращает его сайту. Счётчик может присутствовать, но его поведение различается у аутентификаторов и синхронизируемых учётных данных, поэтому не считайте простое увеличение значения универсальным признаком кражи. Прежде чем применять проверки риска, учитывайте актуальную спецификацию и документированную семантику аутентификатора.
Страница должна сообщить о добавлении passkey только после подтверждения обнаруживаемых учётных данных в соответствии с политикой регистрации. Если приложение не может подтвердить это свойство, результат нельзя называть passkey, объясните недоступность этого способа и предложите понятную поддерживаемую альтернативу. Покажите понятное имя, например «Это устройство» или выбранную пользователем метку, дату добавления при необходимости и возможность удалить или переименовать запись. Не назначайте метку по выведенным из контекста сведениям об оборудовании или личности. В настройках безопасности поясните, что удаление записи у сайта может не удалить копию, которой управляет поставщик в экосистеме устройства. Возможно, пользователю придётся отдельно управлять ей у поставщика.
Аутентификация С Новым Вызовом
Вход сохраняет то же разделение обязанностей. Пользователь выбирает вход с passkey, а сервер формирует новый непредсказуемый вызов с ограниченным сроком действия. Он также определяет допустимый RP ID, политику учётных данных, требование проверки пользователя и контекст учётной записи или транзакции, который нужно связать с церемонией. В сценарии с предварительным вводом имени пользователя сервер может ограничить список идентификаторов теми, что связаны с этой учётной записью. В сценарии без имени пользователя, где обнаруживаются учётные данные, аутентификатор может вернуть их и user handle, сервер должен определить учётную запись по явной политике.
Страница вызывает navigator.credentials.get({ publicKey }). Если это допускают платформа и правила посредничества, браузер может показать выбор учётной записи или интерфейс автозаполнения passkey. Пользователь выбирает или разблокирует аутентификатор, который подписывает данные протокола, связанные с вызовом и доверяющей стороной. При входе с другого устройства можно выбрать телефон или иной аутентификатор через опосредованную церемонию в браузере на отдельном устройстве. Детали зависят от браузера, операционной системы, поставщика учётных данных и доступного транспорта. Приложение не должно обещать одинаковый запрос или транспорт на всех платформах.
Ответ-аутентификатор содержит данные клиента, данные аутентификатора, идентификатор учётных данных и подпись. Сервер проверяет, что это выданный им вызов, что срок не истёк и что вызов ещё не использовали. Он проверяет тип данных клиента, допустимый origin, хеш RP ID, связь учётных данных с учётной записью, подпись по сохранённому открытому ключу и состояние проверки пользователя, если того требует политика. Затем он проверяет состояние учётной записи, права, ограничения частоты и риски до создания сеанса. Действительная подпись является частью решения, а не сам сеанс.
За жизненным циклом вызова нужно следить. Создавайте его криптографически стойким генератором, связывайте с нужным входом или чувствительным действием, задавайте короткий срок действия и запрещайте повторное использование. Не помещайте вызов в URL, аналитику или журналы поддержки. Используйте обычный защищённый транспорт приложения и серверные механизмы сеансов. Если проверка не удалась, нельзя доверять имени пользователя, метке учётных данных или флагу «успех», присланному браузером.
Не путайте детали реализации с личностью. Идентификатор учётных данных относится к учётной записи конкретной доверяющей стороны, а не является глобальной личностью. User handle должен быть непрозрачным и ограниченным службой. Подсказка о транспорте может помочь браузеру выбрать способ соединения, но не доказывает близость аутентификатора или принадлежность устройства названному человеку. Выбор учётной записи и авторизация должны основываться на серверных записях, а не на названиях устройств и возможностях браузера.
Спланировать Перенос И Восстановление
Некоторые passkeys синхронизируются поставщиком учётных данных между устройствами пользователя. Поставщики могут применять сквозное шифрование и защиту восстановления учётной записи, но поведение, доступность и настройка зависят от них. Сайт не должен гарантировать, что passkey, созданная на одном телефоне, немедленно появится на другом, что любой поставщик совместим с любой платформой или что служба синхронизации всегда доступна. Для восстановления учётной записи или синхронизации направляйте пользователей к актуальной документации поставщика, не пытаясь исследовать или чинить его закрытое состояние.
Другие учётные данные привязаны к устройству, например к ключу безопасности или аутентификатору, закрытый ключ которого не синхронизируется. Они могут быть надёжным вторым фактором или управляемым организацией вариантом, но при потере или поломке устройства доверяющей стороне нужен отдельный путь восстановления. Вход между устройствами. Другой сценарий: пользователь применяет находящееся рядом устройство с passkey, чтобы завершить вход, начатый в другом месте. QR-код или обмен данными о близости помогают провести церемонию, но сами по себе не доказывают, что пользователь прошёл серверную проверку. Не объединяйте синхронизацию, резервирование и вход между устройствами обещанием «работает везде».
Восстановление учётной записи и восстановление у поставщика учётных данных являются разными задачами. Восстановление у поставщика возвращает доступ к менеджеру или его зашифрованному набору учётных данных. Восстановление у доверяющей стороны возвращает доступ к сервису, когда зарегистрированную passkey использовать нельзя. Обычно сайт не может восстановить потерянную учётную запись поставщика или извлечь отсутствующий закрытый ключ. Политика сайта может предусматривать другую passkey, зарегистрированный ключ безопасности, коды восстановления, одобренную проверку личности или продуманную процедуру поддержки. Уровень гарантий каждого способа должен соответствовать ценности учётной записи и восстанавливаемому действию.
Предлагайте восстановление во время регистрации, а не только после блокировки пользователя. Рекомендуйте подходящие дополнительные учётные данные или способ восстановления и поясняйте, где они хранятся. Для важных учётных записей требуйте более строгую проверку перед заменой всех аутентификаторов, изменением контактов восстановления или отключением действующего способа. Если политика позволяет, оставляйте старые записи активными до подтверждения замены и ясно уведомляйте пользователя о важных изменениях безопасности. Специалист поддержки не должен обходить те же проверки учётной записи лишь потому, что звонящий знает открытые сведения профиля.
Страницы восстановления также должны препятствовать перечислению учётных записей. Публичный ответ при входе или восстановлении не должен раскрывать, есть ли passkey у заданного адреса почты или имени пользователя. По возможности используйте похожие сообщения и время ответа, а действия для конкретной учётной записи выполняйте только после надлежащей проверки. Не записывайте ответы passkey или секреты восстановления в аналитику, обращения в поддержку, снимки экрана или текст ошибок. Храните минимальную и проверяемую запись об этапе процесса и его результате.
Сделать Запросы, Отмену И Альтернативы Доступными
Браузер или операционная система управляет большей частью окна аутентификатора, но сайт отвечает за окружающий сценарий. Простыми словами объясните, что такое passkey, прежде чем открыть окно. Назовите учётную запись и действие, предупредите, что браузер может попросить выбрать или разблокировать учётные данные, и оставьте видимую альтернативу. Не запускайте запрос учётных данных только из-за загрузки страницы или невидимого таймера. Понятная кнопка и действие пользователя объясняют намерение человеку и платформе.
Считайте отмену решением пользователя. Если запрос отклонён или завершился без пригодных учётных данных, оставьте пользователя на странице входа, сохраните безопасные для хранения данные и верните фокус к полезному элементу. Не открывайте окно немедленно снова, не повторяйте настойчивые запросы и не сообщайте, что учётной записи нет. Различайте отмену, сетевой сбой и отказ сервера только тогда, когда приложение может сделать это надёжно. Общее сообщение с защитой конфиденциальности лучше раскрытия внутреннего состояния учётных данных или аккаунта.
Доступный сценарий работает с клавиатурой, экранным диктором, масштабированием и переведённым интерфейсом. Используйте настоящую кнопку с понятным доступным названием действия. Сообщайте об изменениях состояния, не перемещая фокус неожиданно. Для диалогов и выбора учётной записи задайте логичный порядок фокуса и явное закрытие. Не создавайте впечатление, что passkey требует отпечаток пальца: платформа может использовать PIN, код устройства, взаимодействие с ключом безопасности или другой поддерживаемый локальный способ проверки. Добавьте инструкции для пользователей, которым недоступен основной биометрический ввод устройства.
Альтернатива должна быть предусмотренной частью продукта, а не случайным ухудшением сценария. В зависимости от службы это может быть другая зарегистрированная passkey, ключ безопасности, пароль с многофакторной проверкой или восстановление учётной записи. Применяйте одинаковые серверные правила авторизации после каждого способа и защищайте альтернативы от перебора и фишинга. Не переключайте пользователя на другую учётную запись без предупреждения после выбора passkey и не удаляйте несохранённую работу при смене метода. Альтернативный способ может быть менее удобным, но должен оставаться понятным, защищённым и доступным людям с инвалидностью.
Операционные журналы могут содержать общие этапы: параметры выданы, церемония отменена, assertion получен, сервер отклонил проверку, сеанс создан. Не записывайте вызов, ответ учётных данных, подпись, личные данные, весь client data или необработанный user handle. Это даёт полезные сведения о надёжности, не превращая телеметрию входа в сбор учётных данных. Перед выпуском проверьте срок хранения, управление доступом и возможность связать показатель с конкретным человеком.
Сохранить Приватность И Роль Серверной Политики
Привязка WebAuthn к origin и RP ID помогает не допустить использования учётных данных, созданных для одной доверяющей стороны, как принадлежащих другой. Но она не делает любую систему аутентификации безопасной автоматически. Серверу всё равно нужны правильная работа с вызовами, список допустимых origin, защищённые cookies сеанса, проверки прав, ограничения частоты, правила восстановления и мониторинг. Кража активного сеанса отличается от кражи закрытого ключа passkey, поэтому защита аккаунта должна охватывать и срок жизни учётных данных, и сеанс после входа.
Сведите к минимуму сигналы, собираемые во время церемонии. Не создавайте отпечаток моделей аутентификатора, не сохраняйте доступность API как идентичность устройства, не выводите имя человека из выбора учётной записи и не стройте межсайтовый профиль по подсказкам транспорта. Проверки возможностей браузера полезны, чтобы решить, показывать ли действие в текущем взаимодействии. Они не дают оснований для обнаружения учётных записей, оценки права доступа или утверждений о владельце устройства. Запрашивайте только необходимые параметры протокола и объясняйте более строгую политику аутентификаторов до того, как пользователь с ней столкнётся.
Командам разработки следует проверить весь сценарий на реально поддерживаемых сочетаниях браузеров и операционных систем: регистрация, успешный вход, отсутствующие данные или отказ, истёкший вызов, неверный origin, отказ сервера, второе устройство, удаление учётных данных и восстановление. Проверяйте также управление с клавиатуры и экранным диктором, а не только касания. Сведения о совместимости меняются. Перед обещаниями смотрите актуальные документы WebAuthn и таблицы поддержки браузеров. Успешная демонстрация на одном устройстве подтверждает только этот конкретный путь, не универсальное поведение.
BotBrowser позволяет командам проверять собственный интерфейс регистрации и входа с passkey на повторяемых профилях браузера в поддерживаемых хостовых операционных системах. BotBrowser не контролирует напрямую посредничество браузера, аутентификаторы операционной системы, локальные биометрические проверки или решения сервера доверяющей стороны. Он также не создаёт, не хранит, не синхронизирует, не восстанавливает и не аутентифицирует passkeys. Используйте его для сравнения авторизованного потока приложения, считая браузер, поставщика аутентификатора и серверную часть отдельными владельцами результата.
Практический контракт прост: пользователь сам начинает процесс. Браузер и аутентификатор проводят церемонию в области действия доверяющей стороны. Сервер проверяет подписанный ответ и решает, создавать ли сеанс. Служба предоставляет доступные альтернативы и восстановление. Когда у каждого уровня есть чёткая ответственность, passkey упрощает вход без обещаний переносимости, личности, приватности или восстановления, которые система не может выполнить.
Открытые источники
Похожие статьи
Переведите BotBrowser из исследований в продакшн
Используйте эти руководства, чтобы понять модель, а затем перейти к кроссплатформенной валидации, изолированным контекстам и масштабируемому браузерному развертыванию.