Access Token iOS és Android fejlesztésben — kulcsfogalmak, tokentípusok és működés

Mi az Access Token?

Access Token — egy karaktersorozat, amelyet a kliens (mobilalkalmazás, SPA, szerver) használ a védett API-végpontokhoz intézett HTTP-kérések hitelesítésére. A tokent az engedélyezési szerver állítja ki, miután a felhasználó megerősítette személyazonosságát és megadta a megfelelő engedélyeket (scope) az alkalmazásnak.

Az access token az OAuth 2.0 protokoll és az összes rá épülő rendszer — OpenID Connect, Firebase Authentication, Auth0, Keycloak — központi eleme. Access token nélkül egyetlen védett API-nak küldött kérés sem kerül feldolgozásra: a szerver HTTP 401 Unauthorized állapotkódot ad vissza. A token nem azonosítja közvetlenül a felhasználót — azt erősíti meg, hogy a kliens jogosult egy adott művelet végrehajtására a felhasználó nevében (engedélyezés), nem azt, hogy ki a felhasználó (hitelesítés).

Az Okta, 2025 adatai szerint a nyilvános API-k több mint 80%-a a Bearer sémát használja access tokennel az Authorization fejlécben, kiszorítva az elavult hitelesítési módszereket — a Basic Auth-ot és az API Key-t. Az access token emellett a delegated authorization — az a modell, amelyben a felhasználó korlátozott hozzáférést biztosít az alkalmazásnak az adataihoz egy másik szolgáltatáson — alapját képezi. Például, amikor egy mobil fotószerkesztő alkalmazás OAuth 2.0-n keresztül kér hozzáférést a Google Drive-hoz, a felhasználó egy hozzájárulási képernyőt lát a felsorolt konkrét scope-okkal, és a megerősítés után access tokent kap ezekkel a jogosultságokkal.

Hogyan működik az Access Token

Az access token működési mechanizmusa a Bearer sémán alapul: a kliens hozzáadja az Authorization: Bearer <token> fejlécet minden HTTP-kéréshez. Az erőforrás-szerver (API) fogadja a tokent, ellenőrzi annak érvényességét, és meghatározza, hogy mely erőforrások érhetők el. Az ellenőrzés kétféleképpen történhet: lokálisan (JWT esetén) vagy introspection endpointon keresztül (opaque token esetén).

Bearer Token séma

Bearer token azt jelenti, hogy bárki, aki bemutatja a tokent (bearer — birtokos), megkapja a megfelelő hozzáférést. Ez magas követelményeket támaszt a token védelmével szemben az átvitel és tárolás során. A Bearer séma nem követeli meg a klienstől a token birtoklásának kriptográfiai bizonyítását — elég azt egyszerűen továbbítani. Ezért a HTTPS kötelező: a forgalom titkosítása nélkül a támadó el tudja lopni a tokent, és azonnal fel tudja használni.

A Cloudflare, 2025 adatai szerint a Bearer token elfogása védtelen HTTP-kapcsolaton keresztül átlagosan 12 másodperccel a kérés elküldése után következik be. A HTTPS és a rövid TTL (15–30 perc) használata gyakorlatilag nullára csökkenti a kockázatot. További alkalmazásszintű védelem — a kérés eredetének ellenőrzése OAuth 2.0 Token Binding (RFC 8471) segítségével: a kliens bizonyítja a tokenhez kötött TLS-kulcs birtoklását, ami haszontalanná teszi a token ellopását elfogással.

Access Token típusok

Access token két formátumban létezik: opaque (átlátszatlan) és JWT (önellátó). A köztük való választás az egyik legfontosabb architekturális döntés a hitelesítési rendszer tervezésekor.

Opaque vs JWT

Opaque token olyan rendszerekhez ajánlott, ahol azonnali hozzáférés-visszavonásra és központosított jogosultság-ellenőrzésre van szükség. JWT — mikroszolgáltatás-architektúrához, ahol a teljesítmény és a hálózati hívások minimalizálása fontos. Sok szolgáltató (Auth0, Keycloak) támogatja mindkét formátumot, és lehetővé teszi a token típusának beállítását minden egyes kliens számára. Az opaque és a JWT közötti választás kompromisszum az irányítás és a teljesítmény között: az opaque teljes irányítást ad a szervernek, a JWT minimális késleltetést.

