JSON Web Token (JWT) કેવી રીતે કામ કરે છે?

Question

IT Interview Practice · Accepted Answer

**JSON Web Token (JWT)** એ એક કોમ્પેક્ટ, URL-સેફ, સ્વ-સમાવિષ્ટ ટોકન છે જે વપરાશકર્તા વિશે claims વહન કરે છે. સર્વર તેને એક વાર સાઇન કરે છે; ત્યાર બાદ તે ડેટાબેઝ lookup વગર દરેક વિનંતી પર ટોકનને **verify** કરી શકે છે — એ જ JWT-આધારિત auth ને *stateless* બનાવે છે.

## માળખું: ત્રણ base64url ભાગ

JWT એ `header.payload.signature` છે, ડોટ વડે જોડાયેલા ત્રણ base64url-એન્કોડેડ સેગમેન્ટ:

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

- **Header** — સાઇનિંગ અલ્ગોરિધમ, દા.ત. `{ "alg": "HS256", "typ": "JWT" }`.
- **Payload** — **claims**: પ્રમાણભૂત જેવા કે `sub` (subject/user id), `exp` (expiry), `iat` (issued-at), `iss` (issuer), ઉપરાંત કોઈ પણ કસ્ટમ ફીલ્ડ (`role`, `email`).
- **Signature** — secret અથવા private key વડે header અને payload પર ગણવામાં આવે છે.

> Payload **એન્કોડ થયેલો છે, એન્ક્રિપ્ટ થયેલો નથી**. કોઈ પણ તેને base64-decode કરીને વાંચી શકે છે, તેથી JWT માં ક્યારેય પાસવર્ડ કે secrets ન મૂકો.

## સાઇનિંગ અને verification કેવી રીતે કામ કરે છે

```
signature = HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)
```

- **HS256** (સિમેટ્રિક): એ જ secret સાઇન અને verify કરે છે. સરળ, પણ દરેક verifier પાસે secret હોવો જ જોઈએ.
- **RS256** (અસિમેટ્રિક): **private key** સાઇન કરે છે, **public key** verify કરે છે. Auth સર્વર private key રાખે છે; બીજી સેવાઓ public key વડે verify કરે છે અને ક્યારેય ટોકન બનાવી શકતી નથી.

દરેક વિનંતી પર સર્વર મળેલા header+payload પર signature ફરી ગણે છે અને તેની સરખામણી કરે છે. જો તે મેચ થાય અને `exp` ભવિષ્યમાં હોય, તો ટોકન પર વિશ્વાસ કરાય છે — કોઈ 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); // છેડછાડ થઈ હોય કે સમય પૂરો થયો હોય તો throw કરે છે
  // claims.sub === "123"
} catch (e) {
  // નકારો: અમાન્ય અથવા expired
}
```

## અઘરો ભાગ: revocation

કારણ કે verification stateless છે, તમે એક ટોકનને તેનો સમય પૂરો થાય તે પહેલાં ફક્ત સર્વર-બાજુ "કાઢી નાખીને" **અમાન્ય કરી શકતા નથી**. સામાન્ય ઉપાયો:

- Access ટોકનને **અલ્પજીવી** (5–15 મિનિટ) રાખો અને તેમને લાંબા-જીવી **refresh token** સાથે જોડો.
- Logout/compromise માટે revoke થયેલા ટોકન id (`jti`) ની એક નાની **denylist** જાળવો — આ થોડું state પાછું લાવે છે.
- સાઇનિંગ keys ને rotate કરો.

## Storage ટ્રેડ-ઓફ

| Storage | ફાયદો | ગેરફાયદો |
|---|---|---|
| `httpOnly` cookie | JS દ્વારા વાંચી શકાતું નથી (XSS-થી સલામત) | CSRF સુરક્ષા જરૂરી |
| `localStorage` | સરળ, CSRF નહીં | XSS સામે ખુલ્લું |

## આ શા માટે મહત્વનું છે

JWTs API, microservices, અને SPAs પર stateless authentication ને શક્તિ આપે છે — એક સેવા માત્ર signature verify કરીને વિનંતી પર વિશ્વાસ કરી શકે છે, કોઈ shared session store વગર. પણ એ જ statelessness ક્લાસિક ઇન્ટરવ્યુ ફાંદો છે: ટોકન સરળતાથી revoke થઈ શકતા નથી, payload વાંચી શકાય છે, અને `alg` ગૂંચવણ કે expiry check ની ગેરહાજરી વાસ્તવિક નબળાઈઓ છે. signature શું સુરક્ષિત કરે છે અને શું નથી કરતું તે ચોક્કસ જાણવું એ JWTs નો સલામત ઉપયોગ કરવા માટે આવશ્યક છે.

Storage	ફાયદો	ગેરફાયદો
`httpOnly` cookie	JS દ્વારા વાંચી શકાતું નથી (XSS-થી સલામત)	CSRF સુરક્ષા જરૂરી
`localStorage`	સરળ, CSRF નહીં	XSS સામે ખુલ્લું

માળખું: ત્રણ base64url ભાગ

સાઇનિંગ અને verification કેવી રીતે કામ કરે છે

અઘરો ભાગ: revocation

Storage ટ્રેડ-ઓફ

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો