একটি JWT ডিকোডার আসলে কী করে
একটি JSON Web Token (JWT) দেখতে র্যান্ডম অক্ষরের একটি লম্বা, অস্বচ্ছ স্ট্রিং-এর মতো, কিন্তু এটি এনক্রিপ্টেড নয় এবং এটি কোনো গোপন সাইফার নয়। এটি একটি কমপ্যাক্ট, URL-নিরাপদ কন্টেইনার যা দুই পক্ষের মধ্যে গঠনবদ্ধ ডেটা বহন করে। উপরে একটি টোকেন পেস্ট করুন এবং ডিকোডার সেই স্ট্রিংটিকে আলাদা করে ভিতরের প্রকৃত JSON দেখায় — মেটাডেটা, দাবিগুলো (claims), টোকেনটি কার জন্য, এবং কখন এর মেয়াদ শেষ হয়। সবকিছু আপনার ব্রাউজারেই ঘটে। টোকেনটি কখনো আপলোড, লগ, বা কোথাও পাঠানো হয় না, যা তখন অনেক গুরুত্বপূর্ণ হয়ে ওঠে যখন আপনি যা পরীক্ষা করছেন তা একটি লাইভ সেশন ক্রেডেনশিয়াল।
তিনটি অংশ, দুটি ডট
প্রতিটি সু-গঠিত JWT হলো ডট দিয়ে যুক্ত তিনটি Base64url-এনকোড করা স্ট্রিং: header.payload.signature। সেই একক ডট অক্ষরটিই পার্সারদের জানার উপায় কোথায় একটি সেকশন শেষ হয় ও পরেরটি শুরু হয়, এবং এই কারণেই ভুল সংখ্যক ডটযুক্ত একটি টোকেন অন্য কিছু পড়ার আগেই প্রত্যাখ্যাত হয়।
হেডার হলো টোকেন নিজেকে বর্ণনা করা একটি ছোট JSON অবজেক্ট। এতে প্রায় সবসময় typ (ধরন, সাধারণত JWT) এবং alg — স্বাক্ষর অ্যালগরিদম থাকে, যেমন HS256 (SHA-256 সহ HMAC) বা RS256 (SHA-256 সহ RSA)। হেডার একজন যাচাইকারীকে বলে দেয় ঠিক কীভাবে সিগনেচারটি তৈরি করা হয়েছিল।
পেলোড হলো সেই অংশ যা বেশিরভাগ মানুষ নিয়ে চিন্তিত। এটি আরেকটি JSON অবজেক্ট যাতে দাবি (claims) থাকে — ব্যবহারকারী ও টোকেন সম্পর্কে বিবৃতি। স্পেসিফিকেশন দাবিগুলোকে নিবন্ধিত (স্ট্যান্ডার্ড, সংরক্ষিত নাম), পাবলিক, এবং প্রাইভেট (আপনার নিজের অ্যাপের জন্য আপনার তৈরি করা কাস্টম নাম) এ ভাগ করে। পেলোড ডিকোড করাই প্রকাশ করে কে লগ ইন করা আছে, তাদের ভূমিকা কী, এবং তাদের সেশন কখন শেষ হয়।
সিগনেচার হলো ক্রিপ্টোগ্রাফিক সিল। এটি হেডারের অ্যালগরিদম এবং একটি গোপন বা প্রাইভেট কী ব্যবহার করে এনকোড করা হেডার ও পেলোডের উপর গণনা করা হয়। যেহেতু এটি অন্য দুটি সেকশনকেই কভার করে, হেডার বা পেলোডের যেকোনো পরিবর্তন — এমনকি একটি অক্ষরও — এটিকে অবৈধ করে দেয়।
আপনি যে দাবিগুলো সবচেয়ে বেশি দেখবেন
নিবন্ধিত দাবিগুলো হলো RFC 7519 দ্বারা সংজ্ঞায়িত ছোট, তিন-অক্ষরের নাম যাতে বিভিন্ন সিস্টেম একসাথে কাজ করতে পারে। একটি হাতেগোনা প্রায় সর্বত্র দেখা যায়:
iss— issuer (প্রদানকারী): কে টোকেনটি তৈরি করেছে (আপনার অথ সার্ভার বা আইডেন্টিটি প্রোভাইডার)।sub— subject (বিষয়): যার সম্পর্কে টোকেনটি, সাধারণত একটি স্থিতিশীল ইউজার আইডি।aud— audience (গ্রহীতা): যার জন্য টোকেনটি উদ্দিষ্ট। একটি API-এর এমন টোকেন প্রত্যাখ্যান করা উচিত যার গ্রহীতা সে নিজে নয়।exp— expiration time (মেয়াদ শেষ হওয়ার সময়): একটি ইউনিক্স টাইমস্ট্যাম্প যার পরে টোকেনটি গ্রহণ করা যাবে না।iat— issued at (তৈরির সময়): টোকেনটি যখন তৈরি হয়েছিল সেই ইউনিক্স টাইমস্ট্যাম্প।
আপনি nbf (এর আগে নয়) এবং jti (একটি অনন্য টোকেন আইডি)-এরও দেখা পেতে পারেন। টাইমস্ট্যাম্পগুলো UTC-তে 1970 থেকে সেকেন্ড, যে কারণে একটি ডিকোডার যা এগুলোকে মানুষ-পাঠযোগ্য তারিখ হিসেবে রেন্ডার করে তা আপনার একটি টোকেন ইতিমধ্যে মেয়াদোত্তীর্ণ কিনা তা পরীক্ষা করার মানসিক গণনা বাঁচায়।
ডিকোড করা যাচাই করা নয় — এই অংশটিই মানুষকে কামড়ায়
এই পার্থক্যটি JWT সম্পর্কে বোঝার সবচেয়ে গুরুত্বপূর্ণ বিষয়। ডিকোডিং মানে বিষয়বস্তু পড়া: এতে কোনো কী প্রয়োজন হয় না এবং টোকেন ধারণকারী যে কেউ এটি করতে পারে, কারণ Base64url একটি এনকোডিং, এনক্রিপশন নয়। যাচাই মানে টোকেনটি প্রকৃত ও অক্ষত প্রমাণ করা — সঠিক গোপন বা পাবলিক কী দিয়ে সিগনেচার পুনর্গণনা করা ও নিশ্চিত করা যে এটি মিলে যায়।
এই টুলটি ডিকোড করে। এটি আপনাকে দেখায় টোকেনটি কী বলে, টোকেনটি বিশ্বাসযোগ্য কিনা তা নয়। একটি টোকেন জাল, মেয়াদোত্তীর্ণ, বা পুনরায় ব্যবহৃত হতে পারে এবং তারপরও একেবারে পরিষ্কার-দেখতে JSON হিসেবে ডিকোড হতে পারে। শুধুমাত্র ডিকোড করা দাবির উপর ভিত্তি করে কখনো একটি অথরাইজেশন সিদ্ধান্ত নেবেন না। প্রোডাকশনে আপনি সার্ভার-সাইডে সিগনেচার যাচাই করেন, exp পরীক্ষা করেন, এবং নিশ্চিত করেন iss ও aud আপনার প্রত্যাশার সাথে মিলে — একটি যাচাইকৃত লাইব্রেরি ব্যবহার করে, কখনো হাতে-তৈরি স্ট্রিং তুলনা নয়।
একটি পেলোড কোনো ভল্ট নয়
যেহেতু পেলোড শুধুমাত্র Base64url-এনকোডেড, এটি যে কেউ টোকেনটি আটকায় তার কাছে পাঠযোগ্য। এতে থাকা সবকিছুকে পাবলিক হিসেবে বিবেচনা করুন। JWT দাবিতে পাসওয়ার্ড, সম্পূর্ণ ক্রেডিট কার্ড নম্বর, গোপন কী, বা যেকোনো সংবেদনশীল ব্যক্তিগত ডেটা রাখবেন না — যদি আপনি এটিকে এখানে এক ক্লিকে ডিকোড করতে পারেন, তাহলে যে কেউ এর একটি কপি পায় সেও পারবে। সিগনেচার পরিবর্তনের বিরুদ্ধে রক্ষা করে, কখনো পড়ার বিরুদ্ধে নয়। যদি আপনার সত্যিই পেলোড বিষয়বস্তু লুকানোর প্রয়োজন হয়, তা JWE (এনক্রিপ্টেড টোকেন)-এর কাজ, যা সম্পূর্ণ ভিন্ন একটি স্পেসিফিকেশন।
গোপনীয়তা ও সম্পর্কিত টুল
একটি টোকেন পরীক্ষা করা একটি সংবেদনশীল কাজ, তাই এই ডিকোডারটি সম্পূর্ণভাবে ক্লায়েন্ট-সাইডে চলে — পার্সিং হলো আপনার ট্যাবে সাধারণ JavaScript এবং কিছুই আপনার মেশিন ছেড়ে যায় না। একটি সার্ভার-সমর্থিত টুলে একটি সেশন টোকেন পেস্ট করার মানে একটি লাইভ ক্রেডেনশিয়াল একটি তৃতীয় পক্ষকে হস্তান্তর করা, যা ঠিক যা আপনার এড়ানো উচিত। এর নিচের এনকোডিং-এর জন্য, আমাদের Base64 টুল দেখুন, এবং আরও অন-ডিভাইস ইউটিলিটির জন্য আমাদের বাকি ডেভেলপার টুল ঘুরে দেখুন।
প্রায়শই জিজ্ঞাসিত প্রশ্ন
একটি JWT কি এনক্রিপ্টেড?
না। একটি স্ট্যান্ডার্ড JWT হলো Base64url-এনকোডেড, এনক্রিপ্টেড নয়। টোকেনধারী যে কেউ হেডার ও পেলোড পড়তে পারে। যদি আপনার বিষয়বস্তু লুকানো প্রয়োজন হয় JWE ব্যবহার করুন।
এই টুল কি সিগনেচার যাচাই করে?
না। এটি শুধুমাত্র হেডার ও পেলোড ডিকোড ও প্রদর্শন করে। সিগনেচার যাচাই করতে প্রদানকারীর গোপন বা পাবলিক কী প্রয়োজন এবং এটি আপনার সার্ভারে করা উচিত।
এখানে আমার টোকেন পেস্ট করা কি নিরাপদ?
হ্যাঁ। ডিকোডিং সম্পূর্ণভাবে আপনার ব্রাউজারে লোকাল JavaScript ব্যবহার করে চলে। টোকেনটি কখনো আপলোড, সংরক্ষণ, বা কোনো সার্ভারে পাঠানো হয় না।
iss, sub, aud, exp এবং iat মানে কী?
এগুলো নিবন্ধিত দাবি: issuer (প্রদানকারী), subject (বিষয়), audience (গ্রহীতা), expiration time (মেয়াদ শেষের সময়) ও issued-at time (তৈরির সময়)। তিনটি সময়-সম্পর্কিতগুলো সেকেন্ডে ইউনিক্স টাইমস্ট্যাম্প ব্যবহার করে।
ডিকোড করার পর দেখানো দাবিগুলোকে আমি কি বিশ্বাস করতে পারি?
শুধু নিজেরাই নয়। ডিকোড করা দাবি একটি জাল বা মেয়াদোত্তীর্ণ টোকেন থেকে আসতে পারে। তাদের বিশ্বাস করার আগে সবসময় সিগনেচার যাচাই করুন ও সার্ভার-সাইডে মেয়াদ পরীক্ষা করুন।
আমার টোকেনে কেন ডট দিয়ে বিভক্ত তিনটি অংশ থাকে?
সেগুলো হেডার, পেলোড ও সিগনেচার, প্রতিটি Base64url-এনকোডেড এবং ডট দিয়ে যুক্ত। ডটগুলো পার্সারদের বলে দেয় প্রতিটি সেকশন কোথায় শুরু ও শেষ হয়।