Passkeys в мобильном приложении без Safari: как реализовать нативную авторизацию на iOS и Android

Да, использовать passkeys в мобильном приложении без Safari возможно. Браузерный сценарий с WebAuthn часто становится первым примером знакомства с технологией, поэтому создаётся впечатление, что passkeys обязательно требуют Safari или другого браузера. Однако нативные мобильные приложения могут работать с passkeys напрямую через системные API iOS и Android.

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

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

Что такое passkeys и почему их связывают с Safari

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

• приватный ключ остаётся на устройстве и используется только для криптографических операций;
• публичный ключ передаётся серверу и используется для проверки подписи.

В основе технологии лежат стандарты FIDO2. Один из ключевых компонентов — WebAuthn (Web Authentication API), который описывает взаимодействие между веб-приложением и аутентификатором. Второй компонент — CTAP (Client To Authenticator Protocol), который описывает обмен между клиентом и аутентификатором.

В браузере схема выглядит так: сайт обращается к WebAuthn API браузера, браузер взаимодействует с операционной системой, а система обращается к доступному аутентификатору. Из-за этого многие материалы о passkeys показывают именно браузерный путь.

Safari, Chrome и другие браузеры действительно стали одним из первых способов распространения passkeys, потому что WebAuthn изначально активно развивался как веб-стандарт. Но мобильное приложение не обязано проходить через браузерный слой.

Можно ли использовать passkeys внутри мобильного приложения без браузера

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

Разница между браузерным и нативным сценарием выглядит так:

Сценарий	Кто инициирует работу с credential	Кто управляет ключами
WebAuthn в браузере	Веб-приложение через браузер	ОС и аутентификатор
Native mobile	Мобильное приложение через системный API	ОС и системный менеджер credential

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

Как работают passkeys в iOS-приложениях

В экосистеме Apple нативные приложения могут использовать системные возможности для работы с passkeys через API платформы, в частности через фреймворк AuthenticationServices.

Приложение не создаёт собственное хранилище ключей и не получает доступ к секретной части credential. Вместо этого оно формирует запрос на регистрацию или аутентификацию и передаёт его системе.

При регистрации обычно происходит следующий процесс:

1. Приложение получает от сервера параметры создания credential.
2. Приложение передаёт запрос системному API авторизации.
3. Операционная система предлагает пользователю подтвердить создание passkey.
4. Устройство создаёт криптографический credential.
5. Приложение получает публичные данные credential и передаёт их серверу.
6. Backend сохраняет публичный ключ и связывает его с аккаунтом пользователя.

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

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

Как работают passkeys в Android-приложениях

На Android нативная работа с passkeys строится через системную инфраструктуру управления учётными данными. Одним из ключевых компонентов является Credential Manager.

Credential Manager предоставляет приложению единый интерфейс для взаимодействия с различными типами учётных данных, включая passkeys. Приложение запрашивает нужный credential, а операционная система определяет, какие варианты доступны пользователю.

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

• приложение отправляет запрос через системный API;
• Android обращается к доступным поставщикам credential;
• пользователь выбирает или подтверждает passkey;
• система выполняет криптографическую операцию;
• приложение получает результат для отправки серверу.

Как и на iOS, приложение не должно пытаться хранить приватные ключи самостоятельно. Такая модель снижает риск утечек и сохраняет преимущества аппаратной защиты устройства, если она доступна.

Как устроена архитектура passkeys: приложение, устройство и сервер

Полноценное внедрение passkeys состоит из трёх основных частей:

Мобильное приложение → системный API → создание credential → регистрация публичного ключа на сервере → последующая аутентификация через подпись challenge.

Backend играет центральную роль. Он отвечает за создание запросов, проверку ответов и хранение информации о credential.

На сервере обычно сохраняются:

• публичный ключ;
• идентификатор credential;
• связь credential с аккаунтом пользователя;
• служебные данные, необходимые для проверки.

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

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

Как внедрить passkeys в мобильное приложение: последовательность действий

1. Проверить готовность backend.

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

2. Спроектировать модель хранения credential.

   Необходимо определить связь passkey с пользователем, поддержку нескольких устройств и удаление старых credential.

3. Добавить регистрацию passkey.

   Приложение получает параметры от сервера, вызывает системный API и передаёт результат регистрации обратно.

