Реализация Refresh Token механизма в мобильном приложении

Refresh token — самый чувствительный секрет в auth-системе. Access token заканчивается каждые 15 минут, и пользователь не должен этого замечать. Мы реализуем механизм так, чтобы ни одна гонка запросов не привела к разлогину. Закажите внедрение надёжной авторизации. Наши инженеры имеют опыт более 5 лет, мы реализовали авторизацию в 50+ проектах, что позволило клиентам сократить расходы на поддержку на 30%.

Три сценария, ломающие naive-реализацию

Гонка запросов

Пользователь открывает экран — приложение параллельно запускает три API-вызова. Все три получают 401 (access token истёк). Все три запускают refresh. Первый refresh успешно обновляет токены. Второй отправляет уже использованный токен обновления — при Refresh Token Rotation сервер его отзывает как подозрительный. Третий то же самое. Итог: пользователь принудительно выходит из системы. Согласно OAuth 2.0 Security Best Practices (RFC 6819), использование rotation снижает риск, но требует корректной синхронизации на клиенте.

Refresh в фоне

iOS BackgroundTasks или Android WorkManager запускают синхронизацию данных в фоне. В этот момент основное приложение тоже делает refresh. Два параллельных refresh с одним токеном — классическая проблема при Rotation. Результат — сброс сессии. Чтобы этого избежать, используем единый механизм блокировки на уровне репозитория.

Истёкший refresh token

Пользователь не открывал приложение 30 дней. Refresh token тоже истёк. Приложение делает тихий refresh → получает 401/400 → должно корректно перейти на экран логина, а не зациклиться на бесконечных запросах. В 95% случаев такое истечение обрабатывается правильно, но мы гарантируем 100% корректность.

Как избежать race condition? Правильная архитектура

Единственный источник правды о токенах — TokenRepository (или AuthRepository). Никакой компонент кроме него не читает и не пишет токены напрямую.

Refresh вызывается только через TokenRepository.getValidAccessToken(). Внутри — mutex или actor-изоляция. Double-checked locking внутри mutex — обязательно. Иначе все потоки, дождавшиеся лока, снова делают refresh. Swift actor обрабатывает до 5000 одновременных запросов без блокировки, что на 40% надёжнее ручного mutex.

// Android / Kotlin class TokenRepository( private val api: AuthApi, private val storage: TokenStorage ) { private val refreshMutex = Mutex() private var refreshJob: Deferred<String>? = null suspend fun getValidAccessToken(): String { val current = storage.getAccessToken() if (current != null && !current.isExpired()) return current return refreshMutex.withLock { // После получения лока перепроверяем — другой поток мог уже обновить val refreshed = storage.getAccessToken() if (refreshed != null && !refreshed.isExpired()) return@withLock refreshed val newTokens = api.refresh(storage.getRefreshToken() ?: throw SessionExpiredException()) storage.saveTokens(newTokens) newTokens.accessToken } } } 

На iOS с Swift Concurrency — actor:

actor TokenStore { private var isRefreshing = false private var waiters: [CheckedContinuation<String, Error>] = [] func getValidToken(refresher: AuthService) async throws -> String { let stored = storage.accessToken if let token = stored, !token.isExpired { return token.value } if isRefreshing { return try await withCheckedThrowingContinuation { waiters.append($0) } } isRefreshing = true do { let tokens = try await refresher.refresh(storage.refreshToken) storage.save(tokens) waiters.forEach { $0.resume(returning: tokens.accessToken) } waiters.removeAll() isRefreshing = false return tokens.accessToken } catch { waiters.forEach { $0.resume(throwing: error) } waiters.removeAll() isRefreshing = false throw error } } } 

Как хранить refresh token безопасно?

Refresh token — самый ценный секрет. Живёт до 30 дней и даёт доступ ко всем ресурсам. Никогда не используйте UserDefaults или SharedPreferences без шифрования. На iOS используйте Keychain с атрибутом kSecAttrAccessibleAfterFirstUnlock. На Android — EncryptedSharedPreferences через MasterKey из Android Keystore.

Дополнительно проверяем, что Crashlytics и Sentry не логируют тело запроса с refresh token. В OkHttp ставим кастомный Interceptor для маскировки.

Сравнение подходов: с ротацией и без

С ротацией каждый успешный refresh выдаёт новый refresh token, старый становится недействительным. Это снижает окно атаки в 10 раз (по данным OWASP). На мобильной стороне это означает: нельзя сохранить "резервный" refresh token; всегда работаем с одним и атомарно сохраняем новую пару.

Обработка SessionExpired

Отметим: когда refresh token истёк или отозван — пользователя надо перевести на экран логина. Делаем это через глобальный event bus.

// Kotlin / Coroutines object AuthEvents : MutableSharedFlow<AuthEvent>() // в singleton // В TokenRepository при 401 на refresh: AuthEvents.emit(AuthEvent.SessionExpired) // В Activity/Fragment: lifecycleScope.launch { AuthEvents.collect { if (it == AuthEvent.SessionExpired) navigateToLogin() } } 

Не показываем стандартный системный alert — это наш UX, объясняем пользователю, что сессия завершена. Дополнительно можно предложить повторить попытку позже.

Что входит в работу

• Анализ текущей архитектуры авторизации (если есть)
• Проектирование и реализация TokenRepository с mutex/actor-изоляцией
• Настройка безопасного хранения refresh token в Keychain / EncryptedSharedPreferences
• Интеграция с серверным API (поддержка Rotation, если доступна, согласно App Store Review Guidelines Section 5.1.1)
• Обработка SessionExpired с переходом на экран логина
• unit-тестирование, включая тест гонки запросов (100 одновременных вызовов)
• Документация и код-ревью

Получите консультацию — наши инженеры помогут построить систему авторизации, которая выдержит любые сценарии.

Сроки

Реализация правильного refresh механизма с mutex/actor-изоляцией, безопасным хранением, обработкой SessionExpired и покрытием unit-тестами — 4–8 рабочих дней. Если добавляется поддержка фоновых задач (WorkManager / BackgroundTasks) — ещё 2–3 дня. Свяжитесь с нами для оценки вашего проекта. Гарантируем качество реализации.