JWT ডিকোডার ও যাচাইকারী

JWT কী

একটি JSON Web Token (JWT, উচ্চারণ "জট") দুটি পক্ষের মধ্যে claim বহন করার একটি সংক্ষিপ্ত, URL-নিরাপদ উপায় — প্রায়শই সেই sign-in টোকেন যা কোনো ব্যবহারকারী authenticate হওয়ার পরে আপনার অ্যাপ পায়। এর তিনটি অংশ থাকে যা ডট দিয়ে আলাদা করা: header.payload.signature। header ও payload হলো JSON অবজেক্ট যা কেবল Base64URL-এনকোড করা, তাই এগুলো যে কেউ পড়তে পারে — signature হলো সেটিই যা প্রমাণ করে টোকেন পরিবর্তন হয়নি এবং key ধারণকারী কেউ এটি ইস্যু করেছে।

তিনটি অংশ

• Header — signing অ্যালগরিদম (alg, যেমন HS256 বা RS256) ও টোকেনের ধরন (typ)।
• Payload — claim: টোকেনটি কার সম্পর্কে, কে ইস্যু করেছে, কখন expire হয়, এবং যেকোনো কাস্টম ডেটা।
• Signature — header.payload-এর একটি key-ভিত্তিক হ্যাশ। HMAC-এর জন্য এটি একটি shared secret ব্যবহার করে; RSA/ECDSA-এর জন্য এটি ইস্যুকারীর private key ব্যবহার করে এবং মিলিত public key দিয়ে পরীক্ষা করা হয়।

Registered claim

signature যাচাই করা

যাচাই প্রথম দুটি segment-এর উপর signature পুনরায় হিসাব করে এবং পরীক্ষা করে তা তৃতীয়টির সাথে মেলে কিনা। এই টুলটি HMAC পরিবার (HS256, HS384, HS512) যাচাই করে যখন আপনি shared secret দেন, ব্রাউজারের নেটিভ crypto.subtle ব্যবহার করে। অ্যাসিমেট্রিক টোকেন (RS256, ES256, PS256) সম্পূর্ণ ডিকোড হয়, তবে এদের signature কেবল ইস্যুকারীর public key (এর JWKS endpoint থেকে) দিয়ে যাচাই করা যায়, তাই এখানে পরীক্ষা করা হয় না। একটি ডিকোড করা টোকেন কখনো বৈধতার প্রমাণ নয় — সবসময় exp, nbf, aud ও iss-ও নিশ্চিত করুন।

একটি সমাধান-করা উদাহরণ

নিচের ক্লাসিক RFC 7519 নমুনা টোকেনটি HS256 এবং secret your-256-bit-secret ব্যবহার করে। এর header ডিকোড হয় {"alg":"HS256","typ":"JWT"}-এ এবং এর payload হয় {"sub":"1234567890","name":"John Doe","iat":1516239022}-এ — সেই iat হলো ২৩ জানুয়ারি ২০১৮। তাৎক্ষণিকভাবে ডিকোড ও যাচাই করতে উপরে উদাহরণ লোড করুন-এ ক্লিক করুন।

JWT কোথা থেকে আসে: JOSE পরিবার

JSON Web Token সংজ্ঞায়িত হয়েছে RFC 7519 (মে ২০১৫) দ্বারা, যা সম্পর্কিত মানদণ্ডের একটি সেটের একটি, যাদের সম্মিলিতভাবে বলা হয় JOSE (JavaScript Object Signing and Encryption)। যে signature প্রক্রিয়া এই টুলটি পরীক্ষা করে তা আসে JWS (JSON Web Signature, RFC 7515) থেকে; HS256 ও RS256-এর মতো অনুমোদিত অ্যালগরিদমের তালিকা আসে JWA (JSON Web Algorithms, RFC 7518) থেকে; public key প্রকাশের ফরম্যাট আসে JWK (JSON Web Key, RFC 7517) থেকে; এবং একটি আলাদা মানদণ্ড, JWE (JSON Web Encryption, RFC 7516), সেই টোকেনগুলোর জন্য যাদের বিষয়বস্তু আসলে লুকানো থাকে। একটি সাধারণ JWT — যে ধরনটি আপনি প্রায় যেকোনো আধুনিক ওয়েব অ্যাপে সাইন ইন করার পরে পান — একটি JWS: signed, কিন্তু encrypted নয়।

