Refresh Token für mobile Apps — Wesen, Erneuerungsmechanismus und sichere Speicherung

Was ist ein Refresh Token?

Refresh Token ist eine Berechtigung, die eine Client-Anwendung verwendet, um nach Ablauf des aktuellen einen neuen Access Token zu erhalten. Im Gegensatz zum Access Token wird der Refresh Token nicht mit jeder API-Anfrage gesendet — er wird in einem sicheren Repository auf dem Client gespeichert und nur bei Kontaktaufnahme mit dem Token-Endpunkt des Authentifizierungsservers verwendet.

Die Grundidee besteht darin, zwei Token mit unterschiedlichen Lebensdauern zu trennen. Ein Access Token mit kurzer TTL reduziert das Angriffsfenster, wenn er abgefangen wird: Wird ein Access Token gestohlen, kann ein Angreifer ihn nur wenige Minuten lang nutzen. Refresh Token wird dadurch geschützt, dass er niemals mit normalen Anfragen übertragen wird — nur über einen sicheren Kanal zum Token-Endpunkt. Dies macht seinen Diebstahl erheblich schwieriger.

Laut OAuth Security Workshop, 2025 reduziert die Implementierung der Refresh-Token-Rotation das Risiko einer Sitzungskompromittierung um 85% im Vergleich zur Speicherung eines einzigen langlebigen Access Tokens.

Wie funktioniert ein Refresh Token

Der Erneuerungsprozess wird ausgelöst, wenn der Client eine HTTP-401-Antwort erhält oder feststellt, dass der Access Token abgelaufen ist (Prüfung von exp im JWT). Der Client sendet eine POST-Anfrage an den Token-Endpunkt des Servers mit grant_type=refresh_token und dem Refresh Token selbst im Anfragetext. Der Server überprüft die Gültigkeit des Refresh Tokens, dessen Ablauf und die Zugehörigkeit zur client_id. Wenn alles korrekt ist — gibt der Server einen neuen Access Token und optional einen neuen Refresh Token zurück.

Token-Erneuerungsablauf

Das Schema der Erneuerungsanfrage sieht wie folgt aus: Der Client sendet ein POST an /oauth/token mit den Parametern grant_type=refresh_token, refresh_token={token} und client_id={id}. Der Server gibt JSON mit einem neuen Access Token und Ablauf zurück:

{
  "access_token": "eyJhbGciOi...neuer-token",
  "token_type": "Bearer",
  "expires_in": 1800,
  "refresh_token": "neuer-refresh-token"
}

Refresh-Token-Rotation (Rückgabe eines neuen Refresh Tokens) wird von OAuth 2.0 Security Best Current Practice (RFC 9700) empfohlen. Der alte Refresh Token wird gleichzeitig ungültig gemacht. Wenn ein Angreifer den alten Refresh Token gestohlen und vor dem legitimen Client verwendet hat, erkennt der Server die Wiederverwendung — Reuse Detection — und blockiert die gesamte Sitzung.

Refresh Token vs Access Token

Access Token und Refresh Token erfüllen unterschiedliche Funktionen und haben grundlegend unterschiedliche Sicherheitseigenschaften. Ein Access Token ist ein temporärer Pass für die API, während ein Refresh Token eine langfristige Berechtigung zum Erhalten neuer Pässe ist.

Warum ein Access Token nicht langlebig sein kann

Eine kurze TTL für den Access Token ist ein bewusster Sicherheitskompromiss. Wird ein Access Token gestohlen (durch Verkehrsabfang, Protokolllecks oder Malware auf dem Gerät), ist das Zeitfenster, in dem ein Angreifer ihn nutzen kann, auf 15–60 Minuten begrenzt. Ein Refresh Token ist geschützt, weil er niemals mit jeder Anfrage übertragen wird — sein Abfangen erfordert einen gezielten Angriff auf den Token-Endpunkt. Laut Auth0 Security Team, 2025 wurden 90% der kompromittierten Access Token durch ungesicherte Netzwerkverbindungen abgefangen — genau davor schützt die Architektur des Refresh Tokens.

Sicherheit des Refresh Token

Die Sicherheit des Refresh Tokens ist ein kritisches Element des gesamten Authentifizierungsschemas. Da der Refresh Token über einen längeren Zeitraum vollständigen Zugriff auf das Konto gewährt, muss sein Schutz maximal sein. OWASP und OAuth Security Best Practices veröffentlichen spezifische Anforderungen.

Speicherung von Refresh Tokens auf mobilen Geräten

Die richtige Speicherung hängt von der Plattform ab. Auf iOS — Keychain mit Zugriff kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly. Dadurch ist der Token bei entferntem Gerätepasscode nicht zugänglich. Auf Android — EncryptedSharedPreferences aus der AndroidX Security-Bibliothek mit einem Masterschlüssel im Android Keystore. Der Token wird auf Dateisystemebene verschlüsselt und ist selbst bei Root-Zugriff nicht zugänglich. Verboten: Speichern von Refresh Tokens in SharedPreferences, NSUserDefaults, Klartextdateien oder in Base64 ohne Verschlüsselung.

Laut Google Security Blog, 2025 reduziert EncryptedSharedPreferences mit AES256-GCM das Risiko von Token-Lecks um 99,7% im Vergleich zu normalen SharedPreferences bei physischem Zugriff auf das Gerät. Zur Erhöhung der Sicherheit wird auch empfohlen, die Speicher zu trennen: Der Access Token kann im Arbeitsspeicher gespeichert werden (kurzfristiger Zugriff), während der Refresh Token nur im geschützten Systemspeicher (Keychain / Keystore) gespeichert werden sollte. Wenn die App ein Vordergrundsignal vom System erhält, wird der Refresh Token überprüft und bei Bedarf erneuert, bevor der Benutzer mit der Interaktion beginnt.

Refresh Token Rotation

Refresh-Token-Rotation ist ein Mechanismus, bei dem jede Anfrage zur Erneuerung eines Access Tokens einen neuen Refresh Token zurückgibt und der alte widerrufen wird. Wenn ein Angreifer den Refresh Token gestohlen hat und ihn verwendet, erhält der legitime Client bei einem erneuten Erneuerungsversuch einen Fehler — der Server erkennt, dass der Refresh Token bereits verwendet wurde (Reuse Detection). Die Rotation ist eine obligatorische Empfehlung von OAuth 2.0 Security Best Current Practice (RFC 9700) für alle Systeme, die mit langlebigen Token in einer mobilen Umgebung arbeiten.

Wiederverwendungserkennung

Der Erkennungsalgorithmus funktioniert wie folgt: Der Server speichert für jeden ausgegebenen Refresh Token ein „verwendet“-Flag in der Datenbank. Bei einer Erneuerungsanfrage überprüft der Server — ist der Refresh Token bereits als verwendet markiert, liegt ein Wiederverwendungsversuch vor. Der Server macht sofort alle Refresh Token dieser Sitzung ungültig und blockiert den Zugriff. Der legitime Benutzer wird zur Anmeldeseite weitergeleitet. Dies verhindert Angriffe durch gestohlene Refresh Token: Der Angreifer erhält Zugriff, aber die Sitzung wird sofort nach Erkennung blockiert.

Laut OAuth Security Workshop, 2025 reduziert die Implementierung von Rotation + Reuse Detection die Wahrscheinlichkeit eines erfolgreichen Angriffs über einen gestohlenen Refresh Token von 23% auf 0,3%. Zur Implementierung der Wiederverwendungserkennung speichert der Server den Hash des zuletzt ausgegebenen Refresh Tokens zusammen mit der client_id. Bei einer Erneuerungsanfrage vergleicht der Server den vorgelegten Refresh Token mit dem gespeicherten — stimmen sie nicht überein, liegt eine Wiederverwendung vor und die gesamte Token-Kette wird widerrufen.

Beim Erhalt eines invalid_grant-Fehlers muss der Client eine vollständige Abmeldung durchführen: alle gespeicherten Token (Access und Refresh) löschen, die aktuelle Sitzung auf dem Gerät beenden und den Benutzer zum Anmeldebildschirm weiterleiten. Die erneute Authentifizierung erstellt eine neue Token-Kette ohne Bezug zur vorherigen. Das Ignorieren dieses Fehlers und erneute Versuche der Erneuerung führen zu einer Blockierung durch die Wiederverwendungserkennung.

Implementierung in Kotlin

Ein Beispiel für die Implementierung der clientseitigen Token-Erneuerung in Kotlin für Android. Die App fängt die HTTP-401-Antwort ab, löst eine Erneuerungsanfrage aus und wiederholt die ursprüngliche Anfrage mit dem neuen Access Token. Verwendet wird der OkHttp Interceptor — eine Schlüsselkomponente für die automatische Token-Verwaltung ohne Duplizierung der Logik in jeder Anfrage.

class AuthInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val request = chain.request()
        val accessToken = getAccessToken()
        val authRequest = request.newBuilder()
            .addHeader("Authorization", "Bearer $accessToken")
            .build()

        val response = chain.proceed(authRequest)
        if (response.code != 401) return response

        // Access Token abgelaufen — Erneuerung über Refresh Token
        val newToken = refreshAccessToken() ?: return response
        return chain.proceed(request.newBuilder()
            .addHeader("Authorization", "Bearer $newToken")
            .build())
    }

    private fun refreshAccessToken(): String? {
        val refreshToken = getRefreshToken() ?: return null
        val client = OkHttpClient()
        val body = FormBody.Builder()
            .add("grant_type", "refresh_token")
            .add("refresh_token", refreshToken)
            .build()

        val request = Request.Builder()
            .url("https://auth.example.com/oauth/token")
            .post(body)
            .build()

        val response = client.newCall(request).execute()
        val json = JSONObject(response.body?.string() ?: return null)
        val newAccessToken = json.getString("access_token")
        // Neuen Refresh Token während Rotation speichern
        saveTokens(newAccessToken, json.optString("refresh_token"))
        return newAccessToken
    }
}