Refresh Token para sa mga mobile app — esensya, mekanismo ng pag-refresh, at ligtas na imbakan

Ano ang Refresh Token?

Refresh Token — ay isang kredensyal na ginagamit ng client application upang makakuha ng bagong access token pagkatapos mag-expire ang kasalukuyan. Hindi tulad ng access token, ang refresh token ay hindi ipinapadala sa bawat API request — ito ay naka-imbak sa isang ligtas na imbakan sa client at ginagamit lamang kapag ina-access ang token endpoint ng authentication server.

Ang pangunahing ideya ay paghiwalayin ang dalawang token na may magkaibang haba ng buhay. Ang access token na may maikling TTL ay nagbabawas ng window ng pag-atake kapag ito ay naharang: kung ang access token ay ninakaw, magagamit lamang ito ng attacker sa loob ng ilang minuto. Refresh token ay protektado sa pamamagitan ng hindi pagpapadala nito sa mga ordinaryong request — sa pamamagitan lamang ng secure na channel sa token endpoint. Ginagawa nitong mas mahirap ang pagnanakaw nito.

Ayon sa OAuth Security Workshop, 2025, ang pagpapatupad ng refresh token na may rotation ay nagbabawas ng panganib ng kompromiso ng session ng 85% kumpara sa pag-iimbak ng isang mahabang-buhay na access token.

Paano Gumagana ang Refresh Token

Ang proseso ng pag-refresh ay na-trigger kapag ang client ay nakatanggap ng HTTP 401 Unauthorized na tugon o nakita na ang access token ay nag-expire (pagsusuri ng exp sa JWT). Ang client ay nagpapadala ng POST request sa token endpoint ng server na may grant_type=refresh_token at ang refresh token mismo sa katawan ng request. Sinusuri ng server ang validity ng refresh token, ang expiration date nito, at ang pag-aari nito sa client_id. Kung tama ang lahat — ang server ay nagbabalik ng bagong access token at, opsyonal, isang bagong refresh token.

Daloy ng Pag-refresh ng Token

Ang iskema ng refresh request ay ganito: ang client ay nagpapadala ng POST sa /oauth/token na may mga parameter na grant_type=refresh_token, refresh_token={token}, at client_id={id}. Ang server ay nagbabalik ng JSON na may bagong access token at expiration:

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

Refresh token rotation (pagbabalik ng bagong refresh token) ay inirerekomenda ng OAuth 2.0 Security Best Current Practice (RFC 9700). Ang lumang refresh token ay na-i-invalidate sa prosesong ito. Kung ang isang attacker ay nagnakaw ng lumang refresh token at nagamit ito bago ang lehitimong client, makikita ng server ang paulit-ulit na paggamit — reuse detection — at blinoblock ang buong session.

Refresh Token vs Access Token

Access token at refresh token ay may magkaibang function at may fundamentally magkaibang mga katangian ng seguridad. Ang access token ay isang pansamantalang pass sa API, ang refresh token ay isang pangmatagalang awtorisasyon upang makakuha ng mga bagong pass.

Bakit hindi maaaring maging mahabang-buhay ang access token

Maikling TTL ng access token — ito ay isang sinadyang kompromiso sa seguridad. Kung ang access token ay ninakaw (sa pamamagitan ng pagharang ng trapiko, pagtagas ng log, malware sa device), ang oras kung saan magagamit ito ng attacker ay limitado sa 15–60 minuto. Ang refresh token ay protektado sa pamamagitan ng hindi pagpapadala nito sa bawat request — ang pagharang nito ay nangangailangan ng isang target na pag-atake sa token endpoint. Ayon sa Auth0 Security Team, 2025, 90% ng mga nakompromisong access token ay naharang sa pamamagitan ng hindi secure na mga koneksyon sa network — eksakto kung saan ang refresh token ay protektado ng sarili nitong arkitektura.

Seguridad ng Refresh Token

Seguridad ng refresh token — kritikal na elemento ng buong authentication scheme. Dahil ang refresh token ay nagbibigay ng buong access sa account sa mahabang panahon, ang proteksyon nito ay dapat na maximum. Ang OWASP at OAuth Security Best Practices ay naglalathala ng mga tiyak na kinakailangan.

Pag-iimbak ng refresh token sa mga mobile device

