Впровадження SSO (SAML/OIDC) у корпоративний мобільний додаток

Користувач входить у корпоративний додаток через портал, але при переході в мобільний додаток вимагається повторна аутентифікація. Це призводить до втрат часу та зниження продуктивності до 30%. Ми інтегруємо єдиний вхід (SSO) у корпоративні мобільні додатки — це не просто «вхід через корпоративний обліковий запис». За цим стоїть інтеграція з Identity Provider (IdP), вибір правильного протоколу, обробка токенів відповідно до корпоративних політик безпеки та коректна обробка сценаріїв примусового logout. Наш досвід: понад 20 впроваджень SSO для enterprise-клієнтів, що дозволяє знизити витрати на підтримку аутентифікації до 40% за рахунок централізованого управління. Окупність такого впровадження — від 6 до 12 місяців. Отримайте консультацію: оцінимо ваш проект за 2 дні.

Як вибрати між OIDC та SAML?

SAML 2.0 — XML-based протокол, широко застосовуваний в enterprise: ADFS, Okta, PingFederate. Для мобільних додатків незручний: SAML Assertions передаються через HTTP POST (browser-based flow), що вимагає WebView або браузерного редиректу. Нативного мобільного SDK для SAML практично немає.

OpenID Connect (OIDC) — надбудова над OAuth 2.0, використовує JWT. Нативно підтримується в мобільних бібліотеках. AppAuth — стандартна реалізація Authorization Code Flow з PKCE для iOS та Android. AppAuth знижує час розробки вдвічі порівняно з самописною реалізацією, а також підвищує безпеку за рахунок вбудованої підтримки PKCE. OIDC працює в 2-3 рази швидше за SAML на мобільних пристроях завдяки компактним JWT-токенам.

Якщо IdP підтримує обидва протоколи (Okta, Azure AD, PingFederate — підтримують), для мобільного вибираємо OIDC. SAML потрібен лише коли IdP змушує: on-premise ADFS без сучасного оновлення, або legacy корпоративна система лише з SAML.

Чому OIDC кращий для мобільних додатків?

OIDC використовує стандарт RFC 8252 — Authorization Code Flow з PKCE обов'язковий для мобільних. Згідно з RFC 8252, це забезпечує захист від перехоплення коду. SAML же вимагає браузерних редиректів і не має нативних мобільних SDK, що сповільнює розробку та знижує безпеку.

Як реалізувати OIDC за 5 кроків

1. Налаштуйте IdP: зареєструйте мобільний додаток, вкажіть redirect URI та дозвольте Authorization Code Flow з PKCE.
2. Підключіть SDK AppAuth: додайте залежність у build.gradle (Android) або через CocoaPods (iOS).
3. Створіть AuthorizationRequest: вкажіть issuer, client_id, redirect URI, scopes (openid, email, profile, offline_access).
4. Запустіть flow: викличте getAuthorizationRequestIntent() та обробіть результат.
5. Збережіть AuthState: серіалізуйте в EncryptedSharedPreferences або Keychain.

Реалізація OIDC через AppAuth

Authorization Code Flow з PKCE — обов'язковий стандарт для мобільних. Жодних implicit flow — вони deprecated.

// Android — AppAuth-Android
class AuthManager(private val context: Context) {
    private val authService = AuthorizationService(context)

    fun startLogin(activity: Activity) {
        val serviceConfig = AuthorizationServiceConfiguration(
            Uri.parse("https://login.microsoftonline.com/$tenantId/oauth2/v2.0/authorize"),
            Uri.parse("https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token"),
            null, // registration
            Uri.parse("https://login.microsoftonline.com/$tenantId/v2.0/.well-known/openid-configuration")
        )

        val request = AuthorizationRequest.Builder(
            serviceConfig,
            BuildConfig.CLIENT_ID,
            ResponseTypeValues.CODE,
            Uri.parse("com.company.app:/oauth2redirect")
        )
            .setScopes(
                AuthorizationRequest.SCOPE_OPENID,
                AuthorizationRequest.SCOPE_EMAIL,
                AuthorizationRequest.SCOPE_PROFILE,
                "offline_access"
            )
            .setPrompt("login") // Не кешувати сесію IdP для корпоративних вимог
            .build()

        val intent = authService.getAuthorizationRequestIntent(request)
        activity.startActivityForResult(intent, RC_AUTH)
    }

    fun handleAuthResponse(data: Intent, onSuccess: (AuthState) -> Unit, onError: (String) -> Unit) {
        val response = AuthorizationResponse.fromIntent(data)
        val exception = AuthorizationException.fromIntent(data)

        if (response != null) {
            authService.performTokenRequest(response.createTokenExchangeRequest()) { tokenResponse, ex ->
                if (tokenResponse != null) {
                    val authState = AuthState(response, tokenResponse, ex)
                    saveAuthState(authState)
                    onSuccess(authState)
                } else {
                    onError(ex?.message ?: "Token exchange failed")
                }
            }
        } else {
            onError(exception?.message ?: "Authorization failed")
        }
    }
}

