Access Token inom iOS och Android-utveckling — nyckelbegrepp, tokentyper och hur det fungerar

Vad är Access Token?

Access Token — är en sträng som klienten (mobilapp, SPA, server) använder för att autentisera HTTP-begäranden till skyddade API-endpoints. Token utfärdas av auktoriseringsservern efter att användaren har bekräftat sin identitet och beviljat applikationen lämpliga behörigheter (scope).

Access token är den centrala delen av OAuth 2.0-protokollet och alla system som bygger på det — OpenID Connect, Firebase Authentication, Auth0, Keycloak. Utan access token kommer ingen begäran till ett skyddat API att behandlas: servern returnerar HTTP 401 Unauthorized. Token identifierar inte användaren direkt — den bekräftar att klienten har rätt att utföra en specifik åtgärd på uppdrag av användaren (auktorisation), inte vem användaren är (autentisering).

Enligt data från Okta, 2025 använder över 80% av offentliga API:er Bearer-schemat med access token i Authorization-huvudet, vilket tränger undan föråldrade autentiseringsmetoder — Basic Auth och API Key. Access token är också grunden för delegerad auktorisation — modellen där användaren ger applikationen begränsad åtkomst till sina data på en annan tjänst. Till exempel, när en mobil fotoredigeringsapp begär åtkomst till Google Drive via OAuth 2.0, ser användaren en samtyckesskärm med specifika scopes listade och efter bekräftelse får han en access token med dessa rättigheter.

Hur Access Token fungerar

Access tokens funktionsmekanism är baserad på Bearer-schemat: klienten lägger till rubriken Authorization: Bearer <token> till varje HTTP-begäran. Resursservern (API) tar emot token, kontrollerar dess giltighet och bestämmer vilka resurser som är tillgängliga. Kontrollen kan göras på två sätt: lokalt (för JWT) eller via introspection endpoint (för opaque token).

Bearer Token-schema

Bearer token innebär att den som presenterar token (bearer — innehavare) får motsvarande åtkomst. Detta ställer höga krav på skydd av token under överföring och lagring. Bearer-schemat kräver inte att klienten kryptografiskt bevisar innehavet av token — det räcker att bara överföra den. Därför är HTTPS obligatoriskt: utan kryptering av trafiken kan en angripare fånga upp token och omedelbart använda den.

Enligt data från Cloudflare, 2025 sker avlyssning av Bearer token via en oskyddad HTTP-anslutning i genomsnitt inom 12 sekunder efter att begäran skickats. Användning av HTTPS och kort TTL för access token (15–30 minuter) minskar risken till praktiskt taget noll. Extra skydd på applikationsnivå — verifiering av begäran ursprung via OAuth 2.0 Token Binding (RFC 8471): klienten bevisar innehavet av en TLS-nyckel som är bunden till token, vilket gör stöld av token via avlyssning värdelös.

Typer av Access Token

Access token finns i två format: opaque (ogenomskinlig) och JWT (självförsörjande). Valet mellan dem är ett av de viktigaste arkitektoniska besluten vid utformning av ett autentiseringssystem.

Opaque vs JWT

Opaque token är att föredra för system där omedelbar återkallning av åtkomst och centraliserad rättighetskontroll krävs. JWT — för mikrotjänstarkitektur, där prestanda och minimering av nätverksanrop är viktiga. Många leverantörer (Auth0, Keycloak) stöder båda formaten och låter dig konfigurera tokentypen för varje klient. Valet mellan opaque och JWT är en kompromiss mellan kontroll och prestanda: opaque ger full kontroll till servern, JWT — minimal fördröjning.

Access Token livscykel

Livscykeln för access token består av fyra faser: utfärdande (issuance), överföring, användning och utgång. Varje fas har sina egna säkerhetskrav och protokollbegränsningar.

Utgång och förnyelse

Access token har en begränsad livslängd — vanligtvis 15–60 minuter. Värdet expires_in anges i auktoriseringsserverns svar vid utfärdandet av token. Efter denna tid blir token ogiltig och klienten måste skaffa en ny via refresh token-mekanismen. Klienten kan kontrollera utgången på två sätt: via fältet exp i JWT (lokalt) eller via HTTP-svaret 401 (för opaque token).

Enligt data från Auth0 Best Practices, 2025 är den optimala TTL för access token för mobila applikationer 15–30 minuter. För kort TTL (mindre än 5 minuter) skapar överdriven belastning på token-endpoint vid varje förnyelse — med 10 000 användare och en TTL på 5 minuter får servern upp till 2 000 förnyelsebegäranden per minut under rusningstid. För lång TTL (mer än 2 timmar) ökar attackfönstret vid tokenläckage — en angripare kan använda den komprometterade token i timmar innan åtkomsten automatiskt blockeras.

Säkerhet för Access Token

Säkerheten för access token måste garanteras i alla faser: vid lagring på enheten, vid överföring över nätverket och vid bearbetning på servern. Grundrekommendationen — lagra aldrig access token på platser som är tillgängliga för andra applikationer eller processer.

Skydd vid lagring och överföring

På mobila enheter lagras access token: på iOS — i Keychain med attributet kSecAttrAccessibleAfterFirstUnlock (token tillgänglig efter första upplåsning, även om enheten är låst — för bakgrundsuppdateringar); på Android — i EncryptedSharedPreferences. Access token bör aldrig sparas i NSUserDefaults, SharedPreferences, filer på extern lagring eller i applikationsloggar. Vid överföring — endast HTTPS med TLS 1.3 eller 1.2. För varje API-begäran ska access token överföras i rubriken Authorization: Bearer, inte i URL-parametrar (query string) — URL:n hamnar i server- och webbläsarloggar.

Enligt data från OWASP Mobile Top 10, 2025 hör felaktig lagring av tokens på enheten (M1: Improper Platform Usage) och osäker dataöverföring (M3: Insecure Communication) till de tre vanligaste mobila sårbarheterna som leder till kompromettering av konton. En extra åtgärd — användning av certificate pinning för alla begäranden med access token: klienten verifierar serverns certifikat inte bara via den vanliga CA-kedjan, utan också via en förhandsbesparad certifikatavtryck (SHA-256 fingerprint). Detta förhindrar man-in-the-middle-attacker även vid en komprometterad CA.

Kodexempel i Kotlin

Nedan är ett exempel i Kotlin för Android som visar hur man skickar en begäran med access token i Authorization-huvudet och hanterar 401 med automatisk förnyelse via refresh token. OkHttp med en anpassad Interceptor används.

data class TokenStore {
    fun getAccessToken(): String? {
        // Läsa från 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}")
}

Exemplet visar två tillvägagångssätt: användning av OkHttp Interceptor för automatisk tokenhantering och direkt sändning via HttpURLConnection. OkHttp Interceptor är att föredra — det centraliserar logiken för att lägga till och förnya token, vilket eliminerar duplicering av kod i varje begäran. Alla begäranden går genom en enda interceptor som kontrollerar svarsstatus och vid behov förnyar token utan utvecklarens medverkan.