Резервные варианты и восстановление ключей доступа: подход Identifier-First

1. Введение#

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

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

Ключевые вопросы:

• Какие сценарии резервного входа существуют? Каковы потенциальные сценарии резервного входа, которые могут возникнуть в системах с ключами доступа, и как с ними следует работать для поддержания безопасности?
• Как должно осуществляться восстановление? В зависимости от моделей использования ключей доступа, особенно в средах, использующих MFA, как должны быть спроектированы процессы восстановления для обеспечения их безопасности?

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

2. Определения: идентификатор, уровень безопасности, резервный вход и восстановление#

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

2.1 Идентификатор: электронная почта, номер телефона и имя пользователя#

В большинстве систем для бизнеса и потребителей аутентификация опирается на три основных идентификатора: электронная почта, номер телефона и имя пользователя.

Подавляющее большинство систем используют электронную почту в качестве основного идентификатора, особенно в веб-приложениях. Однако мобильные платформы (mobile-first или app-first) часто предпочитают использовать номер телефона в качестве идентификатора из-за простоты предварительного заполнения SMS-кода (OTP — одноразового пароля), который можно вставить автоматически. В некоторых случаях от пользователей также может потребоваться настроить имя пользователя в дополнение к этим идентификаторам, в первую очередь для платформ, которым требуется уникальное отображаемое имя. Также наблюдается растущая тенденция, особенно на крупных платформах, позволять использовать как электронную почту, так и номер телефона для дополнительной гибкости.

Во время первоначальной регистрации эти идентификаторы обычно проверяются либо с помощью ссылки для подтверждения / OTP (для электронной почты), либо OTP (для номера телефона), гарантируя, что идентификатор принадлежит правильному лицу. В случае потери доступа подтверждения контроля над ранее подтвержденной электронной почтой или номером телефона обычно достаточно для восстановления доступа к учетной записи. Поскольку эти идентификаторы являются наиболее надежными формами связи с пользователями, номера телефонов часто собираются для целей MFA, при этом SMS является часто используемым вторым фактором.

Имена пользователей часто используются для обеспечения дополнительного уровня идентификации пользователей в системах, где требуются публичные идентификаторы, таких как социальные сети, форумы или определенные профессиональные платформы. Хотя они не выполняют ту же функциональную роль при аутентификации, что и электронная почта или номера телефонов, имена пользователей предоставляют пользователям узнаваемую идентичность в публичных или peer-to-peer контекстах. Однако они вносят дополнительную сложность, поскольку пользователи часто могут их забыть, и в большинстве случаев наряду с именем пользователя требуется другой идентификатор. Поэтому в этой статье мы не будем заострять внимание на именах пользователей.

Другие варианты 2FA, такие как приложения-аутентификаторы (которые генерируют коды TOTP), не зависят от идентификатора, но часто сложнее в настройке для обычного пользователя. Ключи доступа также предоставили возможность работать без идентификатора (аутентификация без имени пользователя), функция, которая становится все более популярной в криптопространстве. Однако как для потребительских, так и для корпоративных решений необходимость взаимодействия с пользователями (часто по электронной почте) для целей резервного входа или восстановления делает системы без имен пользователей менее практичными.

2.2 Уровень безопасности: однофакторная аутентификация (SFA) и многофакторная аутентификация (MFA)#

Системы однофакторной аутентификации (SFA) — это системы, которые полагаются на одну форму аутентификации для проверки личности пользователя. Как правило, этим единственным фактором является пароль, но это также может быть социальный вход, OTP по электронной почте или любой другой метод, который требует только одного типа доказательства. Большинство систем в Интернете сегодня — это системы SFA. Однако существует хорошо известный компромисс с безопасностью. При интеграции ключей доступа они обычно служат либо дополнением, либо заменой традиционных паролей, повышая удобство системы. Обычно такие системы по-прежнему допускают варианты резервного входа, такие как OTP по электронной почте или вход через социальные сети, что улучшает пользовательский опыт за счет сокращения паролей, но не повышает безопасность системы сверх SFA.

