JSON Web Token (JWT) कसे कार्य करते?

Question

IT Interview Practice · Accepted Answer

**JSON Web Token (JWT)** हा एक compact, URL-safe, self-contained token आहे जो वापरकर्त्याबद्दल claims वाहून नेतो. Server तो एकदा sign करतो; त्यानंतर तो प्रत्येक request वर database lookup शिवाय token **verify** करू शकतो — हेच JWT-आधारित auth ला *stateless* बनवते.

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

JWT म्हणजे `header.payload.signature`, ठिपक्यांनी जोडलेले तीन base64url-encoded segments:

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

- **Header** — signing algorithm, उदा. `{ "alg": "HS256", "typ": "JWT" }`.
- **Payload** — **claims**: standard जसे `sub` (subject/user id), `exp` (expiry), `iat` (issued-at), `iss` (issuer), तसेच कोणतेही custom fields (`role`, `email`).
- **Signature** — secret किंवा private key ने header आणि payload वर गणना केलेली.

> Payload **encoded आहे, encrypted नाही**. कोणीही base64-decode करून ती वाचू शकतो, म्हणून JWT मध्ये कधीही passwords किंवा 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 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); // छेडछाड किंवा expire झाल्यास error टाकते
  // claims.sub === "123"
} catch (e) {
  // नाकारा: अवैध किंवा expired
}
```

## कठीण भाग: revocation

Verification stateless असल्यामुळे, तुम्ही server-side फक्त "delete" करून token expire होण्यापूर्वी तो **invalidate करू शकत नाही**. सामान्य उपाय:

- Access tokens **short-lived** (5–15 मिनिटे) ठेवा आणि त्यांना दीर्घ-आयुष्याच्या **refresh token** शी जोडा.
- logout/compromise साठी revoked 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 वर विश्वास ठेवू शकते, कोणत्याही shared session store शिवाय. पण तीच statelessness हा classic interview सापळा आहे: tokens सहज revoke करता येत नाहीत, payload वाचता येते, आणि `alg` गोंधळ किंवा हरवलेली expiry तपासणी हे खरे vulnerabilities आहेत. signature नेमके काय संरक्षित करते आणि काय नाही हे माहीत असणे JWTs सुरक्षितपणे वापरण्यासाठी आवश्यक आहे.

Storage	फायदा	तोटा
`httpOnly` cookie	JS ने वाचता येत नाही (XSS-safer)	CSRF संरक्षण आवश्यक
`localStorage`	साधे, CSRF नाही	XSS ला उघडे

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

Signing आणि verification कसे कार्य करते

कठीण भाग: revocation

Storage trade-offs

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

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