Разработка мобильного приложения для электронного пропуска (Digital Pass)
Пластиковый бейдж у проходной — это 2010-й год. Большинство запросов на разработку Digital Pass сводятся к одной задаче: бесшовная верификация сотрудника или посетителя без физического носителя. Но за этой простотой скрывается серьёзный стек: криптографически подписанные токены, NFC/BLE-коммуникация с турникетами, офлайн-режим при потере связи и соответствие требованиям корпоративной MDM-политики.
Где чаще всего ломается логика Digital Pass
Самая частая проблема — приложение показывает QR-код, но не гарантирует его одноразовость. Статичный QR на экране телефона можно сфотографировать и передать. Правильное решение — динамический TOTP-код поверх подписанного JWT: каждые 30 секунд новый код, сгенерированный на основе shared secret, выданного при онбординге. На сервере проверяется не сам QR, а подпись токена + временное окно.
Второй болевой сценарий — NFC-взаимодействие с OSDP-контроллерами (Suprema, HID). Если приложение написано без учёта NFCTagReaderSession lifecycle на iOS, читалка теряет сессию при уходе в background. Обходится явным invalidate() и переносом логики в URLSessionConfiguration.background для silent push, который будит приложение при поднесении телефона.
Как мы строим такие приложения
Стек зависит от требований. Если важна только iOS-аудитория — Swift + CryptoKit для подписи пропуска, Core NFC для считывания/записи, PassKit для Apple Wallet-интеграции. Если нужен cross-platform — Flutter с flutter_nfc_kit + нативными platform channels для доступа к Secure Enclave на iOS и Android Keystore на Android.
Ключевые компоненты:
- Пропуск как Verifiable Credential (VC) по стандарту W3C — JSON-LD документ с DID-подписью эмитента. Удобен при интеграции с внешними СКУД-системами.
- Offline-first хранение: пропуск шифруется AES-GCM и сохраняется в Keychain (iOS) / EncryptedSharedPreferences (Android). Верификатор на турникете работает без интернета через Bluetooth challenge-response.
- Apple Wallet / Google Wallet: PKPass и Google Wallet Pass API позволяют разместить пропуск в нативном кошельке без отдельного приложения. Но там нет возможности встроить динамический TOTP — только статичные поля + barcode. Для корпоративных нужд часто делаем собственный пропуск внутри приложения.
Один из реализованных кейсов: мобильный пропуск для складского комплекса с 12 точками доступа. Каждый читатель — BLE-периферийный девайс. Приложение на Flutter сканирует BLE-устройство, устанавливает GATT-соединение, отправляет подписанный challenge и получает grant или deny. Время от поднесения до ответа — 800–1200 мс. Fallback — QR с TOTP при выключенном BLE.
Роль MDM и профилей конфигурации
Корпоративный Digital Pass без MDM — уязвимость. Если устройство не управляемое, нельзя гарантировать, что приложение не удалено или не клонировано. Интеграция с Apple Configurator / Microsoft Intune позволяет:
- принудительно установить приложение на устройства;
- передать конфигурацию (URL бэкенда, tenant ID) через Managed App Configuration без хардкода;
- заблокировать screenshot API (
UIScreen.isCaptured→ показываем пустой экран вместо пропуска).
Этапы проекта
Типовой путь: аудит существующей СКУД и её API → проектирование схемы токенов и протокола верификации → разработка мобильного клиента и сервера верификации → пилот на одной точке доступа → нагрузочный тест → rollout.
Сроки: от 6 недель (QR/TOTP-пропуск без NFC, одна платформа) до 4 месяцев (BLE + NFC + Wallet + MDM + две платформы). Стоимость рассчитывается индивидуально после анализа требований к СКУД и инфраструктуре.