Access tokens અને refresh tokens સાથે મળીને કેવી રીતે કામ કરે છે?

Question

IT Interview Practice · Accepted Answer

બે tokens એક સરળ lifecycle ને અનુસરે છે: એક **short-lived access token** દરેક API call ને authorize કરે છે, અને એક **long-lived refresh token** તેઓ expire થાય ત્યારે ચૂપચાપ નવા access tokens બનાવે છે — તેથી user credentials ફરી નાખ્યા વગર logged in રહે છે.

## પ્રવાહ (flow)

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. API call: Authorization: Bearer <access>
     ▼
┌────────────┐  verify signature + exp   (no DB lookup)
│ Resource   │ ──── 200 OK ────▶ (access still valid)
│ API        │ ──── 401 ───────▶ (access expired)
└────────────┘
     │  3. on 401: POST /token { refresh }
     ▼
┌────────────┐  verify + rotate
│ Auth server│ ──── new access (+ new refresh) ────▶ retry the call
└────────────┘
```

1. **Login** — user એક વાર authenticate થાય છે; server એક **access token** (short TTL) અને એક **refresh token** (long TTL) પરત આપે છે.
2. **API ને access કરો** — client દરેક request પર `Authorization: Bearer …` માં access token મોકલે છે. API તેને statelessly (signature + `exp`) verify કરે અને જવાબ આપે છે — કોઈ session store જરૂરી નથી.
3. **Expiry પર refresh** — જ્યારે API `401` પરત આપે છે (અથવા client જુએ છે કે `exp` નજીક છે), ત્યારે client **refresh token** ને auth server ના `/token` endpoint પર POST કરે અને એક તાજું access token મેળવે છે, પછી મૂળ request ફરી પ્રયાસ કરે છે. User ને કંઈ ખબર પડતી નથી.
4. **Logout / revoke** — server refresh token ને delete કરે અથવા denylist કરે છે; આગલું refresh નિષ્ફળ થાય અને session સમાપ્ત થાય (વર્તમાન access token હજુ પણ થોડી મિનિટોમાં જાતે મરી જાય).

```js
// Client interceptor: 401 પર એક વાર refresh કરો, પછી retry કરો.
async function apiFetch(url, opts = {}) {
  let res = await fetch(url, withAuth(opts, accessToken));
  if (res.status === 401) {
    accessToken = await refreshAccessToken(refreshToken); // POST /token
    res = await fetch(url, withAuth(opts, accessToken));   // retry
  }
  return res;
}
```

## Refresh token rotation

શ્રેષ્ઠ પ્રથા છે **rotation**: દરેક refresh call એક *નવું* refresh token પરત આપે અને જૂનાને invalidate કરે છે. જો કોઈ જૂનું (પહેલેથી વપરાયેલું) refresh token ફરી રજૂ થાય, તો તે ચોરીનો સંકેત આપે છે — server આખા token family ને revoke કરે અને re-login કરાવે છે. આ ચોરાયેલા refresh token નું નુકસાન મર્યાદિત કરે છે.

## Storage

- **Refresh token** → `httpOnly`, `Secure`, `SameSite` cookie જેથી JavaScript (અને તેથી XSS) તેને વાંચી ન શકે.
- **Access token** → client પર memory માં રખાય; ટૂંકું જીવન exposure મર્યાદિત કરે છે.
- જો ટાળી શકો તો બંનેમાંથી કોઈને `localStorage` માં ક્યારેય ન મૂકો — તે કોઈપણ injected script દ્વારા વાંચી શકાય છે.

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

આ flow આધુનિક SPAs, mobile apps, અને APIs માં session management ની કરોડરજ્જુ છે, તેથી ઇન્ટરવ્યુઅર્સ અપેક્ષા રાખે છે કે તમે તેને end to end ટ્રેસ કરો: login પર બંને issue કરો, access token થી authorize કરો, expiry પર transparently refresh કરો, અને સલામતી માટે rotate + revoke કરો. વિગતો સાચી કરવી — stateless verification, refresh માત્ર token endpoint પર, reuse detection સાથે rotation, અને `httpOnly` storage — એ સરળ, સુરક્ષિત session અને એવા session વચ્ચેનો તફાવત છે જ્યાં એક જ ચોરાયેલા token નો અર્થ છે long-lived account takeover.

પ્રવાહ (flow)

Refresh token rotation

Storage

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

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