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 минути) свежда риска до практически нула. Допълнителна защита на ниво приложение — проверка на произхода на заявката чрез OAuth 2.0 Token Binding (RFC 8471): клиентът доказва притежанието на TLS ключ, свързан с токена, което прави кражбата на токен чрез прихващане безполезна.

Видове 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? {
        // Четене от 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, който проверява статуса на отговора и при необходимост обновява токена без участие на разработчика.