Налаштування SSO (Single Sign-On) для корпоративного мобільного додатку (SAML/OIDC)

TRUETECH займається розробкою, підтримкою та обслуговуванням мобільних додатків iOS, Android, PWA. Маємо великий досвід та експертизу для публікації мобільних додатків до популярних маркетів Google Play, App Store, Amazon, AppGallery та інші.

Розробка та підтримка будь-яких видів мобільних додатків:

Інформаційні та розважальні мобільні програми
Новинки, ігри, довідники, онлайн-каталоги, погодні, фітнес та здоров'я, туристичні, освітні, соціальні мережі та месенджери, квіз, блоги та подкасти, форуми, агрегатори
Мобільні програми електронної комерції
Інтернет-магазини, B2B-додатки, маркетплейси, онлайн-обмінники, кешбек-сервіси, біржі, дропшиппінг-платформи, програми лояльності, доставка їжі та товарів, платіжні системи
Мобільні програми для управління бізнес-процесами
CRM-системи, ERP-системи, управління проектами, інструменти для команди продажів, облік фінансів, управління виробництвом, логістика та доставка, управління персоналом, системи моніторингу даних
Мобільні програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, платформи надання електронних послуг, платформи кешбеку, відеохостинги, тематичні портали, платформи онлайн-бронювання та запису, платформи онлайн-торгівлі

Це лише деякі з типів мобільних додатків, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 1735 послуг
Налаштування SSO (Single Sign-On) для корпоративного мобільного додатку (SAML/OIDC)
Складний
~2-3 дні
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_mobile-applications_feedme_467_0.webp
    Розробка мобільного додатка для компанії FEEDME
    792
  • image_mobile-applications_xoomer_471_0.webp
    Розробка мобільного додатку для компанії XOOMER
    671
  • image_mobile-applications_rhl_428_0.webp
    Розробка мобільного додатку для компанії RHL
    1097
  • image_mobile-applications_zippy_411_0.webp
    Розробка мобільного додатку для компанії ZIPPY
    969
  • image_mobile-applications_affhome_429_0.webp
    Розробка мобільного додатку для компанії Affhome
    914
  • image_mobile-applications_flavors_409_0.webp
    Розробка мобільного додатку для компанії FLAVORS
    495

Конфігурація SSO для корпоративного мобільного додатку (SAML/OIDC)

SSO в корпоративному мобільному додатку — не просто "вхід через корпоративний аккаунт". За цим стоїть інтеграція з Identity Provider (IdP), вибір правильного протоколу, обробка токенів відповідно до корпоративних політик безпеки та коректна обробка сценаріїв примусового виходу.

OIDC vs SAML: вибір протоколу

SAML 2.0 — XML-based протокол з 2005 року. Широко використовується в 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.

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

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

Authorization Code Flow з PKCE — обов'язковий стандарт для мобільних (RFC 8252). Без 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,
            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 ?: "Обмін токену не вдався")
                }
            }
        } else {
            onError(exception?.message ?: "Авторизація не вдалася")
        }
    }
}

На 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)
    }
}

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

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

fun makeApiRequest(url: String) {
    authState.performActionWithFreshTokens(authService) { accessToken, _, exception ->
        if (exception != null) {
            // Refresh не вдався — потрібен повторний логін
            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), але іноді єдиний варіант. Позначаємо це замовнику як технічний борг та рекомендуємо upgrade 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 — різні формати.

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

Конфігурація SSO (OIDC + один IdP): 2–4 тижні. Мультитенантність + кілька IdP + SAML fallback: 5–8 тижнів. Вартість розраховується індивідуально.