మీకు access token మరియు refresh token రెండూ ఎందుకు అవసరం?

Question

IT Interview Practice · Accepted Answer

ఈ రెండు tokens ఒక ప్రత్యక్ష వైరుధ్యాన్ని పరిష్కరించడానికి ఉన్నాయి: ఒక access token **ప్రతి request‌పై పంపబడాలి** (కాబట్టి ఇది చాలా బహిర్గతమవుతుంది), అయినప్పటికీ తరచుగా logins‌ను బలవంతం చేయకుండా **ఎక్కువ కాలం ఉండే** sessions‌ను కూడా మీరు కోరుకుంటారు. రెండింటినీ ఒకే token‌లో సురక్షితంగా కలిగి ఉండలేరు — కాబట్టి మీరు పనిని విభజిస్తారు.

## రెండు పాత్రలు

- **Access token** — స్వల్పకాలిక (సాధారణంగా 5–15 నిమిషాలు), ప్రతి API కాల్‌పై `Authorization` header‌లో పంపబడుతుంది. ఇది నిరంతరం ప్రసారం చేయబడుతుంది కాబట్టి, లీక్ అయ్యే అవకాశం ఉంది; దాన్ని స్వల్పంగా ఉంచడం అంటే దొంగిలించబడినది దాదాపు వెంటనే గడువు ముగుస్తుంది.
- **Refresh token** — దీర్ఘకాలిక (రోజులు/వారాలు), కొత్త access tokens‌ను పొందడానికి auth server యొక్క token endpoint‌కు **మాత్రమే** పంపబడుతుంది. ఇది అరుదుగా ప్రయాణిస్తుంది, మరింత సురక్షితంగా నిల్వ చేయవచ్చు, మరియు server-side‌లో రద్దు చేయవచ్చు.

```
Login ──▶ access (15m) + refresh (30d)
ప్రతి API కాల్ ──▶ access పంపు
Access గడువు ముగిసింది ──▶ refresh పంపు ──▶ కొత్త access (+ రొటేట్ చేయబడిన refresh)
```

## ఒకే token ఎందుకు కాదు?

| | ఒక దీర్ఘకాలిక access token | Access + refresh |
|---|---|---|
| బహిర్గతం | ప్రతి request‌పై పంపబడుతుంది, ఎక్కువ కాలం జీవిస్తుంది → పెద్ద దొంగతనం విండో | Access స్వల్పకాలిక; refresh అరుదుగా పంపబడుతుంది |
| రద్దు | కష్టం (stateless JWT‌ను జారీ-రద్దు చేయలేము) | refresh token‌ను రద్దు చేయండి; access నిమిషాల్లో చనిపోతుంది |
| UX | స్వల్పంగా ఉంటే తరచుగా మళ్లీ login | credentials‌ను మళ్లీ నమోదు చేయకుండా login‌లో ఉంటుంది |
| లీక్ యొక్క నష్ట పరిధి | పెద్దది | చిన్నది (access త్వరగా గడువు ముగుస్తుంది) |

- **ఒక స్వల్ప access token, refresh లేదు** → సురక్షితం, కానీ వినియోగదారు ప్రతి కొన్ని నిమిషాలకు logout అవుతారు. భయంకరమైన UX.
- **ఒక దీర్ఘ access token** → గొప్ప UX, కానీ లీక్ అయిన token ఎక్కువ కాలం చెల్లుబాటు అవుతుంది మరియు సులభంగా రద్దు చేయలేము.
- **Access + refresh** → స్వల్ప బహిర్గత విండో *మరియు* దీర్ఘ sessions. Refresh token అనేది ఏకైక దీర్ఘకాలిక రహస్యం, మరియు అది ఒక సురక్షితమైన స్థలంలో ఉంటుంది.

## విభజన దేన్ని సాధ్యం చేస్తుంది

- **Stateless access tokens ఉన్నప్పటికీ రద్దు.** గడువు ముగియకముందు ఒక JWT access token‌ను చెల్లనిదిగా చేయలేరు, కానీ refresh token‌ను *తొలగించవచ్చు/నిరాకరించవచ్చు*, కాబట్టి session తదుపరి refresh వద్ద (నిమిషాల్లో) ముగుస్తుంది.
- **Refresh token rotation** — ప్రతి ఉపయోగంలో కొత్త refresh token‌ను జారీ చేసి, పాతదాని పునర్వినియోగాన్ని (దొంగతనం సంకేతం) గుర్తించి, ఆపై మొత్తం చైన్‌ను రద్దు చేయండి.
- **అతి తక్కువ బహిర్గతం** — దీర్ఘకాలిక రహస్యం (refresh) ఖచ్చితంగా ఒకే endpoint‌కు పంపబడుతుంది, ఆదర్శంగా XSS అందుబాటుకు దూరంగా ఒక `httpOnly` cookie‌లో నిల్వ చేయబడుతుంది.

## ఇది ఎందుకు ముఖ్యం

ఇది ఆధునిక ప్రామాణిక auth డిజైన్, మరియు మీరు *ఎలా* అని మాత్రమే కాకుండా *ఎందుకు* అని అర్థం చేసుకుంటారా అని చూడటానికి interviewers దీన్ని అడుగుతారు. కీలక అంతర్దృష్టి trade-off: statelessness మరియు స్వల్ప బహిర్గతం (access) వర్సెస్ దీర్ఘ sessions మరియు రద్దు చేయగల సామర్థ్యం (refresh). తప్పు చేయడం — దీర్ఘకాలిక access token, rotation లేకపోవడం, `localStorage`‌లో నిల్వ చేయబడిన refresh — ఒక లీక్ అయిన token‌ను దీర్ఘకాలిక account రాజీగా మారుస్తుంది. విభజనను మరియు ప్రతి token మీకు ఏమి ఇస్తుందో పేర్కొనడం అనేది భద్రతా-అవగాహన ఉన్న engineer తెలుసుకోవాలని ఆశించబడేది.

	ఒక దీర్ఘకాలిక access token	Access + refresh
బహిర్గతం	ప్రతి request‌పై పంపబడుతుంది, ఎక్కువ కాలం జీవిస్తుంది → పెద్ద దొంగతనం విండో	Access స్వల్పకాలిక; refresh అరుదుగా పంపబడుతుంది
రద్దు	కష్టం (stateless JWT‌ను జారీ-రద్దు చేయలేము)	refresh token‌ను రద్దు చేయండి; access నిమిషాల్లో చనిపోతుంది
UX	స్వల్పంగా ఉంటే తరచుగా మళ్లీ login	credentials‌ను మళ్లీ నమోదు చేయకుండా login‌లో ఉంటుంది
లీక్ యొక్క నష్ట పరిధి	పెద్దది	చిన్నది (access త్వరగా గడువు ముగుస్తుంది)

రెండు పాత్రలు

ఒకే token ఎందుకు కాదు?

విభజన దేన్ని సాధ్యం చేస్తుంది

ఇది ఎందుకు ముఖ్యం

సంబంధిత ప్రశ్నలు