На iOS аналогічно через AppAuth-iOS:

let configuration = OIDServiceConfiguration(
    authorizationEndpoint: URL(string: "https://login.microsoftonline.com/\(tenantId)/oauth2/v2.0/authorize")!,
    tokenEndpoint: URL(string: "https://login.microsoftonline.com/\(tenantId)/oauth2/v2.0/token")!
)

let request = OIDAuthorizationRequest(
    configuration: configuration,
    clientId: clientId,
    scopes: [OIDScopeOpenID, OIDScopeEmail, OIDScopeProfile, "offline_access"],
    redirectURL: URL(string: "com.company.app:/oauth2redirect")!,
    responseType: OIDResponseTypeCode,
    additionalParameters: nil
)

currentAuthorizationFlow = OIDAuthState.authState(
    byPresenting: request,
    presenting: self
) { authState, error in
    if let authState = authState {
        self.authStateManager.save(authState)
    }
}

Зберігання токенів та автоматичний refresh

AppAuth надає AuthState — об'єкт, який керує токенами та автоматично виконує refresh коли access token закінчується:

fun makeApiRequest(url: String) {
    authState.performActionWithFreshTokens(authService) { accessToken, _, exception ->
        if (exception != null) {
            // Refresh failed — потрібен повторний логін
            navigateToLogin()
            return@performActionWithFreshTokens
        }
        // accessToken гарантовано свіжий
        apiClient.get(url, bearerToken = accessToken)
    }
}

AuthState потрібно серіалізувати та зберігати в EncryptedSharedPreferences (Android) / Keychain (iOS). Жодних SharedPreferences без шифрування — корпоративні MDM-політики це виявляють.

SAML через WebView

Якщо IdP підтримує лише SAML без OIDC-обгортки — використовуємо custom WebView / SFSafariViewController для проходження SAML assertion flow. Backend отримує SAML Assertion, верифікує, створює власний JWT та повертає його клієнту через Deep Link.

Це менш безпечний підхід (credentials проходять через WebView), але іноді єдиний варіант. Відзначаємо це замовнику як технічний борг та рекомендуємо IdP-апгрейд.

Примусовий logout та відкликання сесії

Корпоративна вимога: при звільненні співробітника або компрометації облікового запису — негайне відкликання доступу. Механізм: backend інвалідує refresh token в IdP, наступний performActionWithFreshTokens повертає помилку, додаток перенаправляє на логін.

Для Azure AD: відкликання через Microsoft Graph POST /users/{id}/revokeSignInSessions. Для Okta: POST /api/v1/users/{userId}/sessions.

End-session endpoint — стандартний механізм OIDC для logout з IdP. Важливо його викликати при logout, інакше користувач може повторно увійти без пароля через SSO-cookie в браузері:

fun logout() {
    val endSessionRequest = EndSessionRequest.Builder(serviceConfig)
        .setIdTokenHint(authState.idToken)
        .setPostLogoutRedirectUri(Uri.parse("com.company.app:/logout"))
        .build()

    authService.performEndSessionRequest(endSessionRequest, pendingIntent)
    clearLocalAuthState()
}

Типові проблеми

Clock skew. JWT перевіряється за часом — якщо годинник на пристрої користувача відстає на 5+ хвилин, валідний токен буде відхилено як прострочений. Потрібна обробка помилки з рекомендацією синхронізувати час.

Redirect URI mismatch. Одна з найчастіших помилок на етапі налаштування. Redirect URI в коді (com.company.app:/oauth2redirect) має збігатися до символу з тим, що зареєстровано в IdP. Custom scheme vs Universal Link — різні формати.

Multiple IdP в одній організації. Великі корпорації з історією M&A часто мають кілька IdP. Потрібен механізм виявлення IdP за доменом email (discovery). Підтримується через OIDAuthorizationService.discoverConfiguration(forIssuer:).

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

• Аналіз поточної IdP та корпоративних політик безпеки
• Вибір протоколу (OIDC/SAML) та архітектури інтеграції
• Налаштування Authorization Code Flow з PKCE
• Реалізація зберігання токенів у захищеному сховищі
• Інтеграція механізму token refresh
• Реалізація примусового logout з відкликанням сесій
• Написання документації та передача доступу до тестового середовища
• Навчання команди замовника

Терміни та вартість

Налаштування SSO (OIDC + один IdP): 2–4 тижні. Мультитенантність + кілька IdP + SAML fallback: 5–8 тижнів. Вартість розраховується індивідуально. Отримайте консультацію — оцінимо ваш проект за 2 дні. Замовте впровадження SSO у ваш додаток вже сьогодні.

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

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