একটি JSON Web Token (JWT) কীভাবে কাজ করে?

Question

IT Interview Practice · Accepted Answer

একটি **JSON Web Token (JWT)** হলো একটি সংক্ষিপ্ত, URL-নিরাপদ, স্বয়ংসম্পূর্ণ token যা একজন ব্যবহারকারী সম্পর্কে claim বহন করে। সার্ভার এটি একবার sign করে; এরপর প্রতিটি request-এ ডেটাবেস lookup ছাড়াই token **verify** করতে পারে — এটাই JWT-ভিত্তিক auth-কে *stateless* করে তোলে।

## গঠন: তিনটি base64url অংশ

একটি JWT হলো `header.payload.signature`, ডট দিয়ে যুক্ত তিনটি base64url-এনকোডেড সেগমেন্ট:

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

- **Header** — signing অ্যালগরিদম, যেমন `{ "alg": "HS256", "typ": "JWT" }`।
- **Payload** — **claim**গুলো: স্ট্যান্ডার্ডগুলো যেমন `sub` (subject/user id), `exp` (মেয়াদ), `iat` (issued-at), `iss` (issuer), সঙ্গে যেকোনো কাস্টম ফিল্ড (`role`, `email`)।
- **Signature** — একটি secret বা private key দিয়ে header ও payload-এর উপর গণনা করা হয়।

> Payload **এনকোড করা, এনক্রিপ্ট করা নয়**। যে কেউ base64-decode করে পড়তে পারে, তাই কখনও JWT-তে পাসওয়ার্ড বা secret রাখবেন না।

## Signing ও verification কীভাবে কাজ করে

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

- **HS256** (সিমেট্রিক): একই secret sign ও verify করে। সহজ, কিন্তু প্রতিটি verifier-কে secret ধরে রাখতে হয়।
- **RS256** (অ্যাসিমেট্রিক): একটি **private key** sign করে, একটি **public key** verify করে। Auth সার্ভার private key রাখে; অন্য সার্ভিসগুলো public key দিয়ে verify করে এবং কখনও token তৈরি করতে পারে না।

প্রতিটি request-এ সার্ভার প্রাপ্ত 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); // টেম্পার করা বা মেয়াদোত্তীর্ণ হলে throw করে
  // claims.sub === "123"
} catch (e) {
  // প্রত্যাখ্যান: অবৈধ বা মেয়াদোত্তীর্ণ
}
```

## কঠিন অংশ: revocation

যেহেতু verification stateless, token মেয়াদ শেষ হওয়ার আগে সার্ভার-সাইডে শুধু "মুছে" দিয়ে আপনি এটি **অকার্যকর করতে পারবেন না**। সাধারণ প্রশমন:

- access token **স্বল্পমেয়াদী** (৫–১৫ মিনিট) রাখুন এবং একটি দীর্ঘমেয়াদী **refresh token**-এর সঙ্গে জোড়া দিন।
- logout/compromise-এর জন্য বাতিল token id (`jti`)-এর একটি ছোট **denylist** রাখুন — এটি সামান্য state ফিরিয়ে আনে।
- signing key ঘোরান।

## স্টোরেজ ট্রেড-অফ

| স্টোরেজ | সুবিধা | অসুবিধা |
|---|---|---|
| `httpOnly` cookie | JS পড়তে পারে না (XSS-নিরাপদতর) | CSRF সুরক্ষা দরকার |
| `localStorage` | সহজ, CSRF নেই | XSS-এর কাছে উন্মুক্ত |

## এটি কেন গুরুত্বপূর্ণ

JWT API, microservice এবং SPA জুড়ে stateless authentication চালায় — একটি সার্ভিস কেবল একটি signature verify করেই একটি request-কে বিশ্বাস করতে পারে, কোনো শেয়ার্ড session store ছাড়াই। কিন্তু সেই একই statelessness হলো ক্লাসিক ইন্টারভিউ ফাঁদ: token সহজে বাতিল করা যায় না, payload পড়া যায়, এবং `alg` বিভ্রান্তি বা একটি অনুপস্থিত expiry চেক বাস্তব দুর্বলতা। signature ঠিক কী রক্ষা করে, আর কী করে না, তা জানা JWT নিরাপদে ব্যবহারের জন্য অপরিহার্য।

স্টোরেজ	সুবিধা	অসুবিধা
`httpOnly` cookie	JS পড়তে পারে না (XSS-নিরাপদতর)	CSRF সুরক্ষা দরকার
`localStorage`	সহজ, CSRF নেই	XSS-এর কাছে উন্মুক্ত

গঠন: তিনটি base64url অংশ

Signing ও verification কীভাবে কাজ করে

কঠিন অংশ: revocation

স্টোরেজ ট্রেড-অফ

এটি কেন গুরুত্বপূর্ণ

সম্পর্কিত প্রশ্ন