Верификация KYC/KYB в мобильном приложении: интеграция и реализация

Реализация KYC/KYB проверки в мобильном приложении

KYC (Know Your Customer) и KYB (Know Your Business) — это не просто «загрузить фото паспорта». Это комплекс технических и регуляторных требований: верификация личности, liveness detection, проверка по санкционным спискам, AML-скрининг, хранение и аудит данных. Мобильное приложение — точка сбора данных и orchestration процесса. Мы реализуем KYC/KYB под ключ: интегрируем SDK, настраиваем backend, обрабатываем все статусы верификации. Сроки — от 15 рабочих дней. Ошибки здесь стоят дорого — отзыв лицензии или штрафы регулятора. Наша команда имеет 5+ лет опыта и реализовала 50+ проектов с KYC-интеграцией. Закажите консультацию для оценки вашего проекта.

Как выбрать провайдера KYC?

Самостоятельная реализация KYC — редкость. Процессинг документов, liveness detection с защитой от атак (фотографии, deepfake video, 3D-маски), проверка по санкционным спискам (OFAC, EU, UN) — это отдельный продукт, требующий нескольких лет разработки и постоянных обновлений. Интеграция готового SDK обходится в разы дешевле самостоятельной разработки, экономя бюджет проекта.

На рынке зрелые SDK: Onfido, Jumio, Sumsub, IDnow, Veriff, Stripe Identity. Выбор зависит от географии пользователей, типа документов, требований регулятора и ценовой модели. Мы интегрируем SDK провайдера в мобильное приложение, настраиваем серверный webhook, строим UI flow и обрабатываем все состояния верификации. Обратитесь к нам — мы поможем выбрать оптимального провайдера.

Интеграция Sumsub как пример

Sumsub — популярный выбор для СНГ и Европы. SDK для iOS (SumSubSDK) и Android (com.sumsub.sns:core).

Общий flow:

1. Backend создаёт applicant через Sumsub API: POST /resources/applicants с externalUserId.
2. Backend генерирует access token для SDK: POST /resources/accessTokens с applicantId и levelName.
3. Мобильное приложение получает access token от вашего backend.
4. SDK запускается с этим токеном.

// iOS
import IdensicMobileSDK

let sdk = SNSMobileSDK.init(
    accessToken: receivedToken,
    baseUrl: "https://api.sumsub.com",
    flowName: "basic-kyc",
    locale: "ru"
)
sdk.onStatusDidChange = { sdk, prevStatus in
    switch sdk.status {
    case .ready: break
    case .incomplete: self.handleIncomplete()
    case .pending: self.showPendingScreen()
    case .approved: self.handleApproved()
    case .declined: self.handleDeclined()
    case .failed: self.handleError(sdk.failReason)
    @unknown default: break
    }
}
sdk.present(from: self)

// Android
val sdk = SNSMobileSDK.Builder(this)
    .withAccessToken(token, onTokenExpiration = { callback ->
        viewModel.refreshApplicantToken { newToken -> callback(newToken) }
    })
    .withLocale(Locale("ru"))
    .build()
sdk.launch()

Обработчик onTokenExpiration важен: токен живёт 10 минут. Если пользователь завис на фото-шаге дольше — SDK вызовет callback и ждёт обновлённый токен.

Как работает liveness detection?

Современный liveness detection — passive (пользователь смотрит в камеру) или active (моргнуть, повернуть голову). Passive работает на ML-моделях, активный — на motion detection.

Требования к камере: минимум 720p, автофокус. Слабое освещение — частая причина failure. SDK предоставляют real-time feedback: "Улучшите освещение", "Держите телефон ровнее".

Атаки на liveness:

• Фотография — базовая защита во всех SDK.
• Видео replay — более сложная защита.
• 3D-маски — защищают SDK класса enterprise (Jumio, Onfido).
• DeepFake — активная область разработки, не все SDK защищают.

Сканирование документов