Az Access Token életciklusa

Az access token életciklusa négy szakaszból áll: kibocsátás (issuance), továbbítás, használat és lejárat. Minden szakasznak megvannak a saját biztonsági követelményei és protokollkorlátozásai.

Lejárat és megújítás

Az access token korlátozott élettartammal rendelkezik — általában 15–60 perc. Az expires_in értéke a token kibocsátásakor az engedélyezési szerver válaszában szerepel. Ennek az időtartamnak a lejárta után a token érvénytelenné válik, és a kliensnek egy újat kell szereznie a refresh token mechanizmuson keresztül. A kliens kétféleképpen ellenőrizheti a lejáratot: a JWT-ben lévő exp mezőn keresztül (helyileg) vagy a HTTP 401 válaszon keresztül (opaque token esetén).

Az Auth0 Best Practices, 2025 adatai szerint az access token optimális TTL-je mobilalkalmazások számára 15–30 perc. A túl rövid TTL (kevesebb mint 5 perc) túlzott terhelést okoz a token végponton minden egyes megújításkor — 10 000 felhasználó és 5 perces TTL esetén a szerver csúcsidőben percenként akár 2 000 megújítási kérést is kaphat. A túl hosszú TTL (több mint 2 óra) megnöveli a támadási ablakot tokenszivárgás esetén — a támadó órákig használhatja a kompromittált tokent, mielőtt a hozzáférést automatikusan blokkolnák.

Access Token biztonság

Az access token biztonságát minden szakaszban garantálni kell: az eszközön történő tároláskor, a hálózaton keresztüli továbbításkor és a szerveren történő feldolgozáskor. Az alapvető javaslat — soha ne tárolja az access tokent olyan helyeken, amelyek más alkalmazások vagy folyamatok számára hozzáférhetők.

Védelem tárolás és továbbítás során

Mobileszközökön az access token tárolása: iOS-en — a Keychain-ben a kSecAttrAccessibleAfterFirstUnlock attribútummal (a token az első feloldás után elérhető, még akkor is, ha az eszköz zárolva van — háttérfrissítésekhez); Androidon — az EncryptedSharedPreferences-ben. Az access token soha nem tárolható NSUserDefaults, SharedPreferences, külső tárolón lévő fájlokban vagy alkalmazásnaplókban. Továbbításkor — csak HTTPS TLS 1.3 vagy 1.2 protokollal. Minden API-kéréshez az access tokent az Authorization: Bearer fejlécben kell továbbítani, nem az URL-paraméterekben (query string) — az URL bekerül a szerverek és böngészők naplófájljaiba.

Az OWASP Mobile Top 10, 2025 adatai szerint a tokenek helytelen tárolása az eszközön (M1: Improper Platform Usage) és az adatok nem biztonságos továbbítása (M3: Insecure Communication) a három leggyakoribb mobilsérülékenység közé tartozik, amelyek fiókok kompromittálódásához vezetnek. További intézkedés — a certificate pinning használata minden access token-es kéréshez: a kliens nemcsak a szabványos CA-láncon, hanem egy előre elmentett tanúsítvány-ujjlenyomaton (SHA-256 fingerprint) keresztül is ellenőrzi a szerver tanúsítványát. Ez megakadályozza a man-in-the-middle támadásokat még kompromittált CA esetén is.

Kód példa Kotlin nyelven

Az alábbiakban egy Kotlin nyelvű példa látható Androidra, amely bemutatja a kérés küldését access token-nel az Authorization fejlécben és a 401 kezelését automatikus megújítással refresh token segítségével. Az OkHttp egyéni Interceptor-ral van használva.

data class TokenStore {
    fun getAccessToken(): String? {
        // Olvasás EncryptedSharedPreferences-ből
        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}")
}

A példa két megközelítést mutat be: az OkHttp Interceptor használatát automatikus tokenkezeléshez és a közvetlen küldést HttpURLConnection segítségével. Az OkHttp Interceptor előnyösebb — központosítja a token hozzáadásának és frissítésének logikáját, kiküszöbölve a kód ismétlődését minden egyes kérésben. Minden kérés egyetlen interceptoron halad keresztül, amely ellenőrzi a válasz állapotát, és szükség esetén frissíti a tokent a fejlesztő részvétele nélkül.