JWT ডিকোডার

একটি JSON Web Token হলো তিনটি base64url-এনকোডেড সেগমেন্ট ডট দিয়ে যুক্ত: header.payload.signature। হেডার ও পেলোড JSON; স্বাক্ষরটি প্রথম দুটি সেগমেন্টের ওপর HMAC বা RSA/ECDSA আউটপুট। এই টুল ডটগুলিতে ভাগ করে, প্রতিটি অংশ base64url-ডিকোড করে, JSON পার্স করে, এবং exp-এর মতো স্ট্যান্ডার্ড টাইম ক্লেইমকে পাঠযোগ্য তারিখ হিসেবে দেখায়। এটি স্বাক্ষর যাচাই করে না — কেন তার জন্য নিচের FAQ দেখুন।

উদাহরণ

JWT স্পেস থেকে নমুনা টোকেন (HS256 স্বাক্ষরিত, সিক্রেট your-256-bit-secret):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

ডিকোডেড হেডার:

{
  "alg": "HS256",
  "typ": "JWT"
}

ডিকোডেড পেলোড:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

আমার JWT স্বাক্ষর অবৈধ হিসেবে চিহ্নিত কেন?

এই ডিকোডার স্বাক্ষর যাচাই করে না (FAQ দেখুন), কিন্তু যদি সার্ভার-সাইড ভ্যারিফায়ার আপনার টোকেন প্রত্যাখ্যান করে, এগুলি সাধারণ কারণ।

• ভুল সিক্রেট বা কী। HMAC সিক্রেটে মাত্র একটি অক্ষরের পার্থক্য সম্পূর্ণ ভিন্ন স্বাক্ষর তৈরি করে। যাচাইকারী সার্ভিসে JWT_SECRET env var ইস্যুকারীর সঙ্গে মেলে কিনা যাচাই করুন।
• অ্যালগরিদম অসঙ্গতি। HS256 দিয়ে স্বাক্ষরিত টোকেন RS256 দিয়ে যাচাই করা যায় না। হেডারে alg ক্লেইম পরীক্ষা করুন এবং নিশ্চিত করুন ভ্যারিফায়ার একই অ্যালগরিদমের জন্য কনফিগার করা আছে।
• মেয়াদোত্তীর্ণ টোকেন। সঠিকভাবে স্বাক্ষরিত JWT-ও exp অতীতে চলে গেলে যাচাইয়ে ব্যর্থ হয়। টাইম-ক্লেইম সারাংশ ডিকোডের পর এটি স্পষ্টভাবে দেখায়।
• ঘড়ির পার্থক্য। nbf (not-before) কাছাকাছি ভবিষ্যতে থাকলে এবং সার্ভার ঘড়ি একটু সরে গেলে "token not yet valid" ত্রুটি আসে। আপনার ভ্যারিফায়ারে ছোট্ট একটি lee-way অনুমোদন করুন (যেমন 60 সেকেন্ড)।
• পেস্ট করা টোকেনে হোয়াইটস্পেস। কপি-পেস্ট কখনো শুরুর ফাঁকা বা শেষের নিউলাইন নিয়ে আসে। একটি JWT অবশ্যই চারপাশে হোয়াইটস্পেস ছাড়া নিখুঁতভাবে header.payload.signature হবে।
• alg: none। হেডার যদি বলে "alg": "none", টোকেন অস্বাক্ষরিত। ভ্যারিফায়ারে এগুলি প্রত্যাখ্যান করুন — কখনো বৈধ হিসেবে গ্রহণ করবেন না।

এই টুল কি JWT স্বাক্ষর যাচাই করতে পারে?

না, এবং এটি ইচ্ছাকৃত। একটি স্বাক্ষর যাচাই করতে সাইনিং কী লাগে — একটি HMAC শেয়ারড সিক্রেট বা একটি অ্যাসিমেট্রিক পাবলিক কী। সেই কী টোকেন ইস্যু বা কনজিউম করা সার্ভারে থাকা উচিত, ওয়েব পৃষ্ঠায় পেস্ট করে নয়। এই টুল কেবল ডিকোড করে ও দেখায়; যাচাইকরণ আপনার ব্যাকএন্ডের সার্ভার-সাইডে হয়।

JWT-এর তিনটি সেগমেন্টের প্রতিটিতে কী থাকে?

একটি JWT হলো header.payload.signature। হেডার হলো JSON যা অ্যালগরিদম (alg) ও টোকেন টাইপ বর্ণনা করে। পেলোড হলো sub, iat, exp-এর মতো ক্লেইম ধারণকারী JSON। স্বাক্ষরটি প্রথম দুই সেগমেন্টকে সিক্রেট বা প্রাইভেট কী দিয়ে সাইন করার base64url-এনকোডেড আউটপুট। প্রথম দুটি শুধু এনকোড, এনক্রিপ্ট নয়।

আমার JWT মেয়াদোত্তীর্ণ — কীভাবে বুঝব?

পেলোডে exp ক্লেইম দেখুন। এটি সেকেন্ডে Unix টাইমস্ট্যাম্প। যদি Date.now() / 1000 exp-এর চেয়ে বড় হয়, টোকেন মেয়াদোত্তীর্ণ। এই টুল পেলোডের নিচে exp, iat ও nbf-কে পাঠযোগ্য তারিখ হিসেবে রেন্ডার করে, তাই নিজে হিসাব না করে এক নজরেই বুঝতে পারবেন।

alg: none মানে কী এবং কেন এটি বিপজ্জনক?

alg: none হলো JWT-এর এমন একটি বৈশিষ্ট্য যেখানে স্বাক্ষর খালি এবং চেক করা হয় না। অনেক লাইব্রেরি ঐতিহাসিকভাবে এমন টোকেন গ্রহণ করেছে, যা আক্রমণকারীদের পেলোড তৈরি করে alg-কে none সেট করে JWT জালিয়াতি করতে দিয়েছে। এই হেডার মান দেখলে টোকেন অস্বাক্ষরিত — যে সার্ভার এটি গ্রহণ করে তার ওপর বিশ্বাস রাখবেন না।

আপনি কি এখানে পেস্ট করা JWT সংরক্ষণ করেন?

না। ডিকোডারে পেস্ট করা কোনো টোকেন আমরা সংরক্ষণ করি না। আপনি যা ড্রপ করেন তা ট্যাব বন্ধ বা রিফ্রেশ করা মাত্রই বাতিল হয় — কিছুই লগ করা হয় না, এবং আপনি যা পরিদর্শন করেছেন তার কোনো রেকর্ড আমাদের পাশে নেই। তবুও: একটি JWT তার exp পর্যন্ত অ্যাক্সেস দেয় — পাসওয়ার্ডের মতো গণ্য করুন এবং ডিবাগ করা যেকোনো প্রোডাকশন টোকেন রোটেট করুন।

স্বাক্ষর অংশ একটি পড়তে-না-পারা ব্লব দেখাচ্ছে — এটি স্বাভাবিক?

হ্যাঁ। স্বাক্ষরটি HMAC বা RSA/ECDSA-এর বাইনারি আউটপুট, base64url-এনকোডেড। এটি মানুষের পড়ার জন্য নয় — এটি শুধু একটি ক্রিপ্টোগ্রাফিক চেক হিসেবে কাজ করে। ডিকোডেড হেডার ও পেলোডই JSON অংশ যা আপনি ব্যবহার করেন। খালি স্বাক্ষর মানে টোকেন অস্বাক্ষরিত (alg: none)।