Настройка 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 (Single Sign-On) для корпоративного мобильного приложения (SAML/OIDC)

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

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, // 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:).

Настройка SSO (OIDC + один IdP): 2-4 недели. Мультитенантность + несколько IdP + SAML fallback: 5-8 недель. Стоимость рассчитывается индивидуально.