आपको access token और refresh token दोनों की ज़रूरत क्यों होती है?

Question

IT Interview Practice · Accepted Answer

दो tokens एक सीधे टकराव को हल करने के लिए मौजूद हैं: एक access token को **हर request पर भेजा जाना** चाहिए (इसलिए यह बहुत exposed होता है), फिर भी आप ऐसे sessions भी चाहते हैं जो बार-बार logins को मजबूर किए बिना **लंबे समय तक चलें**। आप एक ही 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 नहीं** → सुरक्षित, पर उपयोगकर्ता हर कुछ मिनटों में 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 इंजीनियर से अपेक्षित है।

	एक 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 क्यों नहीं?

यह विभाजन क्या सक्षम करता है

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

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