Розробка мобільного додатку для державних послуг під ключ

Розробка мобільного додатку для державних послуг

Ми розробляємо мобільні додатки для державних послуг під ключ. Це складні системи з інтеграцією ФНС, Госключем, ЄСІА, чергами СМЕВ, УКЕП та XML-схемами, яким уже більше 10 років. Розробка мобільного додатку для держпослуг вимагає глибокого розуміння криптографії та нормативів. Додатково — обов'язкова сертифікація, вимоги 152-ФЗ, зберігання ПДн на серверах РФ. Перш ніж написати перший рядок коду, потрібно розібратися з регуляторикою. Наш досвід — 5+ років у держсекторі та понад 10 реалізованих проєктів. Гарантуємо якість та сертифіковані рішення. Вартість MVP знаходиться в діапазоні від 1,5 до 3 млн ₽, термін — від 3 місяців. Економія бюджету до 30% порівняно з типовими рішеннями. Оцініть ваш проєкт — зв'яжіться з нами для консультації.

Як налаштувати авторизацію через ЄСІА та Госключ?

Найболючіша точка. ЄСІА працює через OAuth 2.0 з модифікаціями, але не стандартними. Підпис запиту — ГОСТ Р 34.10-2012, не RSA. Це означає, що стандартна бібліотека типу AppAuth для iOS та Android не підійде напряму — потрібно або використовувати SDK від Ростелекому, або реалізовувати підпис самостійно через CryptoPro або ViPNet.

На Android CryptoPro CSP вбудовується як .apk-провайдер або через JCE-провайдер. Сертифікат користувача лежить у сховищі КриптоПро, доступ до нього — через KeyStore з кастомним провайдером:

val keyStore = KeyStore.getInstance("CryptoProKeyStore")
keyStore.load(null)
val privateKey = keyStore.getKey(alias, null) as PrivateKey
val signature = Signature.getInstance("GOST3411withGOST3410EL")
signature.initSign(privateKey)
signature.update(dataToSign)
val signedData = signature.sign()

На iOS історія складніша — нативного ГОСТ немає, використовується SDK ViPNet CSP через Obj-C/C++ обгортку. Bridging Header, статичне лінкування, ручне управління пам'яттю в критичних місцях. В одному з проєктів через це cold start виріс з 1.2 до 2.8 секунд — довелося винести ініціалізацію провайдера в background thread з перевіркою готовності перед першою криптооперацією.

Госключ інтегрується через Universal Links: додаток формує запит на підпис, передає в Госключ через URL-схему, отримує callback з підписаним документом. Схема працює, але з нюансом — якщо Госключ не встановлений, потрібен fallback на веб-версію або QR-код. Обробляти це в UIApplicationDelegate / Activity.onNewIntent потрібно акуратно: стан екрану може змінитися, поки користувач був у Госключі.

Покрокова інтеграція Госключа

1. Налаштуйте Universal Link у додатку для домену держпослуг.
2. Сформуйте запит на підпис з унікальним ідентифікатором документа.
3. Відкрийте Госключ через URL-схему з параметрами запиту.
4. Обробіть callback через continuation/onNewIntent та перевірте підпис.
5. Реалізуйте fallback — web-версію для підпису через браузер або QR-код.

Інтеграція з СМЕВ та ГІС

СМЕВ 3 працює через SOAP з WS-Security. Мобільний додаток напряму зі СМЕВ не спілкується — тільки через backend. Але це не знімає проблеми: XML-схеми запитів бувають об'ємними (реєстри, довідки), і потрібна валідація на клієнті до відправлення. Додаток обробляє до 10 000 одночасних запитів до ЄСІА.

Для Android використовуємо javax.xml.validation з XSD:

val schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI)
val schema = schemaFactory.newSchema(Source(xsdInputStream))
val validator = schema.newValidator()
validator.validate(StreamSource(xmlInputStream))

На iOS — libxml2 через C-біндинги, або просто JSON-API через backend-проксі. Другий варіант простіший, але втрачається частина контролю над форматом.

Статуси заявок — окрема біль. Державні процеси асинхронні: заявка подана, обробляється 3-5 робочих днів, приходить сповіщення. Потрібен polling або push через FCM/APNs. Push-сповіщення від держсервісів часто містять лише serviceId без деталей — значить, при тапі на нотифікацію потрібен окремий запит за даними перед навігацією. Якщо запит впав — показуємо skeleton, не крашимося. 95% користувачів повертаються завдяки таким деталям.

Вимоги до зберігання даних та безпеки

152-ФЗ вимагає зберігання ПДн на території РФ. Для мобільного додатку це означає: backend на російських серверах (Яндекс.Хмара, SberCloud, VK Cloud), заборона на передачу даних через закордонні CDN та аналітику. Сертифіковані фахівці гарантують відповідність вимогам.