Tamang pag-iimbak ay depende sa platform. Sa iOS — Keychain na may access na kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly. Ginagarantiyahan nito na ang token ay hindi available kapag ang password ng device ay inalis. Sa Android — EncryptedSharedPreferences mula sa AndroidX Security Library na may master key sa Android Keystore. Ang token ay naka-encrypt sa antas ng file system at hindi available kahit na may root access. Ipinagbabawal: mag-imbak ng refresh token sa SharedPreferences, NSUserDefaults, plain-text na mga file, o sa Base64 nang walang encryption.

Ayon sa Google Security Blog, 2025, ang EncryptedSharedPreferences na may AES256-GCM ay nagbabawas ng panganib ng pagtagas ng token ng 99.7% kumpara sa ordinaryong SharedPreferences sa pisikal na access sa device. Para sa pagpapalakas ng seguridad, inirerekomenda din ang paghiwalayin ang mga imbakan: ang access token ay maaaring iimbak sa operational memory (panandaliang access), refresh token — sa secure na system storage lamang (Keychain / Keystore). Kung ang app ay nakatanggap ng foreground signal mula sa system, ang refresh token ay sinusuri para sa validity at kung kinakailangan ay nire-refresh bago magsimula ang gumagamit ng interaksyon.

Refresh Token Rotation

Refresh token rotation — ay isang mekanismo kung saan ang bawat request na mag-refresh ng access token ay nagbabalik ng bagong refresh token, at ang luma ay kinakansela. Kung ang isang attacker ay nagnakaw ng refresh token at ginamit ito, ang lehitimong client ay makakatanggap ng error sa susunod na pagtatangka ng pag-refresh — makikita ng server na ang refresh token ay nagamit na (reuse detection). Ang rotation ay isang mandatoryong rekomendasyon ng OAuth 2.0 Security Best Current Practice (RFC 9700) para sa lahat ng system na nagtatrabaho sa mahabang-buhay na mga token sa mobile environment.

Reuse Detection

Algorithm ng detection ay ganito gumagana: ang server ay nag-iimbak sa database ng markang “used” para sa bawat inisyung refresh token. Sa refresh request, sinusuri ng server — kung ang refresh token ay minarkahan na bilang ginamit, nangangahulugan ito ng pagtatangka ng paulit-ulit na paggamit. Agad na i-i-invalidate ng server ang lahat ng refresh token ng session na ito at blinoblock ang access. Ang lehitimong gumagamit ay nire-redirect sa login page. Pinipigilan nito ang mga pag-atake ng pagnanakaw ng refresh token: ang attacker ay nakakakuha ng access, ngunit ang session ay blinoblock kaagad pagkatapos ng detection.

Ayon sa OAuth Security Workshop, 2025, sa pagpapatupad ng rotation + reuse detection, ang posibilidad ng matagumpay na pag-atake sa pamamagitan ng ninakaw na refresh token ay bumababa mula 23% hanggang 0.3%. Para sa implementasyon ng reuse detection, ang server ay nag-iimbak ng hash ng huling inisyung refresh token kasama ng client_id. Sa refresh request, ikinukumpara ng server ang ipinakitang refresh token sa naka-imbak — kung hindi sila magkatugma, nangangahulugan ito ng paulit-ulit na paggamit at ang buong chain ng token ay kinakansela.

Sa pagtanggap ng error na invalid_grant, ang client ay dapat magsagawa ng buong logout: linisin ang lahat ng naka-imbak na token (access at refresh), tapusin ang kasalukuyang session sa device, at i-redirect ang gumagamit sa login screen. Ang muling pag-authenticate ay lumilikha ng bagong chain ng token na hindi nauugnay sa nauna. Ang pagwawalang-bahala sa error na ito at paulit-ulit na pagtatangka ng pag-refresh ay hahantong sa pag-block sa pamamagitan ng reuse detection.

Implementasyon sa Kotlin

Halimbawa ng implementasyon ng client-side na pag-refresh ng token sa Kotlin para sa Android. Ina-intercept ng app ang HTTP 401 na tugon, tinatawagan ang refresh request, at inuulit ang orihinal na request na may bagong access token. Ginagamit ang OkHttp Interceptor — isang mahalagang component para sa awtomatikong pamamahala ng token nang hindi nagda-duplicate ng logic sa bawat request.

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 nag-expire — nire-refresh sa pamamagitan ng 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")
        // I-save ang bagong refresh token sa rotation
        saveTokens(newAccessToken, json.optString("refresh_token"))
        return newAccessToken
    }
}