Pse ke nevojë si për një access token ashtu edhe për një refresh token?

Question

IT Interview Practice · Accepted Answer

Të dy token-ët ekzistojnë për të zgjidhur një konflikt të drejtpërdrejtë: një access token duhet të **dërgohet në çdo kërkesë** (kështu që ekspozohet shumë), por ti gjithashtu do seanca që **zgjasin gjatë** pa detyruar hyrje të shpeshta. Nuk mund t'i kesh të dyja në mënyrë të sigurt në një token të vetëm — kështu që e ndan punën.

## Dy rolet

- **Access token** — jetëshkurtër (zakonisht 5–15 minuta), dërgohet në header-in `Authorization` në çdo thirrje API. Meqenëse transmetohet vazhdimisht, një rrjedhje është e mundshme; mbajtja e tij e shkurtër do të thotë se një i vjedhur skadon pothuajse menjëherë.
- **Refresh token** — jetëgjatë (ditë/javë), dërgohet **vetëm** te endpoint-i i token-it i serverit të autentikimit për të marrë access token të reja. Udhëton rrallë, mund të ruhet më sigurt dhe mund të revokohet nga ana e serverit.

```
Login ──▶ access (15m) + refresh (30d)
Çdo thirrje API ──▶ dërgo access
Access skadoi ──▶ dërgo refresh ──▶ access i ri (+ refresh i rrotulluar)
```

## Pse jo vetëm një token?

| | Një access token jetëgjatë | Access + refresh |
|---|---|---|
| Ekspozimi | Dërgohet në çdo kërkesë, jeton gjatë → dritare e madhe vjedhjeje | Access jetëshkurtër; refresh dërgohet rrallë |
| Revokimi | I vështirë (një JWT stateless nuk mund të ç'lëshohet) | Revoko refresh token-in; access-i vdes brenda minutash |
| UX | Rihyrje e shpeshtë nëse është i shkurtër | Mbetesh i loguar pa rifutur kredencialet |
| Rrezja e shpërthimit të rrjedhjes | E madhe | E vogël (access-i skadon shpejt) |

- **Një access token i shkurtër, pa refresh** → i sigurt, por përdoruesi çlogohet çdo pak minuta. UX e tmerrshme.
- **Një access token i gjatë** → UX i shkëlqyer, por një token i rrjedhur është i vlefshëm për një kohë të gjatë dhe nuk mund të revokohet lehtë.
- **Access + refresh** → dritare ekspozimi e shkurtër *dhe* seanca të gjata. Refresh token-i është i vetmi sekret jetëgjatë dhe rri në një vend të vetëm të sigurt.

## Çfarë mundëson ndarja

- **Revokim pavarësisht access token-ëve stateless.** Nuk mund të çvlefshmërosh një access token JWT para se të skadojë, por *mund* ta fshish/mohosh refresh token-in, kështu që seanca përfundon në rifreskimin e ardhshëm (brenda minutash).
- **Rotacioni i refresh token-it** — lësho një refresh token të ri në çdo përdorim dhe zbulo ripërdorimin e një të vjetri (shenjë vjedhjeje), pastaj revoko të gjithë zinxhirin.
- **Ekspozim minimal** — sekreti jetëgjatë (refresh) dërgohet te saktësisht një endpoint, idealisht i ruajtur në një cookie `httpOnly`, jashtë mundësisë së XSS-së.

## Pse ka rëndësi

Ky është dizajni standard modern i autentikimit, dhe intervistuesit e pyesin për të parë nëse e kupton *pse*-në, jo vetëm *si*-në. Kuptimi kyç është kompromisi: mungesa e gjendjes dhe ekspozimi i shkurtër (access) kundrejt seancave të gjata dhe mundësisë së revokimit (refresh). Ta bësh gabim — një access token jetëgjatë, pa rotacion, refresh i ruajtur në `localStorage` — e kthen një token të vetëm të rrjedhur në një kompromentim afatgjatë të llogarisë. Të emërtosh ndarjen dhe çfarë të jep secili token është ajo që pritet të dijë një inxhinier i vetëdijshëm për sigurinë.

	Një access token jetëgjatë	Access + refresh
Ekspozimi	Dërgohet në çdo kërkesë, jeton gjatë → dritare e madhe vjedhjeje	Access jetëshkurtër; refresh dërgohet rrallë
Revokimi	I vështirë (një JWT stateless nuk mund të ç'lëshohet)	Revoko refresh token-in; access-i vdes brenda minutash
UX	Rihyrje e shpeshtë nëse është i shkurtër	Mbetesh i loguar pa rifutur kredencialet
Rrezja e shpërthimit të rrjedhjes	E madhe	E vogël (access-i skadon shpejt)

Dy rolet

Pse jo vetëm një token?

Çfarë mundëson ndarja

Pse ka rëndësi

Pyetje të ngjashme