Access Token ve vývoji pro iOS a Android — klíčové pojmy, typy tokenů a jak funguje

Co je Access Token?

Access Token — je řetězec, který klient (mobilní aplikace, SPA, server) používá pro autentizaci HTTP požadavků na chráněné API endpointy. Token je vydán autorizačním serverem poté, co uživatel potvrdí svou identitu a udělí aplikaci příslušná oprávnění (scope).

Access token je ústředním prvkem protokolu OAuth 2.0 a všech na něm postavených systémů — OpenID Connect, Firebase Authentication, Auth0, Keycloak. Bez access tokenu nebude zpracován žádný požadavek na chráněné API: server vrátí HTTP 401 Unauthorized. Token přímo neidentifikuje uživatele — potvrzuje, že klient má právo provést konkrétní akci jménem uživatele (autorizace), nikoli kdo je uživatel (autentizace).

Podle údajů Okta, 2025 používá více než 80 % veřejných API schéma Bearer s access tokenem v Authorization hlavičce, čímž vytlačuje zastaralé metody autentizace — Basic Auth a API Key. Access token je také základem pro delegated authorization — model, ve kterém uživatel poskytuje aplikaci omezený přístup ke svým datům na jiné službě. Například když mobilní aplikace pro úpravu fotek požaduje přístup k Google Drive přes OAuth 2.0, uživatel vidí obrazovku souhlasu s vyjmenovanými konkrétními scopey a po potvrzení obdrží access token s těmito právy.

Jak funguje Access Token

Mechanismus fungování access tokenu je založen na schématu Bearer: klient přidává hlavičku Authorization: Bearer <token> ke každému HTTP požadavku. Server prostředků (API) obdrží token, zkontroluje jeho platnost a určí, které zdroje jsou dostupné. Ověření může probíhat dvěma způsoby: lokálně (pro JWT) nebo přes introspection endpoint (pro opaque token).

Schéma Bearer Token

Bearer token znamená, že kdokoli, kdo token předloží (bearer — nositel), získá odpovídající přístup. To klade vysoké nároky na ochranu tokenu při přenosu a ukládání. Schéma Bearer nevyžaduje, aby klient kryptograficky prokázal vlastnictví tokenu — stačí jej jednoduše předat. Proto je HTTPS povinné: bez šifrování provozu může útočník token zachytit a okamžitě jej použít.

Podle údajů Cloudflare, 2025 dochází k zachycení Bearer tokenu přes nezabezpečené HTTP připojení v průměru do 12 sekund po odeslání požadavku. Použití HTTPS a krátkého TTL access tokenu (15–30 minut) snižuje riziko prakticky na nulu. Dodatečná ochrana na úrovni aplikace — ověření původu požadavku přes OAuth 2.0 Token Binding (RFC 8471): klient prokazuje vlastnictví TLS klíče svázaného s tokenem, což činí krádež tokenu zachycením bezcennou.

Typy Access Token

Access token existuje ve dvou formátech: opaque (neprůhledný) a JWT (soběstačný). Volba mezi nimi je jedním z klíčových architektonických rozhodnutí při navrhování autentizačního systému.

Opaque vs JWT

Opaque token je vhodnější pro systémy, kde je vyžadováno okamžité odvolání přístupu a centralizované ověření práv. JWT — pro mikroslužbovou architekturu, kde jsou důležité výkon a minimalizace síťových volání. Mnoho poskytovatelů (Auth0, Keycloak) podporuje oba formáty a umožňuje nastavit typ tokenu pro každého klienta. Volba mezi opaque a JWT je kompromisem mezi kontrolou a výkonem: opaque dává plnou kontrolu serveru, JWT — minimální zpoždění.

Životní cyklus Access Token

Životní cyklus access tokenu se skládá ze čtyř fází: vydání (issuance), přenos, použití a vypršení. Každá fáze má své vlastní bezpečnostní požadavky a protokolová omezení.

Vypršení a obnovení

Access token má omezenou dobu platnosti — obvykle 15–60 minut. Hodnota expires_in je uvedena v odpovědi autorizačního serveru při vydání tokenu. Po uplynutí této doby se token stává neplatným a klient musí získat nový prostřednictvím mechanismu refresh token. Klient může zkontrolovat vypršení dvěma způsoby: pomocí pole exp v JWT (lokálně) nebo pomocí HTTP odpovědi 401 (pro opaque token).

Podle údajů Auth0 Best Practices, 2025 je optimální TTL access tokenu pro mobilní aplikace 15–30 minut. Příliš krátké TTL (méně než 5 minut) vytváří nadměrnou zátěž na token endpoint při každém obnovení — při 10 000 uživatelích a TTL 5 minut server obdrží až 2 000 požadavků na obnovení za minutu ve špičce. Příliš dlouhé TTL (více než 2 hodiny) zvětšuje útočné okno při úniku tokenu — útočník může používat kompromitovaný token po několik hodin, než je přístup automaticky zablokován.

Bezpečnost Access Token

Bezpečnost access tokenu musí být zajištěna ve všech fázích: při ukládání na zařízení, při přenosu po síti a při zpracování na serveru. Základní doporučení — nikdy neukládejte access token na místech přístupných jiným aplikacím nebo procesům.

Ochrana při ukládání a přenosu

Na mobilních zařízeních se access token ukládá: na iOS — do Keychain s atributem kSecAttrAccessibleAfterFirstUnlock (token je dostupný po prvním odemčení, i když je zařízení uzamčeno — pro aktualizace na pozadí); na Android — do EncryptedSharedPreferences. Access token by nikdy neměl být ukládán do NSUserDefaults, SharedPreferences, souborů na externím úložišti nebo v logách aplikace. Při přenosu — pouze HTTPS s TLS 1.3 nebo 1.2. Pro každý API požadavek by měl být access token předáván v hlavičce Authorization: Bearer, nikoli v parametrech URL (query string) — URL se dostává do logů serverů a prohlížečů.

Podle údajů OWASP Mobile Top 10, 2025 patří nesprávné ukládání tokenů na zařízení (M1: Improper Platform Usage) a nezabezpečený přenos dat (M3: Insecure Communication) mezi tři nejčastější mobilní zranitelnosti vedoucí ke kompromitaci účtů. Dalším opatřením — použití certificate pinnigu pro všechny požadavky s access tokenem: klient ověřuje certifikát serveru nejen prostřednictvím standardního řetězce CA, ale také pomocí předem uloženého otisku certifikátu (SHA-256 fingerprint). To zabraňuje útokům man-in-the-middle i v případě kompromitovaného CA.

Příklad kódu v Kotlin

Níže je uveden příklad v Kotlin pro Android, který demonstruje odeslání požadavku s access tokenem v Authorization hlavičce a zpracování 401 s automatickým obnovením pomocí refresh token. Používá se OkHttp s vlastním Interceptorem.

data class TokenStore {
    fun getAccessToken(): String? {
        // Čtení z 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}")
}

Příklad ukazuje dva přístupy: použití OkHttp Interceptor pro automatickou správu tokenů a přímé odeslání přes HttpURLConnection. OkHttp Interceptor je preferovaný — centralizuje logiku přidávání a obnovování tokenu, čímž eliminuje duplikaci kódu v každém požadavku. Všechny požadavky procházejí jediným interceptorem, který kontroluje stav odpovědi a v případě potřeby obnoví token bez účasti vývojáře.