JSON Web Token (JWT) ఎలా పనిచేస్తుంది?

Question

IT Interview Practice · Accepted Answer

ఒక **JSON Web Token (JWT)** అనేది ఒక వినియోగదారు గురించి claims ను మోసుకెళ్లే ఒక కాంపాక్ట్, URL-safe, స్వయం-నిండిన token. Server దానిని ఒకసారి sign చేస్తుంది; ఆ తర్వాత database lookup లేకుండా ప్రతి request పై దానిని **verify** చేయగలదు — అదే JWT-based 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); // tampered లేదా expired అయితే throw చేస్తుంది
  // claims.sub === "123"
} catch (e) {
  // తిరస్కరించు: చెల్లనిది లేదా గడువు ముగిసింది
}
```

## కష్టమైన భాగం: revocation

verification stateless కాబట్టి, server-side లో దానిని కేవలం "delete" చేయడం ద్వారా ఒక token గడువు ముగియక ముందు దానిని చెల్లనిదిగా చేయడం మీకు **సాధ్యం కాదు**. సాధారణ ఉపశమనాలు:

- access tokens ను **స్వల్పకాలిక** (5–15 నిమిషాలు) గా ఉంచి, వాటిని ఎక్కువ కాలం ఉండే **refresh token** తో జతచేయండి.
- logout/compromise కోసం revoke చేయబడిన token ids (`jti`) కలిగిన ఒక చిన్న **denylist** ను నిర్వహించండి — ఇది కొంత state ను తిరిగి ప్రవేశపెడుతుంది.
- signing keys ను rotate చేయండి.

## నిల్వ trade-offs

| నిల్వ | లాభం | నష్టం |
|---|---|---|
| `httpOnly` cookie | JS చేత చదవబడదు (XSS-safer) | CSRF రక్షణ అవసరం |
| `localStorage` | సరళం, CSRF లేదు | XSS కు బహిర్గతం |

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

JWTs APIs, microservices, మరియు SPAs అంతటా stateless authentication ను శక్తివంతం చేస్తాయి — ఒక service ఒక signature ను మాత్రమే verify చేయడం ద్వారా ఒక request ను నమ్మగలదు, భాగస్వామ్య session store లేకుండా. కానీ అదే statelessness క్లాసిక్ ఇంటర్వ్యూ ఉచ్చు: tokens సులభంగా revoke చేయబడవు, payload చదవగలిగేది, మరియు `alg` గందరగోళం లేదా తప్పిపోయిన expiry తనిఖీ నిజమైన దుర్బలత్వాలు. signature ఏమి రక్షిస్తుంది, ఏమి రక్షించదు అనేది ఖచ్చితంగా తెలుసుకోవడం JWTs ను సురక్షితంగా వాడటానికి అవసరం.

నిల్వ	లాభం	నష్టం
`httpOnly` cookie	JS చేత చదవబడదు (XSS-safer)	CSRF రక్షణ అవసరం
`localStorage`	సరళం, CSRF లేదు	XSS కు బహిర్గతం

నిర్మాణం: మూడు base64url భాగాలు

Signing మరియు verification ఎలా పనిచేస్తాయి

కష్టమైన భాగం: revocation

నిల్వ trade-offs

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

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