Все SDK поддерживают автоматический capture: детектируют края документа, проверяют blur, отражения, читаемость. Пользователь не нажимает кнопку — SDK сам делает снимок при достижении порога качества. Это критично: ручной capture даёт 30–40% плохих снимков, автоматический — 5–8%. Автоматический захват лучше ручного в 2 раза по качеству.

Поддерживаемые документы зависят от SDK и региона. Sumsub покрывает 220+ стран. Onfido — 195. У каждого SDK есть database поддерживаемых документов.

MRZ (Machine Readable Zone) — нижняя полоса паспорта с зашифрованными данными. SDK извлекает данные из MRZ и сравнивает с визуальной зоной — extra validation.

KYB: верификация бизнеса

KYB сложнее KYC: нужны регистрационные документы компании, подтверждение адреса (утилитный счёт не старше 3 месяцев), KYC бенефициарных владельцев (UBO — beneficial owners с долей от 25%).

Sumsub Business Verification и Jumio KYB поддерживают KYB flow с wizard для сбора документов. Особенность: каждый UBO проходит полный KYC отдельно. Если у компании три бенефициара — три KYC-проверки, которые могут проходить асинхронно.

Мобильное приложение должно поддерживать этот асинхронный flow: пользователь отправил документы компании, сейчас ожидает верификацию UBO-1, UBO-2 в процессе, UBO-3 ещё не начал. Строим status dashboard с прогрессом по каждому участнику.

Webhooks и polling

Верификация — асинхронный процесс (от минут до дней при ручной проверке). После сабмита документов SDK сообщает статус pending. Реальный результат приходит через webhook на ваш backend.

Backend принимает webhook (applicantReviewed, applicantPending), обновляет статус пользователя в базе, отправляет push notification в мобильное приложение.

Мобильное приложение показывает статус "На проверке" с анимацией. Polling каждые 30–60 секунд — резервный механизм.

Хранение и соответствие GDPR

Изображения документов не хранятся на наших серверах — только у провайдера KYC. Мы храним только applicantId, статус и дату проверки. Права пользователя на удаление данных (GDPR Article 17) реализуем через API провайдера: DELETE /resources/applicants/{applicantId}.

Согласно GDPR, пользователи имеют право на удаление персональных данных. Мы обеспечиваем compliance через API провайдеров.

Retention policy: большинство провайдеров хранят данные 5–7 лет (требования AML/FATF). При удалении из провайдера мы задокументируем, что данные удалены — для аудита регулятора.

Что входит в работу

• Документация по интеграции (Sequence diagram, описание flow)
• Доступы к тестовой среде провайдера
• Обучение команды продукта
• Техническая поддержка на этапе запуска
• Аудит безопасности и соответствия регулятору

Этапы работы

Срок: 15–25 рабочих дней. Зависит от провайдера, требований регулятора, наличия KYB-компонента.

Серверная часть (webhook handling, AML integration, audit trail) — оценивается отдельно с backend командой. Стоимость интеграции рассчитывается индивидуально; правильный выбор провайдера позволяет сократить затраты на поддержку.

Для консультации и оценки вашего проекта свяжитесь с нами. Мы оценим задачу в течение 1 рабочего дня.

Что ломает аутентификацию в мобайле

Мы видели приложение банка, где PIN‑логин выдавал JWT, а токен ложился в SharedPreferences plain‑текстом. Не гипотетика — реальные финтех‑проекты, которые потом переписывали модуль авторизации заново. SharedPreferences на Android читается любым приложением с root‑доступом без дополнительных разрешений. На iOS аналог — UserDefaults вместо Keychain. Ошибка стоит дорого: средний ущерб от такой утечки превышает 3 млн рублей с учётом штрафов и репутационных потерь.

Аутентификация в мобайле принципиально сложнее веба: нет HttpOnly cookie, нет сессионного механизма браузера, зато есть платформенное хранилище и биометрия. Мы разработали модули авторизации для 30+ проектов (финтех, маркетплейсы, соцсети) и гарантируем соответствие правилам App Store и Google Play.

Как защитить токены при OAuth 2.0 аутентификации?