Многофакторная аутентификация (MFA) включает в себя два или более независимых фактора для проверки личности пользователя; именно это делает ее более безопасной, чем SFA. Эти факторы могут включать в себя то, что пользователь знает (пароль или PIN-код), то, что у пользователя есть (токен безопасности или приложение на мобильном телефоне), и то, кем пользователь является (биометрическая проверка, например, отпечатки пальцев или распознавание лиц). Системы MFA предназначены для защиты от конкретных уязвимостей, от которых системы SFA не могут защитить, таких как фишинговые атаки или утечки паролей. При использовании ключей доступа в системе MFA они обычно применяются как самостоятельный вариант MFA. В этих случаях крайне важно, чтобы любые методы резервного входа или восстановления поддерживали тот же уровень безопасности, что и ключи доступа.

2.3 Резервный вход и восстановление#

Резервные варианты (Fallbacks) используются во всех системах, где сосуществуют несколько методов аутентификации. Они используются, когда основные методы недоступны — часто пользователь с самого начала имеет выбор, как зарегистрироваться (например, вход через социальные сети или по паролю). Резервный вариант может включать альтернативные стратегии аутентификации, такие как OTP по электронной почте, пароли, вход через социальные сети с совпадающими электронными адресами, push-уведомления из нативных приложений, QR-коды или ключи безопасности. Каждый из этих резервных методов различается по качеству безопасности, и выбор подходящего варианта резервного входа имеет решающее значение для баланса между удобством пользователя и требованиями безопасности.

В средах, использующих ключи доступа в качестве части системы многофакторной аутентификации (MFA), эти резервные методы необходимо тщательно продумать, чтобы убедиться, что они обеспечивают многофакторную безопасность, сравнимую с ключами доступа. Процессы восстановления (Recovery) становятся важными, когда пользователи теряют доступ ко всем установленным мерам аутентификации, которые соответствуют требуемым стандартам безопасности (SFA или MFA). Это менее критично в однофакторных системах, где может быть доступно несколько вариантов восстановления, таких как сброс пароля с помощью OTP по электронной почте, который эффективно подтверждает контроль пользователя над связанным идентификатором. Однако восстановление особенно сложно в системах 2FA/MFA, поскольку эти системы изначально полагаются на несколько факторов для верификации. В ситуациях, когда пользователь меняет мобильную операционную систему — например, с iPhone на телефон Android — и теряет связанные ключи доступа и номер телефона — оставшиеся факторы (например, только пароль) не могут удовлетворить требованиям 2FA. Восстановление в этих случаях может потребовать создания новых доказательств личности, что может включать ручные запросы в службу поддержки или более инновационные решения, которые мы рассмотрим позже.

3. Резервный вход с ключом доступа: ручной вход против автоматического входа с ключом доступа#

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

3.1 Ручной вход с ключом доступа: подход, инициируемый пользователем#

3.1.1 Что такое подход, инициируемый пользователем?#

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

На скриншоте показана реализация ключа доступа на https://my.gov.au, где используется ручной подход ко входу с помощью ключа доступа. Хотя этот подход проще реализовать, поскольку бэкенду не нужно определять, возможен ли вход по ключу доступа, он, как правило, приводит к гораздо более низким показателям входа по ключам доступа. Это связано с тем, что он в значительной степени полагается на инициативу пользователя, и потребители могут не помнить или не быть уверены в том, на какой платформе или в каком облачном хранилище находятся их ключи доступа. Этот подход заставляет пользователя думать. Давайте посмотрим, какие возможные варианты резервного входа существуют при этом подходе в следующем разделе.

3.1.2 Резервные варианты#

Резервные варианты (fallbacks) имеют важное значение в любой системе, где есть вероятность неудачного доступа к ключу доступа. При подходе к ручному входу с ключом доступа диалоги и резервные варианты не могут управляться индивидуально, потому что все варианты входа отображаются одновременно, и ключи доступа выбираются по усмотрению пользователя. Это приводит к ряду проблем:

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