Signed, গোপন নয়

একটি স্ট্যান্ডার্ড JWT সম্পর্কে বোঝার সবচেয়ে গুরুত্বপূর্ণ বিষয় হলো এটি signed, encrypted নয়। header ও payload কেবল Base64URL-এনকোড করা — একটি এনকোডিং, এনক্রিপশন নয় — তাই টোকেন ধারণকারী যে কেউ এর ভেতরের প্রতিটি claim ডিকোড করে পড়তে পারে, ঠিক যেমন এই টুলটি করে, কোনো key ছাড়াই। signature বিষয়বস্তু লুকায় না; এটি কেবল দুটি বিষয় প্রমাণ করে: যে ইস্যুর পর থেকে টোকেন পরিবর্তন হয়নি, এবং যে এটি ইস্যু করেছে তার কাছে signing key ছিল। এ থেকে যে নিয়মটি আসে তা চূড়ান্ত: JWT payload-এ কখনো এমন কিছু রাখবেন না যা bearer-কে দেখতে দেওয়া উচিত নয় — কোনো password নয়, কোনো API key নয়, কোনো সংবেদনশীল ব্যক্তিগত ডেটা নয়। বিষয়বস্তু যদি সত্যিই গোপন থাকতে হয়, তবে আপনার JWE (encryption) প্রয়োজন, একটি সাধারণ signed JWT নয়।

HMAC বনাম RSA/ECDSA: signing-এর দুটি উপায়

JWS signature দুটি পরিবারে আসে। HMAC অ্যালগরিদম (HS256, HS384, HS512) symmetric: একটিই shared secret signature তৈরি করে এবং যাচাইও করে। এগুলো সহজ ও দ্রুত এবং তখন আদর্শ যখন একই পক্ষ টোকেন ইস্যু ও পরীক্ষা করে। এই টুলটি HMAC টোকেন সরাসরি যাচাই করতে পারে, কারণ আপনার কাছে secret থাকলে আপনার ব্রাউজারে signature পুনরায় হিসাব করার সবকিছুই আপনার কাছে আছে।

RSA (RS256/384/512, PS256/…) ও ECDSA (ES256/…) অ্যালগরিদম asymmetric: ইস্যুকারী একটি private key দিয়ে সাইন করে যা সে কখনো শেয়ার করে না, এবং যে কেউ মিলিত public key দিয়ে যাচাই করতে পারে। বড় identity provider-রা এটিই ব্যবহার করে, কারণ হাজার হাজার স্বাধীন সেবা কোনো টোকেন তৈরি করার ক্ষমতা না পেয়েও একটি টোকেন বৈধ করতে পারে। public key একটি well-known JWKS (JSON Web Key Set) endpoint-এ প্রকাশিত হয়। এই টুলটি অ্যাসিমেট্রিক টোকেন সম্পূর্ণ ডিকোড করে কিন্তু দূরবর্তী key আনে না, তাই এদের signature যাচাই করে না — সেই পরীক্ষাটি আপনার সার্ভারে, ইস্যুকারীর JWKS-এর বিপরীতে হওয়া উচিত।

আদৌ JWT কেন ব্যবহার করবেন? Stateless authentication

