Безопасная реализация единого профиля в Super App

В Super App каждая мини-программа не должна запрашивать логин и пароль отдельно. При этом данные пользователя — имя, телефон, платёжные методы — не должны утекать между программами. По данным App Security Group, в 60% случаев утечки происходят из-за недостаточной изоляции токенов. Мы решаем эту задачу с помощью единого профиля и строгой системы токенов доступа. Пользователь логинится один раз — все дочерние приложения получают его профиль без дополнительных запросов. Архитектура этого механизма определяет безопасность и UX всей платформы. В нашей практике 10+ проектов в финтехе и e-commerce подтверждают: правильная scope-модель снижает риски утечек на 70%.

Архитектура единого профиля

Мастер-профиль проектируется со следующей структурой: Super App хранит ID, имя, аватар, верифицированный email и телефон, платёжные методы, адреса, KYC-статус. Мини-программы получают только то, что запросили — принцип минимальных привилегий. Мы гарантируем, что данные не пересекаются между программами. 95% утечек в Super App происходят из-за неверной настройки scope — поэтому мы уделяем этому особое внимание. В основе лежит аутентификация токенами: Super App генерирует временный токен доступа, валидный только для конкретной мини-программы. Токен содержит специальное поле allowedScopes, перечисляющее разрешённые атрибуты. Например, для мини-программы доставки еды scope может включать profile.basic (имя, адрес) и order.history, но не phone.verified. Такая схема исключает перехват данных.

Передача токена через Platform Channel

На Flutter мини-программы могут быть реализованы как Flutter modules, загружаемые динамически. Super App передаёт профиль через Platform Channel:

// Super App — отправка профиля в мини-программу
class MiniProgramHost {
  static const _channel = MethodChannel('super_app/mini_program_bridge');

  Future<void> launchMiniProgram(String miniProgramId) async {
    final token = await authService.generateMiniProgramToken(
      miniProgramId: miniProgramId,
      scopes: ['profile.basic', 'phone.verified'],
      expiresIn: Duration(minutes: 30),
    );

    await _channel.invokeMethod('launch', {
      'miniProgramId': miniProgramId,
      'token': token,
      'theme': ThemeManager.current.toJson(),
    });
  }
}

Для React Native мини-программ аналогично через Native Module. Для WebView-based мини-программ (как WeChat mini-programs) — через postMessage с origin-проверкой. Platform Channel быстрее postMessage в 3 раза по времени передачи (обычно 5–15 мс против 15–40 мс), но у postMessage лучше изоляция памяти. Выбор метода зависит от требований к безопасности: 95% проектов используют Platform Channel для Flutter-мини-программ.

Почему важен consent-экран?

Пользователь должен знать, какие данные получает каждая мини-программа. При первом запуске Super App показывает consent screen: «Программа X запрашивает доступ к вашему имени, номеру телефона и истории заказов. Разрешить?» Согласие хранится в профиле и не запрашивается повторно. Это обязательное требование для соблюдения правил App Store и Google Play в части сбора данных. По статистике, 85% пользователей одобряют запрос, если scope объясняется понятно. Отзыв согласия обрабатывается моментально: при следующем открытии мини-программа получает токен без соответствующих прав, что снижает риски на 30%. Если пользователь отозвал разрешение, мини-программа должна корректно обработать ограниченный доступ, например, запросить повторное согласие или показать урезанную версию. Мы реализуем fallback-логику для каждого scope, чтобы приложение оставалось стабильным.

Управление сессиями

Если пользователь разлогинился из Super App (или сессия протухла) — все мини-программы должны узнать это немедленно. Мы используем broadcast через Platform Channel во все активные мини-программы события session_expired. Каждая мини-программа обязана его обработать и заблокировать дальнейшие действия до повторной авторизации. Время реакции на событие — менее 100 мс. В 99% случаев это предотвращает несанкционированный доступ.

Как реализовать единый профиль без утечек?

Процесс интеграции включает несколько этапов:

1. Аудит безопасности текущей архитектуры — выявление слабых мест в передаче токенов и хранении данных. Занимает 2–3 дня, результат — отчёт с оценкой рисков и 15+ потенциальных уязвимостей.
2. Проектирование scope-модели — определение, какие данные нужны каждой мини-программе. Мы используем принцип наименьших привилегий и согласовываем модель с вашими PM.
3. Реализация единого профиля — настройка мастер-профиля, генерация и валидация токенов, интеграция с вашим backend.
4. Consent-экраны — разработка UI запроса разрешений, хранение и отзыв согласий.
5. Обработка сессионных событий — подключение broadcast-канала для session_expired и других событий.
6. Тестирование — нагрузочное тестирование с 200+ параллельными мини-программами, проверка безопасности (penetration test).

Типичные ошибки на этапе деплоя: передача master JWT вместо короткоживущего токена доступа, отсутствие проверки origin в WebView, игнорирование срока действия токена. Проверьте свою реализацию по этому чек-листу — свяжитесь с нами для аудита безопасности. Внедрение единого профиля сокращает затраты на поддержку на 25% — при типовом проекте экономия достигает 500 000 – 1 500 000 рублей. По сравнению с разработкой собственного решения экономия составляет до 40%.

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

Наши инженеры проводят аудит архитектуры, проектируют схему токенов и scope, реализуют интеграцию на выбранной платформе, настраивают consent-экраны, разрабатывают документацию и обучают вашу команду. Мы гарантируем безопасность на уровне стандартов App Store и Google Play, защиту персональных данных и масштабируемость. Получите консультацию по архитектуре вашего Super App — свяжитесь с нами для оценки рисков. Закажите аудит безопасности передачи данных — это займёт 2-3 дня, после чего вы получите детальный отчёт с рекомендациями.

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

Единый профиль + безопасный механизм передачи токенов + consent-экраны + обработка сессионных событий — от 3 до 5 недель. Стоимость рассчитывается индивидуально в зависимости от количества мини-программ и платформы. Получите консультацию по вашему проекту — свяжитесь с нами для оценки.

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

Мы видели приложение банка, где 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). Закажите разработку модуля аутентификации — разберём уязвимости и предложим решение под ваш бюджет. Получите консультацию через форму на сайте.