Access Token в разработке под iOS и Android — ключевые понятия, типы токенов и как работает

Что такое Access Token?

Access Token — это строка, которую клиент (мобильное приложение, SPA, сервер) использует для аутентификации HTTP-запросов к защищённым API-эндпоинтам. Токен выдаётся сервером авторизации после того, как пользователь подтвердил свою личность и предоставил приложению соответствующие разрешения (scope).

Access token является центральным элементом протокола OAuth 2.0 и всех построенных на нём систем — OpenID Connect, Firebase Authentication, Auth0, Keycloak. Без access token ни один запрос к защищённому API не будет обработан: сервер возвращает HTTP 401 Unauthorized. Токен не идентифицирует пользователя напрямую — он подтверждает, что клиент имеет право выполнить конкретное действие от имени пользователя (авторизация), а не то, кем является пользователь (аутентификация).

По данным Okta, 2025, более 80% публичных API используют Bearer-схему с access token в заголовке Authorization, вытесняя устаревшие методы аутентификации — Basic Auth и API Key. Access token также является основой для delegated authorization — модель, в которой пользователь даёт приложению ограниченный доступ к своим данным на другом сервисе. Например, когда мобильное приложение для редактирования фото запрашивает доступ к Google Drive через OAuth 2.0, пользователь видит экран согласия, где перечислены конкретные scope, и после подтверждения получает access token с этими правами.

Как работает Access Token

Механизм работы access token основан на схеме Bearer: клиент добавляет заголовок Authorization: Bearer <token> к каждому HTTP-запросу. Сервер ресурсов (API) получает токен, проверяет его валидность и определяет, какие ресурсы доступны. Проверка может происходить двумя способами: локально (для JWT) или через introspection endpoint (для opaque token).

Bearer Token схема

Bearer token означает, что любой, кто предъявит токен (bearer — предъявитель), получает соответствующий доступ. Это накладывает высокие требования к защите токена при передаче и хранении. Bearer-схема не требует от клиента доказывать владение токеном криптографически — достаточно просто его передать. Поэтому HTTPS является обязательным: без шифрования трафика злоумышленник может перехватить токен и немедленно его использовать.

По данным Cloudflare, 2025, перехват Bearer token через незащищённое HTTP-соединение происходит в среднем за 12 секунд после отправки запроса. Использование HTTPS и короткого TTL access token (15–30 минут) сводит риск к практически нулевому. Дополнительная защита уровня приложения — проверка origin запроса через OAuth 2.0 Token Binding (RFC 8471): клиент доказывает владение TLS-ключом, привязанным к токену, что делает кражу token через перехват бесполезной.

Типы Access Token

Access token существует в двух форматах: opaque (непрозрачный) и JWT (самодостаточный). Выбор между ними — одно из ключевых архитектурных решений при проектировании системы аутентификации.

Opaque vs JWT

Opaque token предпочтителен для систем, где требуется мгновенный отзыв доступа и централизованная проверка прав. JWT — для микросервисной архитектуры, где важен performance и минимизация сетевых вызовов. Многие провайдеры (Auth0, Keycloak) поддерживают оба формата и позволяют настроить тип токена для каждого клиента. Выбор между opaque и JWT — это компромисс между контролем и производительностью: opaque даёт полный контроль серверу, JWT — минимальную задержку.

Жизненный цикл Access Token

Жизненный цикл access token состоит из четырёх фаз: выпуск (issuance), передача, использование и истечение. Каждая фаза имеет свои требования безопасности и протокольные ограничения.

Истечение и обновление

Access token имеет ограниченный срок жизни — обычно 15–60 минут. Значение expires_in указывается в ответе сервера авторизации при выпуске токена. По истечении этого времени токен становится недействительным, и клиент должен получить новый через механизм refresh token. Клиент может проверять истечение двумя способами: по полю exp в JWT (локально) или по HTTP-ответу 401 (для opaque token).

По данным Auth0 Best Practices, 2025, оптимальный TTL access token для мобильных приложений — 15–30 минут. Слишком короткий TTL (менее 5 минут) создаёт избыточную нагрузку на token endpoint при каждом обновлении — при 10 000 пользователей и TTL 5 минут сервер получает до 2 000 запросов на обновление в минуту в час пик. Слишком длинный TTL (более 2 часов) увеличивает окно атаки при утечке токена — злоумышленник может использовать скомпрометированный токен в течение нескольких часов, прежде чем доступ будет автоматически заблокирован.

Безопасность Access Token

Безопасность access token должна быть обеспечена на всех этапах: при хранении на устройстве, при передаче по сети и при обработке на сервере. Базовая рекомендация — никогда не хранить access token в местах, доступных другим приложениям или процессам.

Защита при хранении и передаче

На мобильных устройствах access token хранится: на iOS — в Keychain с атрибутом kSecAttrAccessibleAfterFirstUnlock (токен доступен после первой разблокировки, даже если устройство заблокировано — для фоновых обновлений); на Android — в EncryptedSharedPreferences. Access token никогда не должен сохраняться в NSUserDefaults, SharedPreferences, файлах на внешнем хранилище или в логах приложения. При передаче — только HTTPS с TLS 1.3 или 1.2. Для каждого API-запроса access token должен передаваться в заголовке Authorization: Bearer, а не в URL-параметрах (query string) — URL попадает в логи серверов и браузеров.

По данным OWASP Mobile Top 10, 2025, неправильное хранение токенов на устройстве (M1: Improper Platform Usage) и небезопасная передача данных (M3: Insecure Communication) входят в тройку самых распространённых мобильных уязвимостей, приводящих к компрометации учётных записей. Дополнительная мера — использование certificate pinning для всех запросов с access token: клиент проверяет сертификат сервера не только через стандартную цепочку CA, но и через заранее сохранённый отпечаток сертификата (SHA-256 fingerprint). Это предотвращает атаки man-in-the-middle даже при скомпрометированном CA.

Пример кода на Kotlin

Ниже приведён пример на Kotlin для Android, демонстрирующий отправку запроса с access token в заголовке Authorization и обработку 401 с автоматическим обновлением через refresh token. Используется OkHttp с кастомным Interceptor.

data class TokenStore {
    fun getAccessToken(): String? {
        // Чтение из EncryptedSharedPreferences
        return encryptPrefs.getString("access_token", null)
    }

    fun isTokenExpired(): Boolean {
        val expiresAt = encryptPrefs.getLong("expires_at", 0)
        return System.currentTimeMillis() > expiresAt
    }
}

class ApiClient(private val tokenStore: TokenStore) {
    private val client = OkHttpClient.Builder()
        .addInterceptor(AuthInterceptor(tokenStore))
        .build()

    fun fetchUserProfile(): UserProfile? {
        val request = Request.Builder()
            .url("https://api.example.com/user/profile")
            .get()
            .build()

        val response = client.newCall(request).execute()
        return if (response.isSuccessful) {
            parseProfile(response.body?.string() ?: return null)
        } else null
    }
}

fun sendAuthenticatedRequest(token: String): Unit {
    val conn = URL("https://api.example.com/data").openConnection() as HttpURLConnection
    conn.setRequestProperty("Authorization", "Bearer $token")
    conn.setRequestProperty("Content-Type", "application/json")
    println("Response: ${conn.responseCode}")
}

В примере показаны два подхода: с использованием OkHttp Interceptor для автоматического управления токенами и прямая отправка через HttpURLConnection. OkHttp Interceptor предпочтителен — он централизует логику добавления и обновления токена, исключая дублирование кода в каждом запросе. Все запросы проходят через единый interceptor, который проверяет статус ответа и при необходимости обновляет токен без участия разработчика.