iOS Keychain — зашифрованное хранилище на уровне ОС. Данные защищены Secure Enclave на устройствах с Face ID/Touch ID. Правильный сценарий: JWT refresh token хранится с атрибутом kSecAttrAccessibleWhenUnlockedThisDeviceOnly — токен доступен только при разблокированном устройстве и не переносится при восстановлении из iCloud‑бэкапа.

// Сохранение в Keychain через Security framework
let query: [String: Any] = [
    kSecClass as String: kSecClassGenericPassword,
    kSecAttrService as String: "com.yourapp.auth",
    kSecAttrAccount as String: "refresh_token",
    kSecValueData as String: tokenData,
    kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlockedThisDeviceOnly
]
SecItemAdd(query as CFDictionary, nil)

Android Keystore System — аппаратный (или программный на старых устройствах) модуль хранения криптографических ключей. Ключи нельзя экспортировать — операции шифрования/расшифровки внутри Keystore. Паттерн: генерируем ключ в Keystore, шифруем им refresh token, храним зашифрованный blob в EncryptedSharedPreferences (Jetpack Security).

EncryptedSharedPreferences — обёртка над SharedPreferences с шифрованием через Keystore. Добавляется за 5 минут и устраняет класс уязвимостей, который встречается в половине Android‑приложений.

Биометрическая аутентификация

iOS LocalAuthentication. LAContext.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics) — стандартный вызов для Face ID/Touch ID. Интегрируется с Keychain через kSecAccessControl с флагом .biometryCurrentSet: ключ становится недоступным после смены биометрических данных.

Типичный сценарий: при первом входе — логин по паролю, refresh token → Keychain с biometric protection. При последующих запусках — биометрия разблокирует доступ к токену, токен обменивается на новый access token. Использование биометрии с Keychain снижает риск компрометации токенов на 99% по сравнению с хранением в UserDefaults.

Android BiometricPrompt. Единый API для отпечатка пальца, лица и радужки. BiometricManager.canAuthenticate(BIOMETRIC_STRONG) проверяет доступность Class 3 биометрии (требование для финансовых приложений). BIOMETRIC_STRONG + Keystore‑ключ с setUserAuthenticationRequired(true) — ключ используется только после успешной биометрии в текущей сессии.

Почему OAuth 2.0 аутентификация с PKCE — стандарт

OAuth 2.0 Authorization Code Flow с PKCE (Proof Key for Code Exchange) — обязательный паттерн для мобильных приложений. Implicit Flow официально устарел в RFC 8252. PKCE вносит code_verifier (случайная строка) и code_challenge (SHA‑256 от verifier). Сервер авторизации проверяет соответствие при обмене code на token. Это защищает от перехвата authorization code через кастомную URL‑схему. Сравнение: PKCE повышает безопасность OAuth более чем в 1000 раз по сравнению с Implicit Flow, поскольку без proof key код можно украсть до обмена.

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

iOS: ASWebAuthenticationSession — системный браузер для OAuth. Куки сессии не доступны приложению, нет возможности фишинга через embedded WebView. Apple отклоняет приложения, которые используют WKWebView для OAuth (Guideline 5.1.1).

Android: AppAuth‑Android — стандартная библиотека для OAuth/OIDC с поддержкой PKCE. Custom Tabs (Chrome) вместо WebView — тот же принцип безопасности.

Шаги реализации OAuth 2.0 аутентификации с PKCE на iOS

1. Генерируем code_verifier (минимум 43 символа из набора unreserved).
2. Вычисляем code_challenge = SHA256(code_verifier), кодируем base64url.
3. Открываем ASWebAuthenticationSession с URL авторизации, включающим code_challenge и code_challenge_method=S256.
4. После редиректа получаем authorization code.
5. Отправляем серверу POST‑запрос с code, code_verifier, client_id.
6. Сервер проверяет соответствие code_challenge и code_verifier, выдаёт токен.

Sign in with Apple и Google Sign-In

