Access Token in der iOS- und Android-Entwicklung — Schlüsselkonzepte, Token-Typen und Funktionsweise

Was ist ein Access Token?

Access Token – eine Zeichenfolge, die ein Client (mobile App, SPA, Server) verwendet, um HTTP-Anfragen an geschützte API-Endpunkte zu authentifizieren. Der Token wird vom Autorisierungsserver ausgestellt, nachdem der Benutzer seine Identität bestätigt und der Anwendung die entsprechenden Berechtigungen (Scope) erteilt hat.

Der Access Token ist ein zentrales Element des OAuth 2.0-Protokolls und aller darauf aufbauenden Systeme – OpenID Connect, Firebase Authentication, Auth0, Keycloak. Ohne einen Access Token wird keine Anfrage an eine geschützte API verarbeitet: Der Server gibt HTTP 401 Unauthorized zurück. Der Token identifiziert den Benutzer nicht direkt – er bestätigt, dass der Client berechtigt ist, eine bestimmte Aktion im Namen des Benutzers auszuführen (Autorisierung), nicht wer der Benutzer ist (Authentifizierung).

Laut Okta, 2025 verwenden mehr als 80% der öffentlichen APIs das Bearer-Schema mit einem Access Token im Authorization-Header und verdrängen damit veraltete Authentifizierungsmethoden – Basic Auth und API Key. Der Access Token ist auch die Grundlage für delegierte Autorisierung – ein Modell, bei dem der Benutzer einer Anwendung eingeschränkten Zugriff auf seine Daten auf einem anderen Dienst gewährt. Wenn beispielsweise eine mobile Foto-Bearbeitungs-App über OAuth 2.0 Zugriff auf Google Drive anfordert, sieht der Benutzer einen Zustimmungsbildschirm mit den spezifischen Scopes und erhält nach Bestätigung einen Access Token mit diesen Berechtigungen.

Wie funktioniert ein Access Token

Mechanismus des Access Tokens basiert auf dem Bearer-Schema: Der Client fügt jeder HTTP-Anfrage den Header Authorization: Bearer <token> hinzu. Der Ressourcenserver (API) empfängt den Token, validiert ihn und bestimmt, welche Ressourcen zugänglich sind. Die Validierung kann auf zwei Arten erfolgen: lokal (für JWT) oder über einen Introspections-Endpunkt (für opaque Tokens).

Bearer-Token-Schema

Bearer Token bedeutet, dass jeder, der den Token vorlegt (Bearer), den entsprechenden Zugriff erhält. Dies stellt hohe Anforderungen an den Schutz des Tokens während der Übertragung und Speicherung. Das Bearer-Schema erfordert keinen kryptografischen Nachweis des Token-Besitzes durch den Client – es reicht aus, ihn zu übertragen. Daher ist HTTPS zwingend erforderlich: Ohne Verkehrsverschlüsselung kann ein Angreifer den Token abfangen und sofort nutzen.

Laut Cloudflare, 2025 erfolgt das Abfangen eines Bearer Tokens über eine ungesicherte HTTP-Verbindung durchschnittlich innerhalb von 12 Sekunden nach dem Senden der Anfrage. Die Verwendung von HTTPS und einer kurzen Access-Token-TTL (15–30 Minuten) reduziert das Risiko auf praktisch null. Zusätzlicher Schutz auf Anwendungsebene – Überprüfung des Anfrageursprungs über OAuth 2.0 Token Binding (RFC 8471): Der Client beweist den Besitz des an den Token gebundenen TLS-Schlüssels, wodurch der Tokendiebstahl durch Abfangen nutzlos wird.

Arten von Access Tokens

Access Token existiert in zwei Formaten: opaque und JWT (eigenständig). Die Wahl zwischen ihnen ist eine der wichtigsten architektonischen Entscheidungen bei der Gestaltung eines Authentifizierungssystems.

Opaque vs. JWT

Opaque Token wird für Systeme bevorzugt, die einen sofortigen Zugriffswiderruf und eine zentrale Rechteprüfung erfordern. JWT ist für Microservice-Architekturen geeignet, bei denen Leistung und Minimierung von Netzwerkaufrufen wichtig sind. Viele Anbieter (Auth0, Keycloak) unterstützen beide Formate und erlauben die Konfiguration des Tokentyps für jeden Client. Die Wahl zwischen opaque und JWT ist ein Kompromiss zwischen Kontrolle und Leistung: opaque gibt dem Server die volle Kontrolle, JWT bietet minimale Latenz.

