તમને access token અને refresh token બંનેની જરૂર કેમ પડે છે?

Question

IT Interview Practice · Accepted Answer

બે tokens એક સીધા વિરોધાભાસને ઉકેલવા માટે અસ્તિત્વમાં છે: access token **દરેક request પર મોકલવું** પડે છે (તેથી તે ખૂબ exposed થાય છે), છતાં તમે એવા sessions પણ ઇચ્છો છો જે વારંવાર login કરાવ્યા વગર **લાંબો સમય ટકે**. તમે એક જ token માં બંને સુરક્ષિત રીતે મેળવી શકતા નથી — તેથી તમે કામ વહેંચો છો.

## બે ભૂમિકાઓ

- **Access token** — short-lived (સામાન્ય રીતે 5–15 મિનિટ), દરેક API call પર `Authorization` header માં મોકલાય છે. કારણ કે તે સતત પ્રસારિત થાય છે, leak થવાની શક્યતા વધુ છે; તેને ટૂંકું રાખવાનો અર્થ એ કે ચોરાયેલું લગભગ તરત જ expire થાય છે.
- **Refresh token** — long-lived (દિવસો/અઠવાડિયા), નવા access tokens મેળવવા માટે **માત્ર** auth server ના token endpoint પર જ મોકલાય છે. તે ભાગ્યે જ મુસાફરી કરે છે, વધુ સુરક્ષિત રીતે store થઈ શકે છે, અને server-side revoke થઈ શકે છે.

```
Login ──▶ access (15m) + refresh (30d)
Every API call ──▶ send access
Access expired ──▶ send refresh ──▶ new access (+ rotated refresh)
```

## માત્ર એક token કેમ નહીં?

| | એક long-lived access token | Access + refresh |
|---|---|---|
| Exposure | દરેક request પર મોકલાય, લાંબુ જીવે → મોટી ચોરી window | Access short-lived; refresh ભાગ્યે જ મોકલાય |
| Revocation | અઘરું (stateless JWT ને un-issue કરી શકાતું નથી) | refresh token revoke કરો; access મિનિટોમાં મરી જાય |
| UX | ટૂંકું હોય તો વારંવાર re-login | credentials ફરી નાખ્યા વગર logged in રહે |
| leak ની blast radius | મોટી | નાની (access ઝડપથી expire થાય) |

- **એક ટૂંકું access token, refresh નહીં** → સુરક્ષિત, પણ user દર થોડી મિનિટે logout થાય. ખરાબ UX.
- **એક લાંબુ access token** → સરસ UX, પણ leak થયેલું token લાંબા સમય માટે valid રહે અને સહેલાઈથી revoke થઈ શકતું નથી.
- **Access + refresh** → ટૂંકી exposure window *અને* લાંબા sessions. Refresh token એ એકમાત્ર long-lived secret છે, અને તે એક સુરક્ષિત જગ્યાએ રહે છે.

## આ વિભાજન શું શક્ય બનાવે છે

- **Stateless access tokens છતાં revocation.** તમે JWT access token ને expire થાય તે પહેલાં invalidate કરી શકતા નથી, પણ તમે refresh token ને *delete/deny કરી શકો છો*, તેથી session આગલા refresh પર સમાપ્ત થાય છે (મિનિટોમાં).
- **Refresh token rotation** — દરેક ઉપયોગ પર નવું refresh token આપો અને જૂનાના reuse ને (ચોરીની નિશાની) શોધો, પછી આખી chain revoke કરો.
- **ન્યૂનતમ exposure** — long-lived secret (refresh) બરાબર એક endpoint પર જ મોકલાય છે, આદર્શ રીતે `httpOnly` cookie માં store થાય છે, XSS ની પહોંચ બહાર.

## આ શા માટે મહત્વનું છે

આ પ્રમાણભૂત આધુનિક auth design છે, અને ઇન્ટરવ્યુઅર્સ તે પૂછે છે એ જોવા માટે કે તમે *કેમ* સમજો છો, માત્ર *કેવી રીતે* નહીં. મુખ્ય સૂઝ એ trade-off છે: statelessness અને ટૂંકી exposure (access) વિરુદ્ધ લાંબા sessions અને revocability (refresh). ખોટું કરવું — long-lived access token, rotation નહીં, refresh `localStorage` માં store — એક leak થયેલા token ને લાંબા ગાળાના account compromise માં ફેરવે છે. વિભાજનનું નામ આપવું અને દરેક token તમને શું આપે છે તે જ છે જે security-aware engineer પાસેથી અપેક્ષિત છે.

	એક long-lived access token	Access + refresh
Exposure	દરેક request પર મોકલાય, લાંબુ જીવે → મોટી ચોરી window	Access short-lived; refresh ભાગ્યે જ મોકલાય
Revocation	અઘરું (stateless JWT ને un-issue કરી શકાતું નથી)	refresh token revoke કરો; access મિનિટોમાં મરી જાય
UX	ટૂંકું હોય તો વારંવાર re-login	credentials ફરી નાખ્યા વગર logged in રહે
leak ની blast radius	મોટી	નાની (access ઝડપથી expire થાય)

બે ભૂમિકાઓ

માત્ર એક token કેમ નહીં?

આ વિભાજન શું શક્ય બનાવે છે

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો