Access Token in iOS- en Android-ontwikkeling — kernbegrippen, tokentypen en hoe het werkt

Wat is een Access Token?

Access Token — is een tekenreeks die de client (mobiele app, SPA, server) gebruikt voor authenticatie van HTTP-verzoeken naar beveiligde API-endpoints. De token wordt uitgegeven door de autorisatieserver nadat de gebruiker zijn identiteit heeft bevestigd en de toepassing de juiste machtigingen (scope) heeft gegeven.

Access token is het centrale element van het OAuth 2.0-protocol en alle daarop gebouwde systemen — OpenID Connect, Firebase Authentication, Auth0, Keycloak. Zonder access token wordt geen enkel verzoek naar een beveiligde API verwerkt: de server retourneert HTTP 401 Unauthorized. De token identificeert de gebruiker niet direct — het bevestigt dat de client het recht heeft om een specifieke actie uit te voeren namens de gebruiker (autorisatie), niet wie de gebruiker is (authenticatie).

Volgens gegevens van Okta, 2025 gebruikt meer dan 80% van de publieke API's het Bearer-schema met access token in de Authorization-header, waardoor verouderde authenticatiemethoden — Basic Auth en API Key — worden verdrongen. Access token is ook de basis voor gedelegeerde autorisatie — het model waarbij de gebruiker de toepassing beperkte toegang geeft tot zijn gegevens op een andere dienst. Bijvoorbeeld, wanneer een mobiele fotobewerkingsapp via OAuth 2.0 toegang tot Google Drive vraagt, ziet de gebruiker een toestemmingsscherm met specifieke scopes en ontvangt na bevestiging een access token met deze rechten.

Hoe werkt Access Token

Het werkingsmechanisme van access token is gebaseerd op het Bearer-schema: de client voegt de header Authorization: Bearer <token> toe aan elk HTTP-verzoek. De resourceserver (API) ontvangt de token, controleert de geldigheid ervan en bepaalt welke resources beschikbaar zijn. De controle kan op twee manieren worden uitgevoerd: lokaal (voor JWT) of via een introspection endpoint (voor opaque token).

Bearer Token schema

Bearer token betekent dat iedereen die de token presenteert (bearer — houder) de bijbehorende toegang krijgt. Dit stelt hoge eisen aan de bescherming van de token tijdens verzending en opslag. Het Bearer-schema vereist niet dat de client cryptografisch bewijst dat hij de token bezit — het volstaat om deze gewoon door te geven. Daarom is HTTPS verplicht: zonder versleuteling van het verkeer kan een aanvaller de token onderscheppen en onmiddellijk gebruiken.

Volgens gegevens van Cloudflare, 2025 vindt onderschepping van een Bearer token via een onbeveiligde HTTP-verbinding gemiddeld binnen 12 seconden na het verzenden van het verzoek plaats. Het gebruik van HTTPS en een korte TTL van de access token (15–30 minuten) brengt het risico vrijwel tot nul. Extra bescherming op applicatieniveau — verificatie van de oorsprong van het verzoek via OAuth 2.0 Token Binding (RFC 8471): de client bewijst het bezit van een aan de token gekoppelde TLS-sleutel, waardoor diefstal van de token via onderschepping zinloos wordt.

Soorten Access Token

Access token bestaat in twee formaten: opaque (ondoorzichtig) en JWT (zelfstandig). De keuze ertussen is een van de belangrijkste architectonische beslissingen bij het ontwerpen van een authenticatiesysteem.

Opaque vs JWT

Opaque token heeft de voorkeur voor systemen waar directe intrekking van toegang en gecentraliseerde rechtencontrole vereist zijn. JWT — voor microservice-architectuur, waar prestaties en minimalisatie van netwerkaanroepen belangrijk zijn. Veel aanbieders (Auth0, Keycloak) ondersteunen beide formaten en maken het mogelijk om het tokentype voor elke client in te stellen. De keuze tussen opaque en JWT is een compromis tussen controle en prestaties: opaque geeft volledige controle aan de server, JWT — minimale vertraging.