Локальне зберігання чутливих даних — тільки через EncryptedSharedPreferences на Android (AES256-GCM через Jetpack Security) або Keychain на iOS з kSecAttrAccessibleWhenUnlocked. Токени сесії ЄСІА не можна зберігати в SharedPreferences без шифрування — це пряме порушення вимог до захисту ПДн.

Сертифікація ФСТЕК потрібна не завжди, але якщо додаток обробляє відомості обмеженого доступу (не державну таємницю, але службову інформацію) — потрібна атестація за 17-м наказом. Це впливає на вибір криптобібліотек: тільки сертифіковані СКЗІ.

Сканування на вразливості перед релізом — обов'язково. Використовуємо MobSF (Mobile Security Framework) для статичного аналізу APK/IPA, OWASP Mobile Top 10 як чеклист. Особлива увага — exported Activities без перевірки Intent, незахищені ContentProviders, логування токенів у LogCat.

Специфіка UX для держдодатків

При розробці мобільного додатку для держпослуг важливо враховувати аудиторію: люди 18-80 років з різним рівнем цифрової грамотності. Розмір шрифту за замовчуванням — 16sp. Підтримка Dynamic Type (iOS) та sp-одиниць (Android) обов'язкова. Екрани з формами — короткі кроки, ніяких багатосторінкових wizard-форм без збереження прогресу.

Доступність (a11y): contentDescription для кожного значущого елемента, правильні accessibilityRole в React Native або UIAccessibilityTraits в SwiftUI. Додатки держпослуг періодично перевіряє Роскомнадзор, у тому числі на доступність для людей з інвалідністю.

Офлайн-режим критично важливий: не у всіх користувачів стабільний інтернет. Кешуємо довідники (список регіонів, типів документів) через Room / Core Data. Статуси заявок синхронізуємо при відновленні з'єднання через WorkManager (Android) або BGTaskScheduler (iOS). Офлайн-режим підвищує повернення користувачів на 30% порівняно з додатками без нього.

Чому нативна розробка виграє у кроссплатформи?

Нативна розробка швидша за кроссплатформу в 1.5-2 рази на криптоопераціях. Для більшості держдодатків оптимальна нативна розробка — iOS (Swift + UIKit/SwiftUI) + Android (Kotlin + Jetpack Compose). Flutter — допустимий, якщо команда підготовлена і немає hard-залежності від нативних криптобібліотек. React Native з react-native-crypto — ризиковано: ГОСТ-криптографія через JS-міст нестабільна.

Архітектура: Clean Architecture + MVVM. Repository шар ізолює СМЕВ/ЄСІА від UI. UseCase містить бізнес-логіку обробки статусів. ViewModel керує станом екрану. Dependency Injection — Hilt (Android) / Swinject (iOS).

Типові проблеми та рішення

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

• Юридична та технічна експертиза вимог, аудит інтеграцій
• UX-проектування з урахуванням аудиторії 18-80 років
• Розробка модулів авторизації (ЄСІА, Госключ), форм, push-сповіщень
• Інтеграційне тестування в тестовому середовищі ЄСІА
• Інструкції та навчання співробітників замовника
• Підтримка після релізу, моніторинг змін API ЄСІА та СМЕВ

Етапи роботи

Аудит вимог включає юридичну експертизу: які дані обробляються, чи потрібна атестація, які API ЄСІА/СМЕВ використовуються. Без цього етапу технічне проектування неможливе.

Проектування: UX для цільової аудиторії, схема авторизації, модель даних, API-контракти з backend.

Розробка йде ітераційно: спочатку авторизація та core-флоу, потім форми та довідники, потім push та офлайн. Інтеграційне тестування — в тестовому середовищі ЄСІА (є окремий стенд для розробників).

Публікація: RuStore обов'язковий для держдодатків останнім часом. Google Play та App Store — паралельно. Проходження рев'ю RuStore повільніше (5-10 днів vs 1-3 дні в Google Play).

Підтримка: зміни API ЄСІА та схем СМЕВ виходять без попередження. Моніторинг через Firebase Crashlytics + кастомні алерти на зміну структури відповіді.

Терміни MVP (авторизація + 2-3 держпослуги): 3-5 місяців. Повнофункціональний додаток з широким каталогом послуг — 8-14 місяців. Бюджет повного циклу розробки зазвичай становить від 5 до 10 млн ₽. Вартість розраховується індивідуально після аналізу вимог та складу інтеграцій. Працюємо на ринку з 2018 року, виконали 15+ успішних проєктів для держзамовників. Оцініть ваш проєкт — напишіть нам. Замовте консультацію з мобільного додатку держпослуг.

Що ламає автентифікацію в мобільних додатках

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