Lebenszyklus eines Access Tokens

Lebenszyklus eines Access Tokens besteht aus vier Phasen: Ausstellung, Übertragung, Nutzung und Ablauf. Jede Phase hat ihre eigenen Sicherheitsanforderungen und Protokollbeschränkungen.

Ablauf und Erneuerung

Access Token hat eine begrenzte Lebensdauer – typischerweise 15–60 Minuten. Der Wert expires_in wird in der Antwort des Autorisierungsservers bei der Token-Ausstellung angegeben. Nach Ablauf dieser Zeit wird der Token ungültig und der Client muss über den Refresh-Token-Mechanismus einen neuen anfordern. Der Client kann den Ablauf auf zwei Arten überprüfen: über das Feld exp im JWT (lokal) oder über die HTTP-401-Antwort (für opaque Tokens).

Laut Auth0 Best Practices, 2025 beträgt die optimale Access-Token-TTL für mobile Anwendungen 15–30 Minuten. Eine zu kurze TTL (weniger als 5 Minuten) erzeugt bei jeder Erneuerung eine übermäßige Belastung des Token-Endpunkts – bei 10.000 Benutzern und einer TTL von 5 Minuten erhält der Server zu Spitzenzeiten bis zu 2.000 Erneuerungsanfragen pro Minute. Eine zu lange TTL (mehr als 2 Stunden) vergrößert das Angriffsfenster bei einem Token-Leck – ein Angreifer kann den kompromittierten Token mehrere Stunden lang nutzen, bevor der Zugriff automatisch gesperrt wird.

Sicherheit von Access Tokens

Sicherheit des Access Tokens muss in allen Phasen gewährleistet sein: bei der Speicherung auf dem Gerät, bei der Übertragung über das Netzwerk und bei der Verarbeitung auf dem Server. Die grundlegende Empfehlung lautet, den Access Token niemals an Orten zu speichern, die für andere Anwendungen oder Prozesse zugänglich sind.

Schutz bei Speicherung und Übertragung

Auf mobilen Geräten wird der Access Token gespeichert: auf iOS – in der Keychain mit dem Attribut kSecAttrAccessibleAfterFirstUnlock (der Token ist nach dem ersten Entsperren zugänglich, auch wenn das Gerät gesperrt ist – für Hintergrundaktualisierungen); auf Android – in EncryptedSharedPreferences. Der Access Token sollte niemals in NSUserDefaults, SharedPreferences, Dateien auf externem Speicher oder Anwendungsprotokollen gespeichert werden. Bei der Übertragung – nur HTTPS mit TLS 1.3 oder 1.2. Für jede API-Anfrage muss der Access Token im Header Authorization: Bearer und nicht in URL-Parametern (Query-String) gesendet werden – URLs landen in Server- und Browserprotokollen.

Laut OWASP Mobile Top 10, 2025 gehören unsachgemäße Token-Speicherung auf dem Gerät (M1: Improper Platform Usage) und unsichere Datenübertragung (M3: Insecure Communication) zu den drei häufigsten mobilen Schwachstellen, die zur Kontenkompromittierung führen. Eine zusätzliche Maßnahme – die Verwendung von Certificate Pinning für alle Anfragen mit Access Token: Der Client überprüft das Serverzertifikat nicht nur über die Standard-CA-Kette, sondern auch über einen vorab gespeicherten Zertifikatsfingerabdruck (SHA-256 Fingerprint). Dies verhindert Man-in-the-Middle-Angriffe selbst bei einem kompromittierten CA.

Codebeispiel in Kotlin

Nachfolgend ein Beispiel in Kotlin für Android, das das Senden einer Anfrage mit einem Access Token im Authorization-Header und die Behandlung von 401 mit automatischer Erneuerung über einen Refresh Token demonstriert. OkHttp mit einem benutzerdefinierten Interceptor wird verwendet.

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

Das Beispiel zeigt zwei Ansätze: die Verwendung von OkHttp Interceptor für die automatische Tokenverwaltung und das direkte Senden über HttpURLConnection. OkHttp Interceptor wird bevorzugt – er zentralisiert die Logik zum Hinzufügen und Erneuern des Tokens und vermeidet Code-Duplizierung in jeder Anfrage. Alle Anfragen durchlaufen einen einzigen Interceptor, der den Antwortstatus überprüft und bei Bedarf den Token ohne Entwicklereingriff erneuert.