Refresh Token mobilalkalmazásokhoz — lényeg, frissítési mechanizmus és biztonságos tárolás

Mi az a Refresh Token?

Refresh Token — olyan hitelesítő adat, amelyet a kliensalkalmazás használ új access token beszerzésére a jelenlegi token lejárata után. Az access tokentől eltérően a refresh token nem kerül elküldésre minden API-kéréssel — a kliens oldali biztonságos tárban tárolódik, és csak a hitelesítési szerver token endpointjának elérésekor használjuk.

A fő ötlet a két különböző élettartamú token szétválasztása. A rövid TTL-lel rendelkező access token csökkenti a támadási ablakot az elfogáskor: ha az access token lopott, a támadó csak néhány percig használhatja. Refresh token azáltal védett, hogy soha nem kerül elküldésre a szokványos kérésekkel — csak egy biztonságos csatornán keresztül a token endpointra. Ez lényegesen megnehezíti az ellopását.

A OAuth Security Workshop, 2025 szerint a refresh token rotationnal történő bevezetése 85%-kal csökkenti a munkamenet kompromittálódásának kockázatát egyetlen hosszú élettartamú access token tárolásához képest.

Hogyan működik a Refresh Token

A frissítési folyamat akkor indul, amikor a kliens HTTP 401 Unauthorized választ kap, vagy észleli, hogy az access token lejárt (exp ellenőrzés JWT-ben). A kliens POST kérést küld a szerver token endpointjára grant_type=refresh_token és magával a refresh tokennel a kérés törzsében. A szerver ellenőrzi a refresh token érvényességét, lejárati idejét és a client_id-hez való tartozását. Ha minden rendben van — a szerver új access tokent és opcionálisan új refresh tokent ad vissza.

Token frissítési folyamat

A frissítési kérés sémája így néz ki: a kliens POST-ot küld a /oauth/token címre a grant_type=refresh_token, refresh_token={token} és client_id={id} paraméterekkel. A szerver JSON-t ad vissza az új access tokennal és lejárattal:

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

Refresh token rotation (új refresh token visszaadása) az OAuth 2.0 Security Best Current Practice (RFC 9700) által ajánlott. A régi refresh token ezzel érvénytelenítődik. Ha egy támadó ellopta a régi refresh tokent, és sikerült azt a jogos kliens előtt használnia, a szerver észleli az ismételt használatot — reuse detection — és blokkolja a teljes munkamenetet.

Refresh Token vs Access Token

Access token és refresh token különböző funkciókat töltenek be és alapvetően különböző biztonsági jellemzőkkel rendelkeznek. Az access token ideiglenes belépő az API-hoz, a refresh token hosszú távú engedély új belépők beszerzésére.

Miért nem lehet az access token hosszú élettartamú

Rövid TTL (élettartam) az access token esetén — tudatos biztonsági kompromisszum. Ha az access tokent ellopják (forgalom elfogásával, naplószivárgással, rosszindulatú programmal az eszközön), az idő, amíg a támadó használhatja, 15–60 percre korlátozódik. A refresh token azáltal védett, hogy soha nem kerül elküldésre minden kéréssel — elfogása célzott támadást igényel a token endpoint ellen. A Auth0 Security Team, 2025 szerint a kompromittált access tokenek 90%-a nem biztonságos hálózati kapcsolatokon keresztül került elfogásra — pontosan az, ami ellen a refresh token az architektúrája által védett.

A Refresh Token biztonsága

Biztonság a refresh token esetén — a teljes hitelesítési rendszer kritikus eleme. Mivel a refresh token teljes hozzáférést biztosít a fiókhoz hosszú időn keresztül, védelmének maximálisnak kell lennie. Az OWASP és az OAuth Security Best Practices konkrét követelményeket tesz közzé.

Refresh token tárolása mobileszközökön

