JSON Web Token (JWT) कैसे काम करता है?

Question

IT Interview Practice · Accepted Answer

एक **JSON Web Token (JWT)** एक कॉम्पैक्ट, URL-सुरक्षित, स्व-निहित token है जो किसी उपयोगकर्ता के बारे में claims वहन करता है। सर्वर इसे एक बार sign करता है; उसके बाद यह हर request पर database lookup के बिना token को **verify** कर सकता है — यही JWT-आधारित auth को *stateless* बनाता है।

## संरचना: तीन base64url भाग

एक JWT `header.payload.signature` है, बिंदुओं से जुड़े तीन base64url-एन्कोडेड segments:

```
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 फ़ील्ड (`role`, `email`)।
- **Signature** — किसी secret या private key के साथ header और payload पर गणना की जाती है।

> Payload **एन्कोडेड है, एन्क्रिप्टेड नहीं**। कोई भी इसे base64-decode करके पढ़ सकता है, इसलिए JWT में कभी भी पासवर्ड या secrets न डालें।

## 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 सर्वर private key रखता है; अन्य सेवाएँ public key से verify करती हैं और कभी token नहीं बना सकतीं।

हर request पर सर्वर प्राप्त 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); // छेड़छाड़ या expire होने पर throw करता है
  // claims.sub === "123"
} catch (e) {
  // अस्वीकार करें: अमान्य या expired
}
```

## कठिन हिस्सा: revocation

क्योंकि verification stateless है, आप किसी token को उसके expire होने से पहले केवल सर्वर-साइड पर "delete" करके **अमान्य नहीं कर सकते**। सामान्य उपाय:

- Access tokens को **अल्पकालिक** (5–15 मिनट) रखें और उन्हें एक लंबे-जीवी **refresh token** के साथ जोड़ें।
- Logout/compromise के लिए revoke किए गए token ids (`jti`) की एक छोटी **denylist** बनाए रखें — यह थोड़ा state वापस लाता है।
- Signing keys को rotate करें।

## Storage trade-offs

| Storage | फ़ायदा | नुकसान |
|---|---|---|
| `httpOnly` cookie | JS द्वारा पढ़ने योग्य नहीं (XSS-सुरक्षित) | CSRF सुरक्षा चाहिए |
| `localStorage` | सरल, कोई CSRF नहीं | XSS के प्रति उजागर |

## यह क्यों महत्वपूर्ण है

JWTs APIs, microservices, और SPAs में stateless authentication को शक्ति देते हैं — एक सेवा केवल signature verify करके किसी request पर भरोसा कर सकती है, बिना किसी साझा session store के। लेकिन वही statelessness क्लासिक इंटरव्यू जाल है: tokens आसानी से revoke नहीं किए जा सकते, payload पढ़ा जा सकता है, और `alg` भ्रम या expiry check का न होना वास्तविक vulnerabilities हैं। यह ठीक-ठीक जानना कि signature क्या सुरक्षित करता है और क्या नहीं, JWTs का सुरक्षित उपयोग करने के लिए आवश्यक है।

Storage	फ़ायदा	नुकसान
`httpOnly` cookie	JS द्वारा पढ़ने योग्य नहीं (XSS-सुरक्षित)	CSRF सुरक्षा चाहिए
`localStorage`	सरल, कोई CSRF नहीं	XSS के प्रति उजागर

संरचना: तीन base64url भाग

Signing और verification कैसे काम करते हैं

कठिन हिस्सा: revocation

Storage trade-offs

यह क्यों महत्वपूर्ण है

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