Refresh Token för mobilappar — innebörd, uppdateringsmekanism och säker lagring

Vad är Refresh Token?

Refresh Token — är en credential som klientapplikationen använder för att få en ny access token efter att den nuvarande har upphört att gälla. Till skillnad från access token skickas inte refresh token med varje API-begäran — den lagras i en säker lagring på klienten och används endast när token endpoint på autentiseringsservern anropas.

Huvudidén är att separera två tokens med olika livslängder. Access token med kort TTL minskar attackfönstret vid avlyssning: om access token blir stulen kan angriparen bara använda den i några minuter. Refresh token skyddas genom att den aldrig skickas med vanliga begäran — endast via en säker kanal till token endpoint. Detta gör stöld betydligt svårare.

Enligt OAuth Security Workshop, 2025 minskar implementering av refresh token med rotation risken för sessionskompromettering med 85% jämfört med att lagra en enda långlivad access token.

Hur fungerar Refresh Token

Uppdateringsprocessen startas när klienten får ett HTTP 401 Unauthorized-svar eller upptäcker att access token har upphört att gälla (kontroll av exp i JWT). Klienten skickar en POST-begäran till serverns token endpoint med grant_type=refresh_token och själva refresh token i begärans brödtext. Servern kontrollerar refresh tokens giltighet, dess utgångsdatum och tillhörighet till client_id. Om allt är korrekt — returnerar servern en ny access token och, eventuellt, en ny refresh token.

Tokenuppdateringsflöde

Schemat för uppdateringsbegäran ser ut som följer: klienten skickar en POST till /oauth/token med parametrarna grant_type=refresh_token, refresh_token={token} och client_id={id}. Servern returnerar en JSON med den nya access token och utgång:

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

Refresh token rotation (returnering av en ny refresh token) rekommenderas av OAuth 2.0 Security Best Current Practice (RFC 9700). Den gamla refresh token ogiltigförklaras därmed. Om en angripare har stulit den gamla refresh token och hunnit använda den före den legitima klienten kommer servern att upptäcka återanvändning — reuse detection — och blockera hela sessionen.

Refresh Token vs Access Token

Access token och refresh token har olika funktioner och har fundamentalt olika säkerhetsegenskaper. Access token är ett tillfälligt passerkort till API:et, refresh token är en långvarig auktorisation för att få nya passerkort.

Varför access token inte kan vara långlivad

Kort TTL för access token — är en medveten säkerhetskompromiss. Om access token blir stulen (genom trafikavlyssning, loggläckage, skadlig programvara på enheten) är tiden som angriparen kan använda den begränsad till 15–60 minuter. Refresh token skyddas genom att den aldrig skickas med varje begäran — avlyssning av den kräver en riktad attack mot token endpoint. Enligt Auth0 Security Team, 2025 avlyssnades 90% av komprometterade access tokens via oskyddade nätverksanslutningar — precis vad refresh token skyddas mot genom sin arkitektur.

Säkerhet för Refresh Token

Säkerhet för refresh token — en kritisk komponent i hela autentiseringsschemat. Eftersom refresh token ger full tillgång till kontot under en lång period måste dess skydd vara maximalt. OWASP och OAuth Security Best Practices publicerar specifika krav.

Lagring av refresh token på mobila enheter

Korrekt lagring beror på plattformen. På iOS — Keychain med åtkomst kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly. Detta garanterar att token inte är tillgänglig när enhetens lösenord tas bort. På Android — EncryptedSharedPreferences från AndroidX Security Library med huvudnyckeln i Android Keystore. Token krypteras på filsystemnivå och är inte tillgänglig ens med root-åtkomst. Förbjudet: lagra refresh token i SharedPreferences, NSUserDefaults, plain-text-filer eller i Base64 utan kryptering.

Enligt Google Security Blog, 2025 minskar EncryptedSharedPreferences med AES256-GCM risken för tokenläckage med 99.7% jämfört med vanliga SharedPreferences vid fysisk åtkomst till enheten. För att stärka säkerheten rekommenderas också att separera lagringarna: access token kan lagras i arbetsminnet (kortvarig åtkomst), refresh token — endast i säker systemlagring (Keychain / Keystore). Om applikationen får en foreground-signal från systemet kontrolleras refresh token för giltighet och uppdateras vid behov innan användaren börjar interagera.

Refresh Token Rotation

Refresh token rotation — är en mekanism där varje begäran om att uppdatera access token returnerar en ny refresh token och den gamla annulleras. Om en angripare har stulit en refresh token och använder den kommer den legitima klienten att få ett fel vid nästa uppdateringsförsök — servern upptäcker att refresh token redan har använts (reuse detection). Rotation är en obligatorisk rekommendation från OAuth 2.0 Security Best Current Practice (RFC 9700) för alla system som arbetar med långlivade tokens i mobil miljö.

Reuse Detection

Detektionsalgoritmen fungerar så här: servern lagrar i databasen en markering „used” för varje utfärdad refresh token. Vid en uppdateringsbegäran kontrollerar servern — om refresh token redan är markerad som använd innebär det ett försök till återanvändning. Servern ogiltigförklarar omedelbart alla refresh tokens i denna session och blockerar åtkomsten. Den legitima användaren omdirigeras till inloggningssidan. Detta förhindrar attacker med stulna refresh tokens: angriparen får tillgång men sessionen blockeras omedelbart efter upptäckt.

Enligt OAuth Security Workshop, 2025 minskar sannolikheten för en lyckad attack via en stulen refresh token från 23% till 0.3% vid implementering av rotation + reuse detection. För implementering av reuse detection lagrar servern hashvärdet för den senast utfärdade refresh token tillsammans med client_id. Vid en uppdateringsbegäran jämför servern den presenterade refresh token med den lagrade — om de inte matchar innebär det återanvändning och hela tokenkedjan annulleras.

När felet invalid_grant tas emot bör klienten utföra en fullständig utloggning: rensa alla lagrade tokens (access och refresh), avsluta den aktuella sessionen på enheten och omdirigera användaren till inloggningsskärmen. Omautentisering skapar en ny tokenkedja som inte är kopplad till den föregående. Att ignorera detta fel och upprepa uppdateringsförsök kommer att leda till blockering via reuse detection.

Implementering i Kotlin

Exempel på implementering av klientsidan för tokenuppdatering i Kotlin för Android. Applikationen fångar upp HTTP 401-svaret, anropar en uppdateringsbegäran och upprepar den ursprungliga begäran med den nya access token. OkHttp Interceptor används — en nyckelkomponent för automatisk tokenhantering utan att duplicera logik i varje begäran.

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 har upphört att gälla — uppdaterar via 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")
        // Spara ny refresh token vid rotation
        saveTokens(newAccessToken, json.optString("refresh_token"))
        return newAccessToken
    }
}