Refresh Token untuk aplikasi mobile — esensi, mekanisme pembaruan, dan penyimpanan aman

Apa itu Refresh Token?

Refresh Token — adalah kredensial yang digunakan aplikasi klien untuk mendapatkan access token baru setelah yang saat ini kedaluwarsa. Berbeda dengan access token, refresh token tidak dikirim dengan setiap permintaan API — disimpan di penyimpanan aman di sisi klien dan hanya digunakan saat mengakses token endpoint server autentikasi.

Ide utamanya adalah memisahkan dua token dengan masa hidup berbeda. Access token dengan TTL pendek mengurangi jendela serangan saat dicegat: jika access token dicuri, penyerang hanya dapat menggunakannya selama beberapa menit. Refresh token dilindungi dengan tidak pernah dikirim bersama permintaan biasa — hanya melalui saluran aman ke token endpoint. Ini membuat pencuriannya jauh lebih sulit.

Menurut OAuth Security Workshop, 2025, penerapan refresh token dengan rotation mengurangi risiko kompromi sesi sebesar 85% dibandingkan dengan menyimpan satu access token berumur panjang.

Bagaimana Refresh Token Bekerja

Proses pembaruan dimulai ketika klien menerima respons HTTP 401 Unauthorized atau mendeteksi bahwa access token telah kedaluwarsa (pengecekan exp di JWT). Klien mengirim permintaan POST ke token endpoint server dengan grant_type=refresh_token dan refresh token itu sendiri di badan permintaan. Server memeriksa validitas refresh token, masa berlakunya, dan kepemilikannya terhadap client_id. Jika semuanya benar — server mengembalikan access token baru dan, secara opsional, refresh token baru.

Alur Pembaruan Token

Skema permintaan pembaruan terlihat sebagai berikut: klien mengirim POST ke /oauth/token dengan parameter grant_type=refresh_token, refresh_token={token}, dan client_id={id}. Server mengembalikan JSON dengan access token baru dan masa kedaluwarsa:

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

Refresh token rotation (pengembalian refresh token baru) direkomendasikan oleh OAuth 2.0 Security Best Current Practice (RFC 9700). Refresh token lama dinonaktifkan dalam proses ini. Jika penyerang mencuri refresh token lama dan berhasil menggunakannya sebelum klien yang sah, server akan mendeteksi penggunaan berulang — reuse detection — dan memblokir seluruh sesi.

Refresh Token vs Access Token

Access token dan refresh token menjalankan fungsi berbeda dan memiliki karakteristik keamanan yang fundamental berbeda. Access token adalah izin sementara ke API, refresh token adalah otorisasi jangka panjang untuk mendapatkan izin baru.

Mengapa access token tidak bisa berumur panjang

TTL pendek access token — ini adalah kompromi keamanan yang disadari. Jika access token dicuri (melalui penyadapan lalu lintas, kebocoran log, perangkat lunak berbahaya di perangkat), waktu di mana penyerang dapat menggunakannya terbatas hingga 15–60 menit. Refresh token dilindungi dengan tidak pernah dikirim dengan setiap permintaan — penyadapannya memerlukan serangan terarah pada token endpoint. Menurut Auth0 Security Team, 2025, 90% access token yang dikompromi disadap melalui koneksi jaringan yang tidak aman — persis apa yang dilindungi oleh arsitektur refresh token.

Keamanan Refresh Token

Keamanan refresh token — elemen kritis dari seluruh skema autentikasi. Karena refresh token memberikan akses penuh ke akun untuk jangka waktu lama, perlindungannya harus maksimal. OWASP dan OAuth Security Best Practices menerbitkan persyaratan khusus.

Penyimpanan refresh token di perangkat mobile

Penyimpanan yang benar tergantung pada platform. Di iOS — Keychain dengan akses kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly. Ini menjamin bahwa token tidak tersedia saat kata sandi perangkat dihapus. Di Android — EncryptedSharedPreferences dari AndroidX Security Library dengan kunci master di Android Keystore. Token dienkripsi di tingkat sistem file dan tidak tersedia bahkan dengan akses root. Dilarang: menyimpan refresh token di SharedPreferences, NSUserDefaults, file teks biasa, atau di Base64 tanpa enkripsi.

Menurut Google Security Blog, 2025, EncryptedSharedPreferences dengan AES256-GCM mengurangi risiko kebocoran token sebesar 99.7% dibandingkan SharedPreferences biasa saat akses fisik ke perangkat. Untuk meningkatkan keamanan, disarankan juga memisahkan penyimpanan: access token dapat disimpan di memori operasional (akses jangka pendek), refresh token — hanya di penyimpanan sistem yang aman (Keychain / Keystore). Jika aplikasi menerima sinyal foreground dari sistem, refresh token diperiksa validitasnya dan jika perlu diperbarui sebelum pengguna memulai interaksi.

Refresh Token Rotation

Refresh token rotation — adalah mekanisme di mana setiap permintaan pembaruan access token mengembalikan refresh token baru, dan yang lama dibatalkan. Jika penyerang mencuri refresh token dan menggunakannya, klien yang sah akan menerima kesalahan pada percobaan pembaruan berikutnya — server akan mendeteksi bahwa refresh token sudah digunakan (reuse detection). Rotation adalah rekomendasi wajib OAuth 2.0 Security Best Current Practice (RFC 9700) untuk semua sistem yang bekerja dengan token berumur panjang di lingkungan mobile.

Reuse Detection

Algoritma deteksi bekerja sebagai berikut: server menyimpan di database tanda “used” untuk setiap refresh token yang diterbitkan. Saat permintaan pembaruan, server memeriksa — jika refresh token sudah ditandai sebagai digunakan, berarti telah terjadi percobaan penggunaan berulang. Server segera menonaktifkan semua refresh token sesi ini dan memblokir akses. Pengguna yang sah diarahkan ke halaman masuk. Ini mencegah serangan pencurian refresh token: penyerang mendapatkan akses, tetapi sesi diblokir segera setelah terdeteksi.

Menurut OAuth Security Workshop, 2025, dengan penerapan rotation + reuse detection, kemungkinan serangan berhasil melalui refresh token curian turun dari 23% menjadi 0.3%. Untuk implementasi reuse detection, server menyimpan hash dari refresh token terakhir yang diterbitkan bersama dengan client_id. Saat permintaan pembaruan, server membandingkan refresh token yang disajikan dengan yang disimpan — jika tidak cocok, berarti terjadi penggunaan berulang dan seluruh rantai token dibatalkan.

Saat menerima kesalahan invalid_grant, klien harus melakukan logout penuh: menghapus semua token yang disimpan (access dan refresh), mengakhiri sesi saat ini di perangkat, dan mengarahkan pengguna ke layar masuk. Autentikasi ulang membuat rantai token baru yang tidak terkait dengan yang sebelumnya. Mengabaikan kesalahan ini dan percobaan pembaruan berulang akan menyebabkan pemblokiran melalui reuse detection.

Implementasi di Kotlin

Contoh implementasi bagian klien pembaruan token di Kotlin untuk Android. Aplikasi mencegat respons HTTP 401, memanggil permintaan pembaruan, dan mengulangi permintaan asli dengan access token baru. OkHttp Interceptor digunakan — komponen kunci untuk manajemen token otomatis tanpa menduplikasi logika di setiap permintaan.

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 kedaluwarsa — perbarui melalui 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")
        // Simpan refresh token baru saat rotation
        saveTokens(newAccessToken, json.optString("refresh_token"))
        return newAccessToken
    }
}