একটি ঐতিহ্যবাহী ওয়েব session একটি এলোমেলো session ID কুকিতে রাখে এবং আসল session ডেটা সার্ভার মেমরি বা ডেটাবেসে রাখে, তাই প্রতিটি request-এর জন্য একটি lookup প্রয়োজন হয়। একটি JWT এটি উল্টে দেয়: ব্যবহারকারীর পরিচয় ও অনুমতিগুলো signed টোকেনের ভেতরেই লেখা থাকে। যখন একটি request আসে, সার্ভারকে কেবল signature যাচাই করতে ও claim পড়তে হয় — কোনো ডেটাবেস round-trip নয়, কোনো shared session store নয়। এই statelessness-ই JWT-কে API, microservice ও অনুভূমিকভাবে স্কেল করা সিস্টেমের জন্য জনপ্রিয় করে তোলে, যেখানে কোনো fleet-এর যেকোনো সার্ভার নিজে একটি টোকেন বৈধ করতে পারে। টোকেনটি সাধারণত প্রতিটি request-এ একটি HTTP header-এ Authorization: Bearer <token> হিসেবে পাঠানো হয়।

statelessness-এর উল্টো দিকটি হলো revocation সমস্যা: যেহেতু সার্ভার ইস্যু করা টোকেনের কোনো রেকর্ড রাখে না, তাই কোনো টোকেন expire হওয়ার আগে সহজে কাউকে "log out" করতে পারে না। মানক প্রতিকারগুলো হলো ছোট expiry সময়, বাতিল করা টোকেন ID-এর একটি সার্ভার-সাইড denylist (jti claim), অথবা signing key ঘোরানো — এর প্রতিটিই নিয়ন্ত্রণের বিনিময়ে একটু state ফিরিয়ে আনে।

"alg: none" দুর্বলতা

প্রাথমিক JWT লাইব্রেরিগুলো none-এর একটি বিশেষ অ্যালগরিদম মান সম্মান করত, যার অর্থ টোকেনটি unsigned। কোনো আক্রমণকারী একটি বৈধ টোকেন নিয়ে, payload বদলে (উদাহরণস্বরূপ "role":"user"-কে "role":"admin"-এ উল্টে দিয়ে), header অ্যালগরিদম none-এ সেট করে, signature মুছে ফেলতে পারে, এবং একটি সরল সার্ভার তা গ্রহণ করবে। প্রতিরক্ষা হলো production-এ কখনো none গ্রহণ করবেন না এবং টোকেনের নিজের header-এর মানের উপর নির্ভর করার বদলে অ্যালগরিদমকে একটি স্পষ্ট allow-list-এর বিপরীতে বৈধ করুন। এই টুলটি এমন যেকোনো টোকেনকে unsigned ও জাল-করার-উপযোগী হিসেবে চিহ্নিত করে যার header alg: none ঘোষণা করে।

RS256-থেকে-HS256 confusion আক্রমণ

একটি আরও সূক্ষ্ম ও বিখ্যাত ত্রুটি হলো algorithm-confusion (বা key-confusion) আক্রমণ। একটি সার্ভার RS256 (asymmetric) প্রত্যাশা করে এবং টোকেনগুলো ইস্যুকারীর public key দিয়ে যাচাই করে — যা, সংজ্ঞা অনুসারে, public। যাচাই কোড যদি টোকেনে নামকৃত অ্যালগরিদমের উপর নির্ভর করে, তবে কোনো আক্রমণকারী header HS256-এ বদলে সেই public key-কে যেন এটি একটি HMAC secret, তা ব্যবহার করে একটি জাল টোকেন সাইন করতে পারে। যে লাইব্রেরি অন্ধভাবে HMAC-এ স্যুইচ করে, সে তখন সেই একই key-এর বিপরীতে জালিয়াতিটিকে "যাচাই" করবে যা আক্রমণকারী ব্যবহার করেছে। প্রতিরক্ষা alg: none-এর মতোই: সার্ভারকে প্রত্যাশিত অ্যালগরিদম pin করতে হবে এবং টোকেনকে কখনো ঠিক করতে দেওয়া যাবে না এটি কীভাবে পরীক্ষা করা হবে।

signature-এর চেয়েও বেশি যাচাই করুন

