JSON Web Token (JWT) کیسے کام کرتا ہے؟

Question

IT Interview Practice · Accepted Answer

ایک **JSON Web Token (JWT)** ایک مختصر، URL-safe، خود کفیل token ہے جو کسی صارف کے بارے میں claims اٹھاتا ہے۔ Server اسے ایک بار sign کرتا ہے؛ اس کے بعد وہ ہر request پر ڈیٹابیس lookup کے بغیر token کو **verify** کر سکتا ہے — یہی چیز JWT پر مبنی auth کو *stateless* بناتی ہے۔

## ساخت: تین base64url حصے

ایک JWT `header.payload.signature` ہے، تین base64url-encoded حصے جو نقطوں سے جڑے ہوتے ہیں:

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   ← header
.eyJzdWIiOiIxMjMiLCJleHAiOjE3MDB9      ← payload (claims)
.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1    ← signature
```

- **Header** — signing algorithm، مثلاً `{ "alg": "HS256", "typ": "JWT" }`۔
- **Payload** — **claims**: معیاری جیسے `sub` (subject/user id)، `exp` (expiry)، `iat` (issued-at)، `iss` (issuer)، اور کوئی بھی custom fields (`role`، `email`)۔
- **Signature** — کسی secret یا private key کے ساتھ header اور payload پر حساب کی جاتی ہے۔

> Payload **encode کیا گیا ہے، encrypt نہیں**۔ کوئی بھی اسے base64-decode کر کے پڑھ سکتا ہے، لہٰذا کبھی passwords یا secrets کو JWT میں نہ ڈالیں۔

## Signing اور verification کیسے کام کرتے ہیں

```
signature = HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)
```

- **HS256** (symmetric): وہی secret sign اور verify کرتا ہے۔ سادہ، لیکن ہر verifier کو secret رکھنا پڑتا ہے۔
- **RS256** (asymmetric): ایک **private key** sign کرتی ہے، ایک **public key** verify کرتی ہے۔ auth server private key رکھتا ہے؛ دیگر services public key سے verify کرتی ہیں اور کبھی tokens نہیں بنا سکتیں۔

ہر request پر server موصول ہونے والے header+payload پر signature دوبارہ حساب کرتا ہے اور اس کا موازنہ کرتا ہے۔ اگر وہ میل کھائیں اور `exp` مستقبل میں ہو، تو token پر بھروسہ کیا جاتا ہے — کسی session store کی ضرورت نہیں۔

```js
const jwt = require("jsonwebtoken");

const token = jwt.sign({ sub: "123", role: "admin" }, SECRET, {
  expiresIn: "15m",
});

try {
  const claims = jwt.verify(token, SECRET); // چھیڑ چھاڑ یا expired ہونے پر throw کرتا ہے
  // claims.sub === "123"
} catch (e) {
  // مسترد کریں: غلط یا expired
}
```

## مشکل حصہ: منسوخی (revocation)

چونکہ verification stateless ہے، آپ کسی token کو expire ہونے سے پہلے صرف server-side پر "delete" کر کے غیر مؤثر **نہیں** کر سکتے۔ عام تخفیفات:

- access tokens کو **مختصر مدت** (5–15 منٹ) رکھیں اور انہیں ایک زیادہ دیرپا **refresh token** کے ساتھ جوڑیں۔
- logout/compromise کے لیے منسوخ شدہ token ids (`jti`) کی ایک چھوٹی **denylist** برقرار رکھیں — یہ تھوڑا سا state واپس لاتا ہے۔
- signing keys کو rotate کریں۔

## storage کے trade-offs

| Storage | فائدہ | نقصان |
|---|---|---|
| `httpOnly` cookie | JS سے نہیں پڑھی جا سکتی (XSS-safer) | CSRF تحفظ درکار |
| `localStorage` | سادہ، کوئی CSRF نہیں | XSS کے سامنے کھلی |

## یہ کیوں اہم ہے

JWTs APIs، microservices، اور SPAs میں stateless authentication کو طاقت دیتے ہیں — ایک service صرف ایک signature verify کر کے کسی request پر بھروسہ کر سکتی ہے، بغیر کسی مشترکہ session store کے۔ لیکن وہی statelessness کلاسک انٹرویو پھندا ہے: tokens آسانی سے منسوخ نہیں کیے جا سکتے، payload پڑھی جا سکتی ہے، اور `alg` کی الجھن یا غائب expiry جانچ حقیقی کمزوریاں ہیں۔ یہ ٹھیک ٹھیک جاننا کہ signature کیا محفوظ کرتی ہے، اور کیا نہیں، JWTs کو محفوظ طریقے سے استعمال کرنے کے لیے ضروری ہے۔

Storage	فائدہ	نقصان
`httpOnly` cookie	JS سے نہیں پڑھی جا سکتی (XSS-safer)	CSRF تحفظ درکار
`localStorage`	سادہ، کوئی CSRF نہیں	XSS کے سامنے کھلی

ساخت: تین base64url حصے

Signing اور verification کیسے کام کرتے ہیں

مشکل حصہ: منسوخی (revocation)

storage کے trade-offs

یہ کیوں اہم ہے

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