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 токена кроз незаштићену 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 који проверава статус одговора и по потреби освежава токен без учешћа програмера.