Пользователь входит в корпоративное приложение через портал, но при переходе в мобильное приложение требуется повторная аутентификация. Это приводит к потерям времени и снижению продуктивности до 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 снижает время разработки в 2 раза по сравнению с самописной реализацией, а также повышает безопасность за счёт встроенной поддержки 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 | SAML |
|---|---|---|
| Поддержка мобильных SDK | Нативная (AppAuth) | Отсутствует, только WebView |
| Формат токенов | JWT (компактный) | XML-утверждения (громоздкий) |
| PKCE | Встроенная поддержка | Не поддерживается |
| Простота внедрения | Высокая | Низкая (необходим WebView) |
Как реализовать OIDC за 5 шагов
- Настройте IdP: зарегистрируйте мобильное приложение, укажите redirect URI и разрешите Authorization Code Flow с PKCE.
-
Подключите SDK AppAuth: добавьте зависимость в
build.gradle(Android) или через CocoaPods (iOS). - Создайте AuthorizationRequest: укажите issuer, client_id, redirect URI, scopes (openid, email, profile, offline_access).
-
Запустите flow: вызовите
getAuthorizationRequestIntent()и обработайте результат. - Сохраните 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-политики это обнаруживают.
Детали хранения токенов
Для Android используем EncryptedSharedPreferences из библиотеки AndroidX Security. Они шифруют данные с помощью AES256 и привязывают к устройству через Android Keystore. На iOS используем Keychain Services — стандартный защищённый контейнер для паролей и токенов. Настройка занимает 1-2 дня.
| Платформа | Защищённое хранилище | Шифрование |
|---|---|---|
| Android | EncryptedSharedPreferences | AES256 (Tink) |
| iOS | Keychain Services | AES256 (CommonCrypto) |
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 в ваше приложение уже сегодня.