Mengapa anda memerlukan kedua-dua access token dan refresh token?

Question

IT Interview Practice · Accepted Answer

Kedua-dua token wujud untuk menyelesaikan satu konflik langsung: access token mesti **dihantar pada setiap request** (jadi ia banyak terdedah), namun anda juga mahukan sesi yang **bertahan lama** tanpa memaksa log masuk kerap. Anda tidak boleh memiliki kedua-duanya dengan selamat dalam satu token — jadi anda membahagikan tugas itu.

## Dua peranan

- **Access token** — jangka pendek (biasanya 5–15 minit), dihantar dalam header `Authorization` pada setiap panggilan API. Kerana ia dihantar berterusan, kebocoran berkemungkinan tinggi; mengekalkannya pendek bermakna yang dicuri tamat tempoh hampir serta-merta.
- **Refresh token** — jangka panjang (hari/minggu), dihantar **hanya** ke token endpoint pelayan auth untuk mendapatkan access token baharu. Ia jarang bergerak, boleh disimpan dengan lebih selamat, dan boleh dibatalkan di sisi pelayan.

```
Login ──▶ access (15m) + refresh (30d)
Setiap panggilan API ──▶ hantar access
Access tamat ──▶ hantar refresh ──▶ access baharu (+ refresh dipusing)
```

## Mengapa bukan sekadar satu token?

| | Satu access token jangka panjang | Access + refresh |
|---|---|---|
| Pendedahan | Dihantar setiap request, hidup lama → tetingkap kecurian besar | Access jangka pendek; refresh jarang dihantar |
| Pembatalan | Sukar (JWT stateless tidak boleh dinyahterbit) | Batalkan refresh token; access mati dalam beberapa minit |
| UX | Log masuk semula kerap jika pendek | Kekal log masuk tanpa memasukkan semula kelayakan |
| Radius letupan kebocoran | Besar | Kecil (access tamat cepat) |

- **Satu access token pendek, tiada refresh** → selamat, tetapi pengguna dilog keluar setiap beberapa minit. UX yang teruk.
- **Satu access token panjang** → UX yang hebat, tetapi token yang bocor sah untuk tempoh yang lama dan tidak boleh dibatalkan dengan mudah.
- **Access + refresh** → tetingkap pendedahan pendek *dan* sesi panjang. Refresh token ialah satu-satunya rahsia jangka panjang, dan ia berada di satu tempat yang selamat.

## Apa yang dibolehkan oleh pembahagian ini

- **Pembatalan walaupun access token stateless.** Anda tidak boleh membatalkan JWT access token sebelum ia tamat tempoh, tetapi anda *boleh* memadam/menolak refresh token, jadi sesi berakhir pada refresh berikutnya (dalam beberapa minit).
- **Rotation refresh token** — keluarkan refresh token baharu pada setiap penggunaan dan kesan penggunaan semula yang lama (tanda kecurian), kemudian batalkan seluruh rantaian.
- **Pendedahan paling minimum** — rahsia jangka panjang (refresh) dihantar ke tepat satu endpoint, idealnya disimpan dalam cookie `httpOnly`, di luar jangkauan XSS.

## Mengapa ia penting

Ini ialah reka bentuk auth moden yang standard, dan penemu duga bertanya untuk melihat sama ada anda memahami *mengapa*, bukan sekadar *bagaimana*. Cerapan utama ialah trade-off: statelessness dan pendedahan pendek (access) berbanding sesi panjang dan keupayaan pembatalan (refresh). Salah melakukannya — access token jangka panjang, tiada rotation, refresh disimpan dalam `localStorage` — menukar satu token yang bocor menjadi kompromi akaun jangka panjang. Menamakan pembahagian itu dan apa yang diberikan oleh setiap token ialah perkara yang seorang jurutera yang sedar keselamatan dijangka tahu.

	Satu access token jangka panjang	Access + refresh
Pendedahan	Dihantar setiap request, hidup lama → tetingkap kecurian besar	Access jangka pendek; refresh jarang dihantar
Pembatalan	Sukar (JWT stateless tidak boleh dinyahterbit)	Batalkan refresh token; access mati dalam beberapa minit
UX	Log masuk semula kerap jika pendek	Kekal log masuk tanpa memasukkan semula kelayakan
Radius letupan kebocoran	Besar	Kecil (access tamat cepat)

Dua peranan

Mengapa bukan sekadar satu token?

Apa yang dibolehkan oleh pembahagian ini

Mengapa ia penting

Soalan berkaitan