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 खण्डहरू:

```
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) जस्ता standard, साथै कुनै पनि 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); // छेडछाड वा म्याद सकिए error फाल्छ
  // claims.sub === "123"
} catch (e) {
  // अस्वीकार: अमान्य वा म्याद सकिएको
}
```

## कठिन भाग: revocation

Verification stateless भएकाले, तपाईं server-side बाट केवल "delete" गरेर token म्याद सकिनु अघि **अमान्य गर्न सक्नुहुन्न**। सामान्य उपायहरू:

- Access tokens **छोटो-आयु** (५–१५ मिनेट) राख्नुहोस् र तिनलाई लामो-आयुको **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` confusion वा हराएको expiry जाँच वास्तविक vulnerabilities हुन्। signature ले ठ्याक्कै के सुरक्षित गर्छ, र के गर्दैन भन्ने थाहा पाउनु JWTs सुरक्षित रूपमा प्रयोग गर्न अत्यावश्यक छ।

Storage	फाइदा	बेफाइदा
`httpOnly` cookie	JS ले पढ्न सक्दैन (XSS-safer)	CSRF सुरक्षा चाहिन्छ
`localStorage`	सरल, CSRF छैन	XSS मा उजागर

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

Signing र verification कसरी काम गर्छ

कठिन भाग: revocation

Storage trade-offs

यो किन महत्त्वपूर्ण छ

सम्बन्धित प्रश्नहरू