একটি বৈধ signature কেবল প্রমাণ করে যে টোকেন authentic ও অপরিবর্তিত — এটি প্রমাণ করে না যে টোকেনটি এখনই গ্রহণ করা উচিত। একটি সঠিক verifier registered claim-ও পরীক্ষা করে: exp (এটি কি expired?), nbf (এটি কি খুব তাড়াতাড়ি ব্যবহৃত হচ্ছে?), aud (এই সেবাটি কি উদ্দিষ্ট audience?) ও iss (কোনো বিশ্বস্ত issuer কি এটি তৈরি করেছে?)। যে টোকেন পুরোপুরি signed কিন্তু expired, বা ভিন্ন audience-এর জন্য, তা প্রত্যাখ্যান করা উচিত। ঠিক এ কারণেই একটি সার্ভার বৈধভাবে এমন একটি টোকেন প্রত্যাখ্যান করতে পারে যা এই টুলটি একটি বৈধ HMAC signature সহ দেখায়।

Registered, public ও private claim

RFC 7519 claim-কে তিনটি গ্রুপে ভাগ করে। Registered claim হলো উপরের টেবিলে দেওয়া সংক্ষিপ্ত, মানক নাম (iss, sub, aud, exp, nbf, iat, jti) — এদের কোনোটিই বাধ্যতামূলক নয়, তবে এগুলো ধারাবাহিকভাবে ব্যবহার করলে টোকেন interoperable থাকে। Public claim হলো সেই নাম যা IANA JSON Web Token রেজিস্ট্রিতে নিবন্ধিত বা কোনো সংঘর্ষ-প্রতিরোধী URI দিয়ে namespace করা। Private claim হলো সেই কাস্টম ফিল্ড যাতে আপনার নিজের অ্যাপ্লিকেশন সম্মত হয় — একটি role, scope-এর একটি তালিকা, একটি tenant ID। payload ছোট রাখা গুরুত্বপূর্ণ: টোকেন প্রতিটি request-এ ভ্রমণ করে, তাই একটি স্ফীত JWT প্রতিটি call-এ একটি বাস্তব bandwidth ও header-আকারের খরচ হয়ে ওঠে।

Access token, refresh token ও এগুলো কোথায় রাখবেন

যেহেতু চুরি হওয়া একটি access token expire না হওয়া পর্যন্ত অ্যাক্সেস দেয়, ভালো সিস্টেম এগুলো স্বল্পস্থায়ী রাখে — প্রায়শই ৫ থেকে ১৫ মিনিট — এবং এগুলোকে একটি দীর্ঘ-জীবী refresh token-এর সাথে যুক্ত করে যা কেবল নতুন access token পাওয়ার জন্য ব্যবহৃত হয় এবং কেন্দ্রীয়ভাবে বাতিল করা যায়। কোনো ব্রাউজারে আপনি টোকেন কোথায় রাখেন তা নিজেই একটি নিরাপত্তা সিদ্ধান্ত। এটি localStorage-এ রাখা সুবিধাজনক কিন্তু এটিকে পৃষ্ঠার যেকোনো cross-site-scripting (XSS) বাগের সামনে উন্মুক্ত করে দেয়, যা এটি পড়তে পারে। এটি একটি HttpOnly কুকিতে রাখা এটিকে JavaScript থেকে লুকায় (XSS কমায়) কিন্তু আপনি SameSite অ্যাট্রিবিউট বা একটি anti-CSRF টোকেন না যোগ করলে request-কে cross-site request forgery (CSRF)-এর প্রতি সংবেদনশীল করে তোলে। কোনো একক সঠিক উত্তর নেই — কেবল আপনার threat-model-এর জন্য একটি তথ্যপূর্ণ trade-off।

একটি JWT নিরাপত্তা চেকলিস্ট

• অ্যালগরিদম pin করুন। আপনার কোডে HS256 বা RS256 ঠিক করুন এবং none সহ বাকি সব প্রত্যাখ্যান করুন।
• শক্তিশালী HMAC secret ব্যবহার করুন। HS256-এর জন্য secret কমপক্ষে ২৫৬ বিট (৩২ এলোমেলো বাইট) প্রকৃত entropy-র হওয়া উচিত — একটি dictionary শব্দ আক্রমণকারীর কাছে টোকেন আসামাত্র অফলাইনে কয়েক মুহূর্তে brute-force হয়ে যায়, কারণ যাচাই স্থানীয় ও সীমাহীন।
• payload অ-গোপন রাখুন। একটি signed JWT-এর সবকিছুকে bearer-এর দ্বারা পাঠযোগ্য বলে ধরে নিন।
• exp সেট ও পরীক্ষা করুন। ছোট lifetime লিক হওয়া টোকেনের ক্ষতি সীমিত করে।
• aud ও iss বৈধ করুন যাতে অন্য কোনো সেবার জন্য বা অন্য কোনো issuer থেকে তৈরি টোকেন আপনার বিরুদ্ধে replay করা না যায়।
• অ্যাসিমেট্রিক টোকেন ইস্যুকারীর JWKS public key (cache ও refresh করা)-এর বিপরীতে যাচাই করুন — কখনো টোকেনে embed করা key-এর বিপরীতে নয়।
• একটি revocation পরিকল্পনা রাখুন — একটি jti denylist বা key ঘোরানো — সেই ক্ষেত্রগুলোর জন্য যা ছোট expiry কভার করতে পারে না।

এভাবে ব্যবহৃত হলে, JWT একটি মজবুত, ভালোভাবে বোঝা building block। বাস্তবে বেশিরভাগ JWT ঘটনা cryptography থেকে নয় বরং বাদ পড়া পরীক্ষা থেকে আসে — none গ্রহণ করা, header-এর অ্যালগরিদমে নির্ভর করা, বা একটি অনুমেয় HMAC secret ব্যবহার করা — এর প্রতিটিই প্রতিরোধযোগ্য।

Base64URL এনকোডিং কী

একটি JWT-এর ডটগুলো তিনটি Base64URL-এনকোড করা segment আলাদা করে। Base64URL হলো সাধারণ Base64-এর একটি ঘনিষ্ঠ চাচাতো ভাই যা কোনো URL-এ রাখার জন্য নিরাপদ: এটি + ও / অক্ষরকে - ও _ দিয়ে প্রতিস্থাপন করে, এবং সাধারণত = padding বাদ দেয়। header ও payload-এ প্রযুক্ত এটিই একমাত্র "রূপান্তর" — কোনো compression নেই এবং কোনো encryption নেই, এ কারণেই এই টুলটি (এবং অন্য যে কেউ) কেবল টোকেন দিয়ে এগুলো পড়তে পারে। signature segment হলো কাঁচা signature বাইট-এর Base64URL এনকোডিং, text-এর নয়, এ কারণেই এটি পাঠযোগ্য JSON-এর বদলে এলোমেলো অক্ষরের মতো দেখায়।

JWT বনাম opaque session টোকেন

JWT-ই একমাত্র ধরনের টোকেন নয়। ক্লাসিক বিকল্প হলো একটি opaque token — একটি দীর্ঘ এলোমেলো স্ট্রিং যা নিজে থেকে কিছুই বোঝায় না এবং কেবল session ডেটার একটি সার্ভার-সাইড store-এ একটি lookup key। trade-off হলো JWT-এর ঠিক উল্টো: একটি opaque token intercept হলে কিছুই প্রকাশ করে না এবং তাৎক্ষণিকভাবে বাতিল করা যায় (শুধু সার্ভার রেকর্ড মুছে দিন), কিন্তু প্রতিটি request-এর জন্য সেই lookup প্রয়োজন, তাই এটি stateless নয়। একটি JWT-এর কোনো lookup প্রয়োজন হয় না এবং এটি সার্ভারগুলোর জুড়ে অনায়াসে স্কেল করে, কিন্তু এটি পাঠযোগ্য, বড়, এবং expiry-র আগে বাতিল করা অসুবিধাজনক। অনেক সিস্টেম উভয়ই ব্যবহার করে — দ্রুত API authorization-এর জন্য স্বল্পস্থায়ী JWT, যা নবায়নের জন্য একটি opaque, বাতিলযোগ্য refresh token দ্বারা সমর্থিত — প্রতিটির শক্তি নিয়ে।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