Levenscyclus van Access Token

De levenscyclus van een access token bestaat uit vier fasen: uitgifte (issuance), verzending, gebruik en vervaldatum. Elke fase heeft zijn eigen beveiligingseisen en protocolbeperkingen.

Vervaldatum en vernieuwing

Access token heeft een beperkte levensduur — meestal 15–60 minuten. De waarde expires_in wordt vermeld in het antwoord van de autorisatieserver bij uitgifte van de token. Na het verlopen van deze tijd wordt de token ongeldig en moet de client een nieuwe verkrijgen via het refresh token-mechanisme. De client kan het verlopen op twee manieren controleren: via het veld exp in de JWT (lokaal) of via het HTTP-antwoord 401 (voor opaque token).

Volgens gegevens van Auth0 Best Practices, 2025 is de optimale TTL voor access tokens voor mobiele toepassingen 15–30 minuten. Een te korte TTL (minder dan 5 minuten) creëert overmatige belasting van het token-endpoint bij elke vernieuwing — bij 10.000 gebruikers en een TTL van 5 minuten ontvangt de server tot 2.000 vernieuwingsverzoeken per minuut in piekuren. Een te lange TTL (meer dan 2 uur) vergroot het aanvalsvenster bij tokenlekkage — een aanvaller kan de gecompromitteerde token urenlang gebruiken voordat de toegang automatisch wordt geblokkeerd.

Beveiliging van Access Token

De beveiliging van access token moet in alle fasen worden gewaarborgd: bij opslag op het apparaat, bij verzending via het netwerk en bij verwerking op de server. De basisaanbeveling — bewaar access token nooit op plaatsen die toegankelijk zijn voor andere toepassingen of processen.

Bescherming bij opslag en verzending

Op mobiele apparaten wordt access token opgeslagen: op iOS — in Keychain met attribuut kSecAttrAccessibleAfterFirstUnlock (token beschikbaar na eerste ontgrendeling, zelfs als apparaat vergrendeld is — voor achtergrondupdates); op Android — in EncryptedSharedPreferences. Access token mag nooit worden opgeslagen in NSUserDefaults, SharedPreferences, bestanden op externe opslag of in applicatielogs. Bij verzending — alleen HTTPS met TLS 1.3 of 1.2. Voor elk API-verzoek moet access token worden doorgegeven in de header Authorization: Bearer, niet in URL-parameters (query string) — de URL komt terecht in server- en browserlogs.

Volgens gegevens van OWASP Mobile Top 10, 2025 behoren onjuiste opslag van tokens op het apparaat (M1: Improper Platform Usage) en onveilige gegevensoverdracht (M3: Insecure Communication) tot de drie meest voorkomende mobiele kwetsbaarheden die leiden tot accountcompromittatie. Een extra maatregel — het gebruik van certificate pinning voor alle verzoeken met access token: de client controleert het servercertificaat niet alleen via de standaard CA-keten, maar ook via een vooraf opgeslagen certificaatvingerafdruk (SHA-256 fingerprint). Dit voorkomt man-in-the-middle-aanvallen, zelfs bij een gecompromitteerde CA.

Voorbeeldcode in Kotlin

Hieronder staat een voorbeeld in Kotlin voor Android, dat het verzenden van een verzoek met access token in de Authorization-header en het afhandelen van 401 met automatische vernieuwing via refresh token demonstreert. Er wordt OkHttp met een aangepaste Interceptor gebruikt.

data class TokenStore {
    fun getAccessToken(): String? {
        // Lezen uit 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}")
}

Het voorbeeld toont twee benaderingen: het gebruik van OkHttp Interceptor voor automatisch tokenbeheer en direct verzenden via HttpURLConnection. OkHttp Interceptor heeft de voorkeur — het centraliseert de logica voor het toevoegen en vernieuwen van de token, waardoor code-herhaling in elk verzoek wordt geëlimineerd. Alle verzoeken gaan door één interceptor die de antwoordstatus controleert en indien nodig de token vernieuwt zonder tussenkomst van de programmeur.