Пользователь открывает мобильное приложение магазина, чтобы повторить привычный заказ, — и упирается в форму логина. Вспомнить пароль, переключить раскладку, промахнуться мимо кнопки: три секунды раздражения, и часть людей просто закрывает приложение. В мобайле каждый лишний барьер на входе стоит заказов, а вход по паролю — один из самых заметных барьеров.
Эта статья — о том, как сделать вход по биометрии: по Face ID, отпечатку пальца или системному экрану разблокировки. Разберём, как это устроено, чем токен лучше пароля, где хранить секреты, как связать приложение с бэкендом на 1С-Битрикс и что учесть в безопасности. Данные, которые клиент видит после входа, обычно тянутся из учётной системы, поэтому вопросы связки касаются и автоматизации продаж и склада на 1С.
Коротко
- Биометрия не передаётся на сервер: она лишь разблокирует доступ к токену, сохранённому на устройстве.
- После первого обычного входа приложение хранит токен в Keychain (iOS) или Keystore (Android), защищённый биометрией.
- Всегда оставляйте запасной вход (пароль или PIN) и возможность отозвать токен при потере устройства.
- Ценность быстрого входа раскрывается, когда после него клиент сразу видит актуальные данные из 1С.
Почему быстрый вход решает в мобайле
Мобильное приложение выигрывает у сайта именно за счёт скорости и привычки: клиент заходит часто, короткими сессиями, обычно за конкретным действием — проверить статус заказа, повторить закупку, посмотреть цену. В этом ритме форма входа с паролем ломает весь сценарий. Человек либо не помнит пароль, либо не хочет его вводить с телефона — и откладывает действие «на потом», которое не наступает.
Быстрый вход по биометрии снимает этот барьер. Клиент прикладывает палец или смотрит в камеру — и уже внутри. Для приложений с регулярными заказами это напрямую поднимает частоту возвратов и конверсию постоянных покупателей: путь от запуска до оформления сокращается до нескольких секунд. Барьер входа — частая причина, по которой приложение скачивают, но не используют.
Как устроена биометрическая аутентификация
Главное заблуждение — что приложение «получает отпечаток» и отправляет его на сервер. Это не так и так делать нельзя. Биометрические данные никогда не покидают устройство: они хранятся в отдельном аппаратном модуле (Secure Enclave на iOS, доверенная среда TEE на Android) и недоступны ни приложению, ни операционной системе напрямую.
Схема работает иначе. При первом обычном входе приложение получает от сервера токен сессии и сохраняет его в защищённом хранилище устройства, «запирая» доступ к нему биометрией. В следующий раз приложение просит систему подтвердить личность; если биометрия совпала, система выдаёт разрешение достать токен, и приложение молча авторизуется на сервере этим токеном. То есть биометрия — это не «пароль на сервер», а ключ к локальному сейфу с уже выданным токеном.
Face ID, отпечаток и BiometricPrompt
На разных платформах механизм называется по-разному, но принцип общий: приложение вызывает системный API, а тот сам показывает окно проверки и возвращает результат.
| Платформа | Механизм | Защищённое хранилище |
|---|---|---|
| iOS | Face ID / Touch ID через LocalAuthentication | Keychain + Secure Enclave |
| Android | BiometricPrompt (отпечаток, лицо) | Keystore + TEE / StrongBox |
| Запасной путь | Системный PIN / пароль устройства | То же хранилище |
Важная деталь: современные API умеют откатываться на код разблокировки устройства, если биометрия недоступна. Это удобно, но нужно осознанно решить, разрешать ли такой откат для входа в магазин, — для чувствительных действий его иногда намеренно отключают, требуя именно биометрию.
Токены вместо пароля
Фундамент быстрого входа — токены, а не хранение пароля. Пароль в приложении держать нельзя: даже зашифрованный, он остаётся паролем, который можно похитить. Вместо него используют пару токенов.
- Access-токен — короткоживущий, им приложение подписывает запросы к API. Живёт минуты или часы и легко отзывается.
- Refresh-токен — долгоживущий, лежит в защищённом хранилище под биометрией. По нему приложение получает новый access-токен, не спрашивая пароль.
Именно refresh-токен «отпирается» биометрией. Пользователь подтвердил личность — приложение достало refresh-токен, обменяло его на свежий access-токен и авторизовалось. Пароль при этом не участвует вовсе. Такой подход даёт и удобство, и контроль: скомпрометированный токен отзывают на сервере, не трогая аккаунт.
Где хранить секреты: Keychain и Keystore
Токен нельзя класть в обычные настройки приложения или локальную базу — там его достанут. Для секретов есть системные защищённые хранилища, привязанные к аппаратной защите устройства.
- iOS Keychain. Элемент помечается флагом, требующим биометрию для доступа; ключ шифрования держит Secure Enclave.
- Android Keystore. Ключ создаётся с условием «доступ только после биометрической аутентификации», в доверенной среде или StrongBox.
- Привязка к устройству. Ключи не экспортируются и не переносятся — на новом телефоне их просто нет, и это правильно.
Связка приложения с бэкендом 1С-Битрикс
Мобильное приложение почти всегда общается с сайтом на 1С-Битрикс через API: выдача токенов, проверка сессии, история заказов, цены и остатки. Быстрый вход — лишь фасад, за которым стоит надёжный обмен данными между приложением и бэкендом, а через него — с 1С.
Безопасность этого канала — отдельная большая тема: авторизация запросов, защита эндпоинтов, вебхуки для событий заказа. Мы подробно разбирали её в статье про REST, вебхуки и безопасность в Битрикс, а сам мобильный клиент часто опирается на серверную логику из кастомного модуля Битрикс. Данные же о заказах и остатках, которые клиент видит после входа, приходят из учётной системы — за это отвечает автоматизация на 1С.
Первый вход и привязка биометрии
Биометрию нельзя включить «по умолчанию» — сначала нужен обычный вход, а затем явное согласие пользователя. Типовой сценарий подключения выглядит так:
- Обычный вход. Пользователь входит по логину и паролю или коду из SMS, сервер выдаёт пару токенов.
- Предложение включить биометрию. Приложение спрашивает, включить ли быстрый вход, и объясняет, что это удобно и безопасно.
- Создание защищённого ключа. Refresh-токен кладётся в Keychain / Keystore с условием доступа по биометрии.
- Проверка. Приложение сразу просит подтвердить биометрию, чтобы убедиться, что механизм работает на этом устройстве.
- Следующие запуски. При открытии приложения — только биометрия, без ввода пароля.
Спрашивать согласие важно не только из вежливости: пользователь должен понимать, что включает, и иметь возможность отказаться. Навязанная биометрия вызывает недоверие и удаления.
Смена устройства, сброс и запасной вход
Быстрый вход обязан корректно вести себя в «нештатных» ситуациях, иначе он превратится в ловушку. Ключевые сценарии:
- Новое устройство. Ключа нет — пользователь входит обычным способом и заново включает биометрию.
- Потеря телефона. В личном кабинете или по обращению токен отзывается, старое устройство теряет доступ.
- Смена биометрии на устройстве. Если добавлен новый отпечаток или лицо, система может инвалидировать ключ — приложение это ловит и просит войти заново.
- Отказ от биометрии. Пользователь может выключить быстрый вход и вернуться к паролю или PIN.
Запасной способ входа — не опция, а обязательное требование. Часть пользователей не имеет биометрии на устройстве или не доверяет ей; без пароля или PIN они окажутся заперты снаружи собственного аккаунта.
Безопасность и типовые риски
Биометрия повышает безопасность, но не отменяет базовых мер защиты. Риски, о которых стоит помнить:
- Компрометация токена. Решается коротким сроком жизни access-токена и возможностью отзыва refresh-токена на сервере.
- Подмена запросов. Весь обмен идёт только по защищённому соединению, эндпоинты проверяют авторизацию каждого запроса.
- Доступ к устройству чужого человека. Если телефон разблокирован и биометрия чужая — тут защищает сама биометрия устройства, поэтому важен корректный откат на PIN.
- Устаревшие сессии. Логаут на всех устройствах и отзыв токенов при смене пароля — обязательны.
UX быстрого входа
Даже технически верный вход можно испортить неудобным поведением. Несколько принципов хорошего UX:
- Не заставляйте. Предлагайте биометрию после первого входа, а не блокируйте приложение, пока не включат.
- Объясняйте отказ. Если биометрия не сработала, покажите понятное сообщение и путь входа по паролю, а не пустой экран.
- Уважайте контекст. Требовать биометрию при каждом переходе внутри приложения — перебор; хватает входа и подтверждения чувствительных действий.
- Держите настройку. В профиле должна быть явная опция включить и выключить быстрый вход.
Хорошо, когда после входа клиент сразу попадает не на пустой экран, а на то, ради чего пришёл: свои заказы, привычную закупку, статусы. Это уже вопрос данных из учётной системы и продуманности личного кабинета.
Частые ошибки
- Хранят пароль на устройстве. Даже зашифрованный пароль — это пароль; нужен отзываемый токен.
- Нет запасного входа. Пользователь без биометрии оказывается заперт снаружи аккаунта.
- Токен нельзя отозвать. При потере телефона доступ к аккаунту не закрыть — критичная дыра.
- Биометрию навязывают. Приложение требует включить быстрый вход, вызывая недоверие и удаления.
- Игнорируют смену биометрии. Добавили новый отпечаток — а приложение по-прежнему пускает по старому ключу.
- Слабая защита API. Красивый вход поверх незащищённых эндпоинтов не даёт реальной безопасности.
Чек-лист внедрения
- Архитектура токенов. Пара access + refresh, короткий срок access, отзыв refresh на сервере.
- Защищённое хранилище. Refresh-токен в Keychain / Keystore с условием доступа по биометрии.
- Первый вход и согласие. Биометрия включается явно после обычного входа.
- Запасной путь. Вход по паролю или PIN доступен всегда.
- Сценарии сброса. Новое устройство, потеря, смена биометрии обрабатываются корректно.
- Безопасность канала. Только защищённое соединение, авторизация каждого запроса к бэкенду 1С-Битрикс.
- Актуальные данные. После входа клиент сразу видит заказы, статусы и цены из 1С.
- Проверка на устройствах. Разные модели iOS и Android, откат на PIN, поведение без биометрии.
Вывод
Биометрический вход — это не про «модную кнопку», а про снятие главного барьера мобильной коммерции: ввода пароля. Работает он просто и безопасно, если строить его на токенах и защищённом хранилище устройства, а не на хранении пароля: биометрия отпирает локальный сейф с refresh-токеном, а не летит на сервер.
Но сам по себе быстрый вход бесполезен, если за ним пустота. Ценность появляется, когда после разблокировки клиент мгновенно видит свои заказы, персональные цены и остатки — а всё это приходит из 1С. Поэтому связку приложения с учётной системой и защиту API стоит проектировать вместе с быстрым входом, а не после него. Инфраструктурную часть — от хостинга и BitrixVM до безопасного API — закладывайте заранее.