4. Добавить вход через passkey.

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

5. Обработать ошибки.

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

6. Добавить резервные способы входа.

   Пользователь должен иметь путь восстановления доступа при потере устройства или невозможности использовать passkey.

7. Протестировать разные сценарии.

   Важно проверять новые устройства, восстановление, несколько credential, разные версии ОС и различные методы подтверждения личности.

Что происходит при входе пользователя

1. Пользователь открывает приложение и выбирает вход через passkey.
2. Приложение обращается к серверу и получает параметры запроса аутентификации.
3. Приложение передаёт запрос системному API.
4. Операционная система показывает доступные credential.
5. Пользователь подтверждает действие.
6. Устройство подписывает предоставленный сервером challenge.
7. Приложение отправляет результат серверу.
8. Backend проверяет подпись с помощью сохранённого публичного ключа.
9. При успешной проверке сервер создаёт пользовательскую сессию.

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

Можно ли полностью отказаться от Safari

Да, в нативном мобильном приложении Safari обычно не нужен. Приложение может использовать системные API iOS и Android для работы с passkeys напрямую.

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

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

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

Ошибка 1. Считать passkeys полной заменой системы аккаунтов

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

Правильно: проектировать passkeys как часть полноценной системы идентификации.

Ошибка 2. Пытаться хранить приватные ключи на сервере

Это нарушает основную модель безопасности passkeys.

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

Ошибка 3. Игнорировать потерю устройства

Пользователь может потерять телефон или получить новый.

Правильно: заранее предусмотреть восстановление доступа и управление несколькими credential.

Ошибка 4. Проектировать UX только для успешного сценария

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

Ошибка 5. Тестировать только одно устройство

Разные версии ОС и модели устройств могут иметь различия в поведении системных компонентов.

Правильно: проверять реальные пользовательские сценарии на разных конфигурациях.

Ошибка 6. Не учитывать миграцию с паролей

Большинство приложений уже имеют пользователей с существующими способами входа.

Правильно: создавать постепенный переход, а не требовать мгновенного отказа от старой авторизации.

Ограничения и важные нюансы

• Совместимость устройств. Поддержка зависит от версии операционной системы, настроек устройства и доступных системных компонентов.
• Синхронизация credential. Некоторые платформы позволяют синхронизировать passkeys между устройствами пользователя через собственные экосистемы. Это нужно учитывать при проектировании модели аккаунта.
• Потеря устройства. Passkey не отменяет необходимость продуманного восстановления.
• Несколько устройств. Один пользователь может иметь несколько credential, поэтому сервер должен поддерживать такую модель.
• Корпоративные сценарии. В организациях могут действовать собственные политики управления устройствами и учётными данными.
• Резервная авторизация. Для некоторых продуктов необходимо сохранить дополнительные методы подтверждения личности.

Когда passkeys действительно подходят мобильному приложению

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

Хорошими кандидатами являются:

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

При этом внедрение имеет смысл только тогда, когда backend, UX и процессы восстановления готовы к новой модели.

Практический вывод

Использование passkeys в мобильном приложении без Safari — это стандартный сценарий для современных нативных приложений. Браузерный WebAuthn — только один из вариантов взаимодействия с технологией.

На iOS и Android приложение обращается к системным механизмам авторизации, а операционная система управляет credential и защищает приватные ключи. Backend получает только публичную часть и проверяет криптографические подписи.

Главная задача команды разработки — не просто добавить кнопку «Войти с passkey», а правильно встроить технологию в архитектуру аккаунтов, серверную логику и пользовательские сценарии.

FAQ

Нужен ли Safari для passkeys в iOS-приложении?

Нет. Нативные приложения могут использовать системные API iOS без открытия Safari.

Может ли приложение получить приватный ключ passkey?

Нет. Приватный ключ остаётся под управлением системного хранилища credential и не передаётся приложению.

Чем passkeys отличаются от сохранённых паролей?

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

Можно ли использовать один passkey на нескольких устройствах?

Это зависит от механизмов синхронизации платформы и настроек пользователя.

Заменяют ли passkeys двухфакторную аутентификацию?

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

Стоит ли сразу отключать пароли после внедрения passkeys?

Обычно нет. Для большинства продуктов лучше использовать постепенный переход с сохранением понятных способов восстановления доступа.