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

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்