আমার টোকেন কি কোথাও আপলোড হয়?

না। ডিকোডিং ও signature যাচাই সম্পূর্ণভাবে আপনার ব্রাউজারে বিল্ট-ইন Web Crypto API দিয়ে ঘটে। টোকেন ও secret কখনো আপনার ডিভাইস থেকে বাইরে যায় না এবং কখনো লগ বা ট্রান্সমিট হয় না — তাই এমন টোকেন পরীক্ষা করা নিরাপদ যা কোনো সার্ভার-সাইড টুলে পেস্ট করা ঝুঁকিপূর্ণ হতো। পৃষ্ঠা লোড হওয়ার পরে এটি অফলাইনেও কাজ করে।

ডিকোড করা JWT কি গোপন বা এনক্রিপ্টেড?

না। একটি স্ট্যান্ডার্ড JWT signed, encrypted নয় — header ও payload কেবল Base64URL-এনকোড করা, তাই টোকেন ধারণকারী যে কেউ সেগুলো পড়তে পারে। signature বিষয়বস্তু লুকায় না; এটি কেবল প্রমাণ করে যে টোকেনে হেরফের হয়নি এবং যে key জানে সে-ই এটি ইস্যু করেছে। কখনো এমন গোপন তথ্য JWT payload-এ রাখবেন না যা আপনি ক্লায়েন্টকে দেখাতে চান না।

এই টুলটি কোন signature যাচাই করতে পারে?

এটি HMAC signature যাচাই করে — HS256, HS384 ও HS512 — যখন আপনি shared secret দেন, নেটিভ Web Crypto API ব্যবহার করে। অ্যাসিমেট্রিক অ্যালগরিদম (RS256, ES256, PS256, EdDSA) সম্পূর্ণ ডিকোড হয়, তবে এদের signature ইস্যুকারীর public key দিয়ে যাচাই করা হয়, যা কেবল ইস্যুকারীর well-known endpoint-এর কাছে থাকে, তাই এই টুলটি সেগুলো যাচাই করে না।

এখানে "expired" মানে কী?

payload-এ যদি exp (expiration) claim থাকে এবং সেই মুহূর্তটি আপনার ডিভাইসের ঘড়ির তুলনায় অতীত হয়, তবে টোকেনটি expired হিসেবে দেখানো হয়। একইভাবে ভবিষ্যতের nbf (not-before) claim "এখনো বৈধ নয়" হিসেবে দেখানো হয়। এগুলো সরাসরি ডিকোড করা claim থেকে পড়া হয়; expiry পরীক্ষা সাধারণত টোকেন গ্রহণকারী সার্ভার করে থাকে।

signature "বৈধ" হওয়ার পরও সার্ভার আমার টোকেন প্রত্যাখ্যান করে কেন?

একটি বৈধ signature কেবল বোঝায় যে টোকেন পরিবর্তন হয়নি এবং key মিলে যায়। সার্ভার তবুও এটি প্রত্যাখ্যান করতে পারে কারণ এটি expired (exp), খুব তাড়াতাড়ি ব্যবহৃত (nbf), ভুল audience (aud) বা issuer (iss), অথবা বাতিল করা হয়েছে। ডিকোড করা payload-এ এই claim-গুলোও পরীক্ষা করুন।

সম্পর্কিত টুল

• Base64 এনকোডার / ডিকোডার
• JSON ফরম্যাটার ও ভ্যালিডেটর
• SHA হ্যাশ জেনারেটর
• Unix টাইমস্ট্যাম্প কনভার্টার
• UUID জেনারেটর

সব ব্রাউজার টুল দেখুন → · সব ডেভেলপার ও ডেটা রূপান্তর →