آپ کو access token اور refresh token دونوں کی ضرورت کیوں ہوتی ہے؟

Question

IT Interview Practice · Accepted Answer

یہ دونوں tokens ایک براہِ راست تضاد کو حل کرنے کے لیے موجود ہیں: access token کو **ہر request پر بھیجنا** پڑتا ہے (اس لیے یہ بہت زیادہ ظاہر ہوتا ہے)، پھر بھی آپ ایسے sessions بھی چاہتے ہیں جو بار بار logins پر مجبور کیے بغیر **لمبے عرصے تک چلیں**۔ آپ دونوں کو ایک ہی token میں محفوظ طریقے سے نہیں رکھ سکتے — اس لیے آپ کام کو تقسیم کر دیتے ہیں۔

## دو کردار

- **Access token** — مختصر مدت (عموماً 5–15 منٹ)، ہر API کال پر `Authorization` header میں بھیجا جاتا ہے۔ چونکہ یہ مسلسل منتقل ہوتا ہے، اس کا leak ہونا ممکن ہے؛ اسے مختصر رکھنے کا مطلب یہ ہے کہ چوری شدہ token تقریباً فوراً ختم ہو جاتا ہے۔
- **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 رہتا ہے |
| leak کے نقصان کا دائرہ | بڑا | چھوٹا (access جلد ختم ہو جاتا ہے) |

- **ایک مختصر access token، کوئی refresh نہیں** → محفوظ، لیکن صارف ہر چند منٹ بعد logout ہو جاتا ہے۔ بھیانک UX۔
- **ایک طویل access token** → بہترین UX، لیکن leak ہوا 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 ڈیزائن ہے، اور انٹرویو لینے والے یہ دیکھنے کے لیے پوچھتے ہیں کہ آیا آپ *کیوں* کو سمجھتے ہیں، نہ صرف *کیسے* کو۔ کلیدی بصیرت trade-off ہے: statelessness اور مختصر ظاہر ہونا (access) بمقابلہ لمبے sessions اور منسوخ کیے جانے کی صلاحیت (refresh)۔ غلط کرنا — ایک طویل مدت access token، کوئی rotation نہیں، refresh کو `localStorage` میں محفوظ کرنا — ایک leak ہوئے token کو ایک طویل مدت اکاؤنٹ سمجھوتے میں بدل دیتا ہے۔ تقسیم کا نام لینا اور یہ کہ ہر token آپ کو کیا دیتا ہے، وہی ہے جو سیکیورٹی سے باخبر engineer سے جاننے کی توقع کی جاتی ہے۔

	ایک طویل مدت access token	Access + refresh
ظاہر ہونا	ہر request پر بھیجا جاتا ہے، لمبا جیتا ہے → بڑی چوری کی کھڑکی	Access مختصر مدت؛ refresh کم بھیجا جاتا ہے
منسوخی	مشکل (stateless JWT کو غیر جاری نہیں کیا جا سکتا)	refresh token منسوخ کریں؛ access منٹوں میں مر جاتا ہے
UX	مختصر ہو تو بار بار دوبارہ login	credentials دوبارہ ڈالے بغیر login رہتا ہے
leak کے نقصان کا دائرہ	بڑا	چھوٹا (access جلد ختم ہو جاتا ہے)

دو کردار

صرف ایک token کیوں نہیں؟

یہ تقسیم کیا ممکن بناتی ہے

یہ کیوں اہم ہے

متعلقہ سوالات