Реализация OAuth 2.0 для мобильного приложения
Мы часто видим проекты, где авторизация OAuth 2.0 реализована через устаревшие или небезопасные схемы. Мы используем Authorization Code Flow с PKCE — единственный корректный вариант для нативных приложений. Implicit Flow deprecated с выходом RFC 9700, а Client Credentials не даёт пользовательского контекста. Если вам предлагают Implicit Flow для мобильного приложения — это тревожный сигнал.
Как работает PKCE?
PKCE (Proof Key for Code Exchange) решает проблему отсутствия client_secret в мобильном коде. Приложение генерирует случайный code_verifier, хеширует его SHA-256 и передаёт code_challenge на сервер авторизации. При обмене кода на токен сервер проверяет, что verifier соответствует challenge. Перехватить код и использовать без verifier невозможно.
// iOS - генерация verifier
var buffer = [UInt8](repeating: 0, count: 32)
_ = SecRandomCopyBytes(kSecRandomDefault, buffer.count, &buffer)
let verifier = Data(buffer).base64URLEncodedString()// Android
val bytes = ByteArray(32)
SecureRandom().nextBytes(bytes)
val verifier = Base64.encodeToString(bytes, Base64.URL_SAFE or Base64.NO_PADDING or Base64.NO_WRAP)Universal Links vs Custom URL Scheme для OAuth 2.0
Схема вида myapp://callback может быть перехвачена любым приложением, зарегистрировавшим такой же идентификатор. Universal Links на iOS и App Links на Android проверяют цифровые сертификаты домена через apple-app-site-association или assetlinks.json. Только ваш сайт может быть авторизован для открытия приложения.
Настройка этого механизма требует:
- AASA-файл на
https://yourapp.com/.well-known/apple-app-site-association - Capability
Associated Domainsсapplinks:yourapp.com - Обработка URL в
scene(_:continue:)илиapplication(_:continue:restorationHandler:)
Библиотеки для OAuth 2.0 в мобильном приложении
Не реализуйте протокол с нуля. AppAuth (iOS/Android), react-native-app-auth, flutter_appauth берут на себя PKCE, открытие браузера и обработку redirect. AppAuth надёжнее и быстрее самостоятельной реализации — сокращает время разработки в 3 раза и исключает типовые уязвимости.
| Библиотека | Платформа | PKCE | Стоимость интеграции |
|---|---|---|---|
| AppAuth | iOS / Android | Да | $80–150 |
| react-native-app-auth | React Native | Да | $100–180 |
| flutter_appauth | Flutter | Да | $100–180 |
Хранение токенов
Краткоживущий токен держите в оперативной памяти (например, @State в SwiftUI). Refresh token — в защищённом хранилище: Keychain на iOS, EncryptedSharedPreferences на Android. Перехват такого токена из SharedPreferences на рутованном устройстве — реальный вектор атаки.
Ротация refresh token и обнаружение компрометации
Ротация refresh token — обязательная практика для продакшн-приложений. При каждом успешном обмене сервер выдаёт новый access token, а прежний refresh token немедленно инвалидируется. Если злоумышленник похитил токен и попытается воспользоваться уже недействительным, сервер обнаружит коллизию и отзовёт всю сессию целиком. Keycloak включает ротацию через revokeRefreshToken: true, AWS Cognito — через параметр Refresh Token Revocation.
Рекомендуемый срок жизни: токен доступа — 15–60 минут, refresh token — 30–90 дней с sliding-window продлением при каждом использовании. Обязательно реализуйте logout с отзывом токена на сервере — вызов /revoke endpoint по RFC 7009. Долгоживущий токен обновления без отзыва при выходе — наиболее частый источник компрометации аккаунтов в мобильных приложениях.
Обработка state и защита от CSRF
State-параметр — случайная строка, которую приложение передаёт в authorization request и проверяет в redirect. Без проверки state возможна CSRF-атака: злоумышленник подставляет чужой код авторизации, и приложение связывает его аккаунт с сессией жертвы. AppAuth генерирует и валидирует state автоматически. Если вы пишете OAuth-клиент вручную — state обязателен. Audit-логирование каждого запроса авторизации с device fingerprint, IP и User-Agent позволяет обнаруживать аномалии. Наш опыт в 30+ OAuth-интеграциях показывает: именно журналы событий выявляли инциденты несанкционированного доступа в течение нескольких минут. Стоимость полной интеграции OAuth 2.0 с PKCE — от $220–320 в зависимости от количества провайдеров и платформ.
Сравнение OAuth Flows
| Flow | Безопасность | Мобильная поддержка | Статус |
|---|---|---|---|
| Implicit | Низкая (токен в URL) | Нет (RFC 9700 deprecated) | Устарел |
| Authorization Code | Средняя (требует client_secret) | Частично | Редко |
| Authorization Code + PKCE | Высокая | Полная | Рекомендуется |
Пошаговая реализация на iOS
- Установите AppAuth через CocoaPods или SPM.
- Настройте
ASWebAuthenticationSessionдля открытия браузера. - Реализуйте генерацию
code_verifierиcode_challenge. - Обработайте redirect через Universal Links.
- После получения сохраните access-токен в памяти, токен обновления — в Keychain.
- Реализуйте автоматический refresh токена при истечении.
Что входит в работу
Мы предоставляем: документацию по интеграции, доступы к тестовым средам, обучение команды, поддержку на этапе релиза. Наш опыт 5+ лет в мобильной безопасности гарантирует, что ваше решение пройдёт App Store Review (раздел 4.8, 5.1). Реализуем интеграцию под ключ за 5–10 рабочих дней для одного провайдера.
Типичные ошибки: применение Implicit-схемы, хранение токенов в UserDefaults, отсутствие PKCE. Мы проверяем ваш текущий код и оцениваем проект.