В приведенном выше примере показано, насколько запутанными являются сообщения об ошибках Windows 11, когда ключи доступа не найдены в аутентификаторе платформы. Система может предполагать, что ключ доступа находится на ключе безопасности или другом устройстве. Этот процесс может сбить с толку пользователей, незнакомых с такими потоками аутентификации, особенно если они никогда раньше не использовали ключ безопасности или никогда не создавали ключ доступа.

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

3.2 Автоматический вход с ключом доступа: подход Identifier-First#

3.2.1 Что такое подход Identifier-First?#

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

Вход в Google с использованием подхода Identifier-First

Вход в Google с помощью ключа доступа

На приведенных выше скриншотах показано поведение входа в систему Google для учетной записи, к которой привязан ключ доступа на устройстве macOS. Google также следует подходу Identifier-First и определил, что вход по ключу доступа, скорее всего, будет возможен:

1. Поддержка ключа доступа платформой: базовая платформа поддерживает платформенный аутентификатор, следовательно, вход в систему может быть возможен.
2. Ключ доступа доступен: ключ доступа, скорее всего, будет доступен на этом клиенте (macOS), поскольку он был создан в системе macOS.

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

3.2.2 Отсутствие поддержки платформой ключей доступа или доступности ключа доступа#

Система определяет, возможен ли вход по ключу доступа. В случае:

• Ключ доступа не существует: пользователь еще не создал ключ доступа для своей учетной записи
• Ключи доступа недоступны: созданные пользователем ключи доступа, скорее всего, недоступны на этом клиенте (например, у пользователя есть только ключ доступа для MacOS, и теперь он выполняет вход с Windows).
• Аутентификация с помощью ключа доступа не поддерживается: текущий клиент не поддерживает платформенные аутентификаторы, а также, весьма вероятно, не поддерживает межсетевую аутентификацию устройств (Cross-Device-Authentication) с помощью QR-кода

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

В приведенном выше примере при входе происходит возврат к паролю, а затем будет предложено запросить дополнительные факторы аутентификации в зависимости от статуса и безопасности учетной записи, поскольку клиентом является устройство с Windows 11, у которого вряд ли будет доступ к ключам доступа macOS. В зависимости от требований безопасности вашей системы аутентификации вы имеете полный контроль над тем, какой метод аутентификации активировать в таком случае (например, последний успешный вариант аутентификации без использования ключа доступа).

3.2.3 Прерывания процесса входа с помощью ключа доступа#

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

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

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

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

3.3 Сравнение подходов к реализации ключей доступа#

Следующая таблица помогает сравнить различные подходы, обобщая наиболее важные характеристики:

Подходы, созданные своими силами, обычно следуют подходу ручного входа с помощью ключа доступа и полагаются на Conditional UI и на то, что пользователь выберет ключи доступа, что приводит к очень низким показателям входа с ключами доступа и разочарованным пользователям. Подход Identifier-First требует создания продуманной логики устройств поверх Conditional UI, и в этом вам может помочь Corbado. Создавать собственную логику устройств и механизм passkey intelligence не рекомендуется, поскольку этот набор правил требует постоянной настройки и адаптации к новым устройствам, новому функционалу WebAuthn и облачной синхронизации (например, ключам доступа GPM).

4. Восстановление ключей доступа#

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

4.1 Однофакторное восстановление и многофакторное восстановление#

Для обеспечения безопасности в системах SFA восстановление обычно включает подтверждение контроля над идентификатором, таким как адрес электронной почты или номер мобильного телефона.

• OTP по электронной почте: OTP отправляется на зарегистрированный адрес электронной почты пользователя. После проверки это позволяет пользователю восстановить доступ и создать новый ключ доступа.
• SMS OTP: аналогично восстановлению по электронной почте, OTP отправляется на зарегистрированный номер мобильного телефона. Пользователь может использовать этот OTP для восстановления доступа к своей учетной записи.

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

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

