Mengapa Anda memerlukan access token dan refresh token sekaligus?

Question

IT Interview Practice · Accepted Answer

Kedua token ada untuk menyelesaikan konflik langsung: access token harus **dikirim pada setiap request** (jadi sangat terekspos), namun Anda juga ingin sesi yang **bertahan lama** tanpa memaksa login sering. Anda tidak bisa memiliki keduanya secara aman dalam satu token — jadi Anda memecah tugasnya.

## Dua peran

- **Access token** — berumur pendek (biasanya 5–15 menit), dikirim di header `Authorization` pada setiap panggilan API. Karena ditransmisikan terus-menerus, kebocoran sangat mungkin; membuatnya pendek berarti yang dicuri hampir langsung kedaluwarsa.
- **Refresh token** — berumur panjang (hari/minggu), dikirim **hanya** ke token endpoint server auth untuk memperoleh access token baru. Ia jarang bepergian, bisa disimpan lebih aman, dan bisa dicabut di sisi server.

```
Login ──▶ access (15m) + refresh (30d)
Setiap panggilan API ──▶ kirim access
Access kedaluwarsa ──▶ kirim refresh ──▶ access baru (+ refresh yang dirotasi)
```

## Mengapa tidak satu token saja?

| | Satu access token berumur panjang | Access + refresh |
|---|---|---|
| Eksposur | Dikirim tiap request, hidup lama → jendela pencurian besar | Access berumur pendek; refresh jarang dikirim |
| Pencabutan | Sulit (JWT stateless tidak bisa dibatalkan) | Cabut refresh token; access mati dalam hitungan menit |
| UX | Login ulang sering jika pendek | Tetap login tanpa memasukkan kredensial lagi |
| Radius ledakan kebocoran | Besar | Kecil (access cepat kedaluwarsa) |

- **Satu access token pendek, tanpa refresh** → aman, tetapi pengguna logout setiap beberapa menit. UX buruk.
- **Satu access token panjang** → UX bagus, tetapi token yang bocor valid untuk waktu lama dan tidak mudah dicabut.
- **Access + refresh** → jendela eksposur pendek *dan* sesi panjang. Refresh token adalah satu-satunya rahasia berumur panjang, dan ia berada di satu tempat aman.

## Apa yang dimungkinkan oleh pemisahan ini

- **Pencabutan meski access token stateless.** Anda tidak bisa membatalkan JWT access token sebelum kedaluwarsa, tetapi Anda *bisa* menghapus/menolak refresh token, jadi sesi berakhir pada refresh berikutnya (dalam hitungan menit).
- **Rotasi refresh token** — terbitkan refresh token baru pada setiap penggunaan dan deteksi penggunaan ulang yang lama (tanda pencurian), lalu cabut seluruh rantainya.
- **Eksposur paling minim** — rahasia berumur panjang (refresh) dikirim ke tepat satu endpoint, idealnya disimpan dalam cookie `httpOnly`, di luar jangkauan XSS.

## Mengapa ini penting

Ini adalah desain auth modern yang standar, dan pewawancara menanyakannya untuk melihat apakah Anda memahami *mengapa*, bukan sekadar *bagaimana*. Wawasan kuncinya adalah trade-off: statelessness dan eksposur pendek (access) versus sesi panjang dan kemampuan dicabut (refresh). Melakukannya salah — access token berumur panjang, tanpa rotasi, refresh disimpan di `localStorage` — mengubah satu token yang bocor menjadi kompromi akun berumur panjang. Menyebutkan pemisahan dan apa yang diberikan masing-masing token adalah yang diharapkan diketahui oleh insinyur yang sadar keamanan.

	Satu access token berumur panjang	Access + refresh
Eksposur	Dikirim tiap request, hidup lama → jendela pencurian besar	Access berumur pendek; refresh jarang dikirim
Pencabutan	Sulit (JWT stateless tidak bisa dibatalkan)	Cabut refresh token; access mati dalam hitungan menit
UX	Login ulang sering jika pendek	Tetap login tanpa memasukkan kredensial lagi
Radius ledakan kebocoran	Besar	Kecil (access cepat kedaluwarsa)

Dua peran

Mengapa tidak satu token saja?

Apa yang dimungkinkan oleh pemisahan ini

Mengapa ini penting

Pertanyaan terkait