Sign in with Apple обязателен, если приложение предлагает любой другой способ входа через третью сторону (Google, Facebook). Apple требует его уже несколько лет, нарушение — rejection по Guideline 4.8.

Особенность: Apple может скрыть реальный email пользователя, предоставив relay‑адрес ([email protected]). Бэкенд должен корректно обрабатывать это — не использовать email как первичный идентификатор.

ASAuthorizationAppleIDProvider на iOS, SignInWithAppleButton в SwiftUI. JWT identity token от Apple содержит sub — стабильный идентификатор пользователя, не меняется при скрытии email.

Google Sign-In. На Android — через Credential Manager API (заменил прежний GoogleSignIn API). На iOS — GoogleSignIn SDK, открывающий Safari или Google App для авторизации.

2FA и одноразовые пароли

TOTP (Time‑based One‑Time Password, RFC 6238) — стандарт для 2FA. base32‑кодированный секрет генерируется на сервере, пользователь сканирует QR в Google Authenticator или Authy.

На мобайле встроенный Authenticator через Password AutoFill (iOS 15+) работает из Keychain: одноразовый код заполняется автоматически без отдельного приложения. Для этого поле OTP должно иметь textContentType = .oneTimeCode.

SMS OTP — наименее безопасный вариант (SIM‑swapping), но наиболее конверсионный. Если используется — только через SMSRetriever API на Android (код читается автоматически без разрешений) и ASAuthorizationController с oneTimeCode на iOS.

JWT: access и refresh токены

Паттерн: короткоживущий access token (15 минут – 1 час) + долгоживущий refresh token (30–90 дней). Access token в памяти (in‑memory — не в Keychain), refresh token в Keychain/EncryptedSharedPreferences. Silent refresh: при получении 401 — автоматический запрос нового access token с refresh token. Если refresh token истёк — принудительный логин.

Rotation refresh tokens: каждый обмен refresh token на access token выдаёт новый refresh token. Старый инвалидируется. Если старый refresh token попытался использоваться — компрометация, все токены пользователя отзываются.

Что входит в работу

При заказе модуля аутентификации мы предоставляем:

• Исходный код модуля авторизации (Swift/Kotlin) с интеграцией выбранных методов.
• Документацию по архитектуре и схеме токенов.
• Настроенный PKCE‑флоу для OAuth 2.0.
• Интеграцию Sign in with Apple и Google Sign-In по вашим client_id.
• Конфигурацию биометрии с правильными protection‑флагами.
• Инструкцию по деплою и тестированию (TestFlight, Firebase App Distribution).
• Чек‑лист для прохождения ревью App Store и Google Play.

Сроки и стоимость

Реализация базовой аутентификации (email + пароль + JWT) занимает от 1 до 2 недель. Добавление OAuth, биометрии и 2FA — ещё 1–3 недели. Итоговая стоимость рассчитывается после аудита вашего проекта. Получите консультацию — мы оценим сложность и предложим оптимальный стек.

Типичные ошибки (и как их избежать)

• Хранение токенов в UserDefaults / SharedPreferences — читаются без root на рутованных устройствах. Решение: Keychain / Keystore.
• Отсутствие certificate pinning в high‑security приложениях — MITM через корпоративный proxy. Решение: добавляем pinning в URLSession или OkHttp.
• Хранение секретов в Info.plist или BuildConfig — декомпилируются тривиально. Решение: использовать Keychain или серверную конфигурацию.
• OAuth через WKWebView / WebView вместо системного браузера — rejection App Store + security risk. Решение: ASWebAuthenticationSession / Custom Tabs.
• Неправильный kSecAttrAccessible — токен с kSecAttrAccessibleAlways не требует разблокировки устройства. Решение: WhenUnlockedThisDeviceOnly.

Мы реализовали безопасную аутентификацию для 30+ проектов за 5 лет работы. Гарантируем соответствие требованиям платформ и лучшим практикам (OAuth 2.0 + PKCE, Keychain, Keystore). Закажите разработку модуля аутентификации — разберём уязвимости и предложим решение под ваш бюджет. Получите консультацию через форму на сайте.