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 बनाता है — इसलिए उपयोगकर्ता 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** — उपयोगकर्ता एक बार authenticate करता है; server एक **access token** (short TTL) और एक **refresh token** (long TTL) लौटाता है।
2. **APIs को 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 को दोबारा प्रयास करता है। उपयोगकर्ता को कुछ पता नहीं चलता।
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 का मतलब है दीर्घकालिक account takeover।

प्रवाह (flow)

Refresh token rotation

Storage

यह क्यों महत्वपूर्ण है

संबंधित प्रश्न