• Использование альтернативных факторов: если ключ доступа потерян, пользователь может пройти аутентификацию с использованием двух других факторов, таких как пароль + SMS OTP или приложение-аутентификатор. После прохождения аутентификации он может создать новый ключ доступа.
• Использование других ключей доступа: если у пользователя есть другие устройства с ключами доступа, он может использовать их для восстановления доступа с соответствующими подсказками (например, с просьбой использовать ключ доступа с iPhone).
• Создание новых ключей доступа: после аутентификации с помощью метода восстановления пользователю следует предложить создать новый ключ доступа, чтобы обеспечить сохранение настройки MFA.

Как для систем SFA, так и для систем MFA, главное — обеспечить надежность и безопасность процессов восстановления, минимизируя при этом трудности для пользователя.

4.2 Интеллектуальное восстановление MFA: цифровизация затрат на восстановление MFA#

В системах, обрабатывающих конфиденциальные персональные данные, регулируемых отраслях или государственных службах, стандартных OTP по электронной почте и OTP по мобильному номеру не всегда может быть достаточно или они могут быть недоступны для восстановления. В таких случаях механизмы интеллектуального восстановления MFA (smart MFA recovery) предлагают передовые методы восстановления учетной записи, которые поддерживают высокие стандарты безопасности, предлагая пользователям бесперебойный опыт.

Одним из наиболее эффективных методов является идентификация по селфи с проверкой на живость (liveness check). Этот процесс включает в себя фотографирование пользователем своего удостоверения личности. Кроме того, проверка селфи на живость гарантирует, что селфи сделано в режиме реального времени, подтверждая, что пользователь физически присутствует и совпадает с сфотографированным удостоверением личности, тем самым предотвращая мошенничество с использованием статических изображений или украденных удостоверений. В зависимости от используемой технологии проверка на живость выполняется путем записи короткого видео, в котором изменяется расстояние до камеры, или поворота головы на 180 градусов (например, Apple Face ID).

Этот метод может быть особенно полезен, когда традиционные методы восстановления, такие как OTP по электронной почте или SMS, недоступны или устарели. Например, вот пример того, как делается селфи, за которым следует проверка живости от onfido:

Пример: идентификация по селфи с проверкой живости от onfido

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

Кроме того, другие методы интеллектуального восстановления могут включать:

• Восстановление через несколько устройств (Cross-device recovery): если у пользователя есть доверенное вторичное устройство, он может восстановить свою учетную запись, отсканировав QR-код.
• Известные среды: пользователи, у которых по-прежнему есть доступ к тому же устройству, которое они успешно использовали в прошлом, могут предоставить дополнительные подтверждающие факторы, используя это устройство и тем самым предоставляя доказательство того, что они действуют с того же устройства, от того же провайдера и из того же местоположения, чтобы помочь ручному процессу восстановления. Этот подход использует Google для Восстановления учетной записи Gmail.
• API цифровых учетных данных (Digital Credentials API): ожидается, что с ростом популярности кошельков ID прямая проверка через этот API будет играть все большую роль в безопасном и удобном восстановлении учетной записи.

Методы интеллектуального восстановления MFA нацелены на то, чтобы предложить пользователям безопасные и интуитивно понятные способы восстановления доступа к их учетным записям, особенно при работе с конфиденциальной или регулируемой информацией. Эти подходы гарантируют, что даже в тех случаях, когда традиционные методы, такие как восстановление по электронной почте или по телефону, недоступны, пользователи по-прежнему смогут восстановить свой доступ безопасно и эффективно. Интеллектуальное восстановление помогает снизить затраты на восстановление MFA.

4.3 Частота восстановления MFA: номер телефона против ключа доступа#

Важно помнить, что поскольку ключи доступа синхронизируются в облаке, затраты на восстановление MFA намного ниже за период в 36 месяцев, так как смена номера мобильного телефона происходит гораздо чаще, чем переход с Apple на Android или наоборот. В случае смены телефона по договору о связи ключи доступа будут восстановлены.

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

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

