तुम्हाला 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 expired ──▶ 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 का नाही?

विभागणीमुळे काय शक्य होते

हे का महत्त्वाचे आहे

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