Helyes tárolás a platformtól függ. iOS-en — Keychain kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly hozzáféréssel. Ez garantálja, hogy a token nem érhető el, ha az eszköz jelszavát eltávolítják. Androidon — EncryptedSharedPreferences az AndroidX Security Library-ből, a rendszergazda kulccsal az Android Keystore-ban. A token fájlszinten van titkosítva, és még root hozzáféréssel sem érhető el. Tilos: refresh token tárolása SharedPreferences-ben, NSUserDefaults-ban, plain-text fájlokban vagy Base64-ben titkosítás nélkül.

A Google Security Blog, 2025 szerint az AES256-GCM-mel ellátott EncryptedSharedPreferences 99.7%-kal csökkenti a token szivárgásának kockázatát a hagyományos SharedPreferences-hez képest fizikai eszközhozzáférés esetén. A biztonság fokozása érdekében ajánlott a tárolók szétválasztása is: az access token tárolható az operatív memóriában (rövid távú hozzáférés), a refresh token — csak a biztonságos rendszertárolóban (Keychain / Keystore). Ha az alkalmazás foreground jelet kap a rendszertől, a refresh token érvényessége ellenőrződik, és szükség esetén frissül, mielőtt a felhasználó megkezdené az interakciót.

Refresh Token Rotation

Refresh token rotation — olyan mechanizmus, amelyben minden access token frissítési kérés új refresh tokent ad vissza, és a régit törli. Ha egy támadó ellopott egy refresh tokent és használja, a jogos kliens a következő frissítési próbálkozáskor hibát kap — a szerver érzékeli, hogy a refresh token már használatban volt (reuse detection). A rotation az OAuth 2.0 Security Best Current Practice (RFC 9700) kötelező ajánlása minden olyan rendszer számára, amely hosszú élettartamú tokenekkel dolgozik mobil környezetben.

Reuse Detection

A detection algoritmusa így működik: a szerver „used” jelzőt tárol az adatbázisban minden kiadott refresh tokenhez. A frissítési kérésnél a szerver ellenőrzi — ha a refresh token már használtként van megjelőlve, ez ismételt használati kísérletet jelent. A szerver azonnal érvényteleníti a munkamenet összes refresh tokenjét és blokkolja a hozzáférést. A jogos felhasználó átirányítódik a bejelentkezési oldalra. Ez megakadályozza a refresh token lopási támadásokat: a támadó hozzáférést szerez, de a munkamenet azonnal blokkolódik észlelés után.

A OAuth Security Workshop, 2025 szerint a rotation + reuse detection bevezetésével a sikeres támadás valószínűsége ellopott refresh token segítségével 23%-ról 0.3%-ra csökken. A reuse detection megvalósításához a szerver az utolsó kiadott refresh token hash-ét tárolja a client_id-vel párosítva. A frissítési kérésnél a szerver összehasonlítja a bemutatott refresh tokent a tárolttal — ha nem egyeznek, az ismételt használatot jelent, és a teljes tokenlánc érvénytelenítődik.

Az invalid_grant hiba kézhezvételekor a kliensnek teljes kijelentkezést kell végrehajtania: törölnie kell az összes tárolt tokent (access és refresh), be kell fejeznie az aktuális munkamenetet az eszközön, és át kell irányítania a felhasználót a bejelentkezési képernyőre. Az újrahitelesítés új tokenláncot hoz létre, amely nem kapcsolódik az előzőhöz. A hiba figyelmen kívül hagyása és az ismételt frissítési kísérletek a reuse detection általi blokkoláshoz vezetnek.

Megvalósítás Kotlinban

Példa a token frissítés kliens oldali megvalósítására Kotlinban Androidhoz. Az alkalmazás elfogja a HTTP 401-es választ, meghív egy frissítési kérést, és megismétli az eredeti kérést az új access tokennal. OkHttp Interceptor használatos — egy kulcsfontosságú komponens a tokenek automatikus kezeléséhez anélkül, hogy a logikát minden kérésben meg kellene ismételni.

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 lejárt — frissítjük refresh token segítségével
        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")
        // Új refresh token mentése rotation esetén
        saveTokens(newAccessToken, json.optString("refresh_token"))
        return newAccessToken
    }
}