5. Рекомендации для менеджеров по продуктам и разработчиков#

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

• Отдайте предпочтение подходу Identifier-First: этот подход более удобен для пользователя и снижает трения в процессе входа. Попросив пользователей сначала ввести свой основной идентификатор (например, адрес электронной почты или номер телефона), система может автоматически определить, возможен ли вход по ключу доступа. Это обеспечивает плавный, интуитивно понятный процесс входа в систему без необходимости полагаться на пользователя для ручного выбора параметра ключа доступа.
• Используйте поясняющие экраны прерывания для лучшего пользовательского опыта: хотя безопасность должна быть главным приоритетом, важно разработать процесс, который поможет пользователю освоить ключи доступа. Убедитесь, что прерывания процесса в первый раз рассматриваются как нормальные явления, и дайте четкие указания повторить попытку.
• Обеспечьте безопасность вариантов резервного входа и восстановления: убедитесь, что резервные методы (такие как OTP по электронной почте и/или SMS OTP) соответствуют уровню безопасности основного метода аутентификации. Например, в системе MFA, использующей ключи доступа, резервный вариант также должен требовать нескольких факторов для поддержания того же стандарта безопасности.
• Автоматизируйте регулярные запросы на восстановление: регулярно предлагайте пользователям проверять свою контактную информацию (адрес электронной почты или номер телефона) во время входа в систему, чтобы гарантировать, что варианты восстановления остаются актуальными при использовании ими ключей доступа. Это снижает вероятность того, что пользователи будут заблокированы в своих учетных записях из-за устаревших методов восстановления.
• Рассмотрите методы интеллектуального восстановления для повышения безопасности и снижения затрат на поддержку восстановления: для регулируемых отраслей или систем, имеющих доступ к персональным данным для онлайн-проверки личности, рассмотрите расширенные методы восстановления, такие как идентификация по селфи с проверкой живости. Этот метод может обеспечить дополнительные уровни безопасности, сохраняя при этом интуитивно понятный и удобный для пользователя процесс восстановления в зависимости от ваших требований к безопасности.

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

6. Что Corbado может сделать для вас: компоненты UI и Passkey Intelligence#

Corbado предоставляет все необходимое для реализации подхода Identifier-First для проектов, создаваемых с нуля, которым нужна совершенно новая система аутентификации, и для существующих проектов, которым необходимо добавить ключи доступа в существующую систему аутентификации.

6.1 UI компоненты для различных сценариев использования#

Оба продукта предлагают компоненты пользовательского интерфейса (UI), которые можно настроить под ваши нужды:

1. Corbado Complete: начните свой проект с аутентификации passkey-first (сначала ключ доступа)
   Это наша полная система аутентификации, которая включает в себя бесшовный подход Identifier-First для упрощения процесса входа в систему. Corbado Complete обеспечивает безопасный и удобный опыт, автоматически определяя, возможен ли вход по ключу доступа, после того как пользователь вводит свой идентификатор. Это уменьшает трения и обеспечивает плавный процесс входа, что имеет решающее значение для максимального принятия ключей доступа.
2. Corbado Connect: добавьте ключи доступа без миграции в любое приложение
   Для предприятий, которые уже имеют устоявшиеся процессы аутентификации и хотят добавить ключи доступа в качестве улучшения, Corbado Connect предлагает дополнительное решение для стратегий однофакторной и многофакторной аутентификации. Этот подход дополняет вашу существующую инфраструктуру путем плавной интеграции ключей доступа как безопасного и удобного варианта, позволяя пользователям аутентифицироваться с помощью ключей доступа без капитального ремонта вашей текущей системы. Например, Corbado Connect можно легко встроить в Amazon Cognito.

Мы строго согласовываем наши методы с лидерами отрасли, такими как Google и другими видными игроками в сфере больших технологий, особенно ориентированными на потребительские компании.

6.2 Passkey Intelligence позволяет использовать подход Identifier-First#

Наша цель — не только максимизировать принятие ключей доступа (т. е. создание ключей доступа), но и гарантировать, что эти ключи доступа активно используются для обеспечения высокого уровня входа в систему (и, следовательно, повышения безопасности и снижения затрат на SMS OTP). Наши компоненты UI созданы с учетом подхода Identifier-First и напрямую подключены к нашему Passkey Intelligence, который принимает решения о наличии и доступности ключей доступа на основе клиентской среды и существующих ключей доступа. Они поддерживают все обсуждаемые функциональные возможности резервного входа и восстановления. Следующие экраны показывают нашу логику прерывания и повторной попытки:

Первое прерывание ключа доступа

Второе прерывание ключа доступа

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

7. Заключение#

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

• Какие сценарии резервного входа существуют? Может возникнуть несколько сценариев резервного входа, например, отсутствие поддержки ключа доступа или недоступность ключей доступа на определенном устройстве. Для обеспечения безопасности и бесперебойного UX (пользовательского опыта) должны быть доступны варианты резервного входа, такие как электронная почта или SMS OTP, когда вход по ключу доступа невозможен.
• Как должно осуществляться восстановление? Процессы восстановления должны быть спроектированы так, чтобы соответствовать уровню безопасности системы аутентификации. В системах SFA может быть достаточно электронной почты или SMS OTP, в то время как в системах MFA для восстановления доступа и создания нового ключа доступа необходимо использовать альтернативные факторы. В строго регулируемых или конфиденциальных средах интеллектуальные методы восстановления, такие как идентификация по селфи с проверкой живости, обеспечивают дополнительную безопасность.

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

О Corbado

Corbado — это Passkey Intelligence Platform для CIAM-команд, обеспечивающих аутентификацию пользователей в крупных масштабах. Мы показываем то, что не видят логи IDP и общие инструменты аналитики: какие устройства, версии ОС, браузеры и менеджеры учётных данных поддерживают passkey, почему регистрации не превращаются в логины, где сбоит WebAuthn-поток и когда обновление ОС или браузера тихо ломает вход — всё это без замены Okta, Auth0, Ping, Cognito или вашего собственного IDP. Два продукта: Corbado Observe добавляет наблюдаемость для passkey и любых других способов входа. Corbado Connect даёт managed passkey со встроенной аналитикой (рядом с вашим IDP). VicRoads использует passkey для более чем 5 млн пользователей с Corbado (+80 % активации passkey). Поговорить с экспертом по passkey →

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

Как подход Identifier-First обрабатывает вход по ключу доступа, если ключ недоступен на текущем устройстве?#

Когда ключ доступа, скорее всего, недоступен (например, ключ доступа macOS используется с устройства Windows), система автоматически пропускает запрос ключа доступа и вместо этого предлагает резервные варианты, такие как пароль или OTP. Это позволяет избежать тупиковых ситуаций, запутывающих пользователя, поскольку вход по ключу доступа запускается только тогда, когда успех вероятен, следуя стратегии «не заставляйте меня думать».

Что должно произойти, если пользователь прерывает процесс аутентификации по ключу доступа на полпути?#

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

Какие варианты восстановления существуют для систем MFA, когда пользователь теряет доступ к своему ключу доступа?#

В системах MFA пользователи могут восстановить доступ, пройдя аутентификацию с помощью двух альтернативных факторов, таких как пароль плюс SMS OTP, или используя ключ доступа с другого доверенного устройства, а затем создать новый ключ доступа. Для регулируемых отраслей, где традиционные методы восстановления недоступны, интеллектуальные методы, такие как идентификация по селфи с проверкой живости (liveness check), обеспечивают дополнительный безопасный путь восстановления.

Почему подход с кнопкой ручного «Входа по ключу доступа» приводит к более низкому уровню внедрения по сравнению с подходом Identifier-First?#

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