तपाईंलाई access token र refresh token दुवै किन चाहिन्छ?

Question

IT Interview Practice · Accepted Answer

दुई tokens एउटा प्रत्यक्ष द्वन्द्व समाधान गर्न अस्तित्वमा छन्: access token **हरेक request मा पठाइनुपर्छ** (त्यसैले यो धेरै exposed हुन्छ), तर तपाईं पटक-पटक login नगराई **लामो समय टिक्ने** sessions पनि चाहनुहुन्छ। एउटै token मा सुरक्षित रूपमा दुवै हुन सक्दैन — त्यसैले तपाईं काम बाँड्नुहुन्छ।

## दुई भूमिका

- **Access token** — छोटो अवधिको (सामान्यतया 5–15 मिनेट), हरेक API call मा `Authorization` header मा पठाइन्छ। निरन्तर प्रसारित हुने भएकाले leak हुने सम्भावना उच्च; यसलाई छोटो राख्नुको अर्थ चोरिएको लगभग तुरुन्तै expire हुन्छ।
- **Refresh token** — लामो अवधिको (दिन/हप्ता), नयाँ access tokens प्राप्त गर्न **केवल** auth server को token endpoint मा पठाइन्छ। यो विरलै यात्रा गर्छ, अझ सुरक्षित रूपमा भण्डारण गर्न सकिन्छ, र server-side revoke गर्न सकिन्छ।

```
Login ──▶ access (15m) + refresh (30d)
हरेक API call ──▶ access पठाउनुहोस्
Access सकियो ──▶ refresh पठाउनुहोस् ──▶ नयाँ access (+ rotated refresh)
```

## किन एउटै token मात्र होइन?

| | एउटा लामो अवधिको access token | Access + refresh |
|---|---|---|
| Exposure | हरेक request मा पठाइन्छ, लामो बाँच्छ → ठूलो चोरीको झ्याल | Access छोटो अवधिको; 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 लामो समयसम्म वैध रहन्छ र सजिलै revoke गर्न सकिँदैन।
- **Access + refresh** → छोटो exposure window *र* लामो sessions। Refresh token एक मात्र लामो अवधिको secret हो, र यो एउटा सुरक्षित ठाउँमा बस्छ।

## यो विभाजनले के सम्भव बनाउँछ

- **Stateless access tokens भए पनि revocation।** तपाईं JWT access token expire हुनुअघि invalidate गर्न सक्नुहुन्न, तर refresh token तपाईं *delete/deny गर्न सक्नुहुन्छ*, त्यसैले session अर्को refresh मा समाप्त हुन्छ (केही मिनेटमा)।
- **Refresh token rotation** — हरेक प्रयोगमा नयाँ refresh token issue गर्नुहोस् र पुरानोको reuse पत्ता लगाउनुहोस् (चोरीको संकेत), त्यसपछि सम्पूर्ण chain revoke गर्नुहोस्।
- **न्यूनतम exposure** — लामो अवधिको secret (refresh) ठ्याक्कै एउटा endpoint मा पठाइन्छ, आदर्श रूपमा `httpOnly` cookie मा भण्डारण गरिन्छ, XSS को पहुँचभन्दा बाहिर।

## यो किन महत्त्वपूर्ण छ

यो मानक आधुनिक auth design हो, र अन्तर्वार्ताकारहरूले यो सोध्छन् कि तपाईंले *कसरी* मात्र होइन, *किन* बुझ्नुहुन्छ कि। मुख्य अन्तर्दृष्टि भनेको trade-off हो: statelessness र छोटो exposure (access) विरुद्ध लामो sessions र revocability (refresh)। गलत गर्दा — लामो अवधिको access token, rotation छैन, refresh `localStorage` मा भण्डारण — एउटा leak भएको token लामो अवधिको account compromise मा बदलिन्छ। विभाजन र प्रत्येक token ले के दिन्छ भन्ने नाम लिनु नै एउटा security-aware engineer बाट अपेक्षित कुरा हो।

	एउटा लामो अवधिको access token	Access + refresh
Exposure	हरेक request मा पठाइन्छ, लामो बाँच्छ → ठूलो चोरीको झ्याल	Access छोटो अवधिको; refresh विरलै पठाइन्छ
Revocation	गाह्रो (stateless JWT un-issue गर्न सकिँदैन)	refresh token revoke गर्नुहोस्; access केही मिनेटमा मर्छ
UX	छोटो भए पटक-पटक re-login	credentials फेरि नहाली logged in रहन्छ
Leak को blast radius	ठूलो	सानो (access छिटो expire हुन्छ)

दुई भूमिका

किन एउटै token मात्र होइन?

यो विभाजनले के सम्भव बनाउँछ

यो किन महत्त्वपूर्ण छ

सम्बन्धित प्रश्नहरू