JWT ও Session Management
- ●Session হলো stateful (সার্ভার মনে রাখে), JWT হলো stateless (token নিজেই তথ্য বহন করে)।
- ●JWT-এর তিনটি অংশ— header, payload, signature; signature দিয়ে tampering ধরা পড়ে।
- ●JWT-এর বড় চ্যালেঞ্জ হলো মেয়াদ শেষের আগে revoke করা কঠিন।
সমস্যাটা কী?
HTTP একটি stateless প্রোটোকল— প্রতিটি request আগের request-এর কথা মনে রাখে না। তার মানে তুমি একবার লগইন করলেও, পরের request-এ সার্ভার ভুলে যায় তুমি কে। তাহলে প্রতিবার পেজ বদলালেই কি আবার password দিতে হবে? অবশ্যই না।
সমাধান হলো লগইনের পর সার্ভার একটা "প্রমাণপত্র" দেয়, যা তুমি পরের প্রতিটি request-এ সাথে পাঠাও। এই প্রমাণপত্র দুই রকমভাবে বানানো যায়— session বা JWT। কোনটা কখন ব্যবহার করবে, আর কোথায় token রাখবে— এই সিদ্ধান্তগুলো ভুল হলে অ্যাকাউন্ট হাইজ্যাক পর্যন্ত হতে পারে।
মূল ধারণা
Session হলো server-side পরিচয় সংরক্ষণ— সার্ভার ইউজারের তথ্য মনে রাখে ও একটি ছোট ID দেয়। JWT (JSON Web Token) হলো একটি স্বয়ংসম্পূর্ণ, সাইন-করা token যা নিজের ভেতরেই ইউজারের তথ্য বহন করে— সার্ভারকে কিছু মনে রাখতে হয় না।
মূল পার্থক্যটা state নিয়ে। Session-এ সার্ভার stateful— সে নিজের memory বা database-এ প্রতিটি active session রাখে। JWT-তে সার্ভার Stateless— token-এর ভেতরেই সব তথ্য থাকে, সার্ভার শুধু signature যাচাই করে নিশ্চিত হয় token আসল।
কীভাবে কাজ করে
Session যেভাবে কাজ করে
- ইউজার লগইন করে।
- সার্ভার একটি random session ID বানায়, ইউজারের তথ্যসহ নিজের store-এ রাখে।
- session ID একটি cookie-তে ইউজারকে দেয়।
- পরের প্রতি request-এ browser ওই cookie পাঠায়; সার্ভার ID দিয়ে store-এ খুঁজে ইউজার চেনে।
JWT-এর গঠন
JWT তিনটি অংশ নিয়ে, dot (.) দিয়ে আলাদা— header.payload.signature`:
eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjEyMywicm9sZSI6ImFkbWluIn0.S1gN...
- Header: কোন algorithm ব্যবহার হয়েছে (যেমন HS256)।
- Payload: আসল ডেটা বা "claims"— যেমন userId, role, expiry। এটি শুধু base64-encoded, encrypted নয়, তাই যে কেউ পড়তে পারে।
- Signature: header ও payload-কে গোপন key দিয়ে সাইন করা। কেউ payload বদলালে signature আর মিলবে না।
সার্ভার token পেলে শুধু signature যাচাই করে— সঠিক হলে নিশ্চিত হয় token সে-ই দিয়েছিল এবং কেউ বদলায়নি।
তুলনা
| বিষয় | Session | JWT |
|---|---|---|
| State | Stateful (সার্ভার মনে রাখে) | Stateless |
| স্কেলিং | একাধিক সার্ভারে shared store লাগে | সহজে স্কেল হয় |
| Revoke | সহজ (store থেকে মুছে দাও) | কঠিন |
| আকার | ছোট ID | তুলনামূলক বড় |
| উপযুক্ত | একক/ছোট অ্যাপ | microservice, API |
Session অনেকটা জিমের রিসেপশনের খাতার মতো— তোমাকে শুধু একটা টোকেন নম্বর দেয়, আসল তথ্য খাতায় (সার্ভারে) লেখা থাকে; রিসেপশন চাইলেই তোমার এন্ট্রি কেটে দিতে পারে। JWT হলো ছবিযুক্ত পরিচয়পত্রের মতো— সব তথ্য কার্ডেই লেখা ও সিল মারা; গার্ড শুধু সিল দেখে বিশ্বাস করে, অফিসে ফোন করতে হয় না— কিন্তু কার্ড একবার দিলে মেয়াদ শেষ না হওয়া পর্যন্ত ফেরত নেওয়া কঠিন।
কৌশল
Token কোথায় রাখবে
- HttpOnly cookie: JavaScript এতে হাত দিতে পারে না, তাই XSS দিয়ে চুরি কঠিন। তবে CSRF সুরক্ষা (SameSite attribute) লাগে।
- localStorage: ব্যবহার সহজ, কিন্তু XSS হলে token সহজেই চুরি হয়। সাধারণত নিরুৎসাহিত।
- Memory (variable): সবচেয়ে কম ঝুঁকি, কিন্তু পেজ refresh-এ মুছে যায়।
সাধারণ পরামর্শ: HttpOnly Cookie + SameSite ব্যবহার করো।
Expiry ও Refresh
Access token সবসময় স্বল্পমেয়াদি রাখো (যেমন ১৫ মিনিট)। চুরি হলেও অল্প সময়েই অকেজো হবে। মেয়াদ শেষ হলে দীর্ঘমেয়াদি Refresh Token দিয়ে নতুন access token নেওয়া হয়, ইউজারকে আবার লগইন করতে হয় না। refresh token সাধারণত HttpOnly cookie-তে রাখা হয় এবং প্রতিবার ব্যবহারে নতুন করে ইস্যু করা (rotation) ভালো অভ্যাস।
Revocation চ্যালেঞ্জ
এটি JWT-এর সবচেয়ে বড় দুর্বলতা। যেহেতু সার্ভার token মনে রাখে না, কেউ লগআউট করলে বা token চুরি হলে মেয়াদের আগে সেটি বাতিল করা কঠিন। সাধারণ সমাধান:
- token-এর মেয়াদ খুব ছোট রাখা।
- একটি blocklist (বাতিল করা token-এর তালিকা) রাখা— তবে এতে কিছুটা stateful হয়ে যায়।
- refresh token rotation ও তা database-এ ট্র্যাক করা।
কখন ব্যবহার করবে / করবে না
একক সার্ভার বা সাধারণ ওয়েব অ্যাপে session সহজ, নিরাপদ ও revoke করা সরল— এটাই বেছে নাও। অনেক service বা মোবাইল ক্লায়েন্টওয়ালা stateless API-তে JWT সুবিধাজনক।
JWT-এর payload encrypted নয়— শুধু signed। তাই password, card নম্বর বা গোপন তথ্য কখনো payload-এ রেখো না; যে কেউ base64 decode করে পড়ে ফেলবে। আর alg: none বা দুর্বল algorithm কখনো মেনে নিও না— এটি একটি পরিচিত আক্রমণ।
বাস্তব উদাহরণ
বড় microservice-নির্ভর প্রতিষ্ঠান, যেমন Netflix বা Uber, প্রায়ই JWT-ধাঁচের stateless token ব্যবহার করে, কারণ একটি token শত শত আলাদা service আলাদাভাবে যাচাই করতে পারে— প্রতিবার central session store-এ ফোন করতে হয় না, ফলে latency কমে ও স্কেলিং সহজ হয়। অন্যদিকে অনেক ঐতিহ্যবাহী ওয়েব অ্যাপ (যেমন একক ই-কমার্স সাইট) এখনো server-side session ব্যবহার করে, কারণ instant logout ও সহজ revocation তাদের জন্য বেশি গুরুত্বপূর্ণ।
ইন্টারভিউতে যদি বলে "JWT দিয়ে কীভাবে logout করবে?"— এটি একটি ফাঁদ প্রশ্ন। সঠিক উত্তর: "যেহেতু JWT stateless, সত্যিকারের instant revocation নেই; তাই short expiry + refresh token rotation, প্রয়োজনে একটি blocklist ব্যবহার করি।" এই স্বীকারোক্তিই দেখায় তুমি trade-off বোঝো।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. JWT-এর কোন অংশ tampering ধরতে সাহায্য করে?
2. Session-ভিত্তিক auth কেন stateful বলা হয়?
3. ব্রাউজারে token রাখার সবচেয়ে নিরাপদ জায়গা সাধারণত কোনটি?