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 також є основою для делегованої авторизації — модель, у якій користувач надає застосунку обмежений доступ до своїх даних на іншому сервісі. Наприклад, коли мобільний застосунок для редагування фотографій запитує доступ до 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 — для мікросервісної архітектури, де важливі продуктивність і мінімізація мережевих викликів. Багато провайдерів (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? {
        // Reading from 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, який перевіряє статус відповіді та при необхідності оновлює токен без участі розробника.