Безпечна реалізація єдиного профілю в 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. Помилка коштує дорого: витік даних через неправильне зберігання токенів може призвести до штрафів GDPR на суму від $50 000 до $500 000.

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

Як захистити токени при OAuth 2.0 автентифікації?

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

// Збереження в 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. Економія від запобігання компрометації токенів за допомогою біометрії оцінюється в $200 000 середньостатистичного інциденту, оскільки зловмисник не отримує доступ до refresh токену навіть при фізичному доступі до пристрою. Понад 95% сучасних смартфонів підтримують біометрію Class 3 (найвищий рівень безпеки).

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 (випадковий рядок мінімум 43 символи) та code_challenge (SHA‑256 від verifier). Сервер авторизації перевіряє відповідність при обміні code на token. Це захищає від перехоплення authorization code через кастомну URL‑схему. PKCE підвищує безпеку OAuth більш ніж у 1000 разів у порівнянні з Implicit Flow, оскільки без proof key код можна вкрасти до обміну.

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.

Як організувати ротацію refresh токенів?

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 намагалися використати — компрометація, всі токени користувача відкликаються. Ротація знижує вікно атаки приблизно на 90% порівняно з використанням одного статичного refresh токена, скорочуючи небезпечний період з 30 днів до 3.

Найпоширеніші помилки — зберігання токенів у UserDefaults / SharedPreferences (читаються без root на рутованих пристроях), відсутність certificate pinning у high‑security додатках (MITM через корпоративний proxy), зберігання секретів у Info.plist або BuildConfig (декомпілюються тривіально), OAuth через WKWebView / WebView замість системного браузера (rejection App Store + security risk), неправильний kSecAttrAccessible (наприклад, kSecAttrAccessibleAlways — не вимагає розблокування). Усі ці помилки усуваються на етапі проектування.

Що входить в роботу

При замовленні модуля автентифікації ми надаємо:

• Вихідний код модуля авторизації (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 тижні. Підсумкова вартість розраховується після аудиту вашого проєкту. Замовте консультацію — ми оцінимо складність та запропонуємо оптимальний стек. Зв'яжіться з нами для аудиту вашого проекту. Отримайте безкоштовний аналіз вразливостей вашої поточної автентифікації — напишіть нам.