JWT ডিকোডার

JWT কী?#

একটি JWT (JSON Web Token, RFC 7519-এ সংজ্ঞায়িত) হলো একটি কমপ্যাক্ট, URL-নিরাপদ টোকেন যা দুটি পক্ষের মধ্যে দাবি বহন করতে নির্মিত। এটি হলো সেই পরিচয়পত্র যা আপনার ব্রাউজার লগইনের পরে একটি API-তে পাঠায়, পরিচয় দাবি যা একটি OAuth প্রদানকারী একটি নির্ভরশীল অ্যাপ্লিকেশনকে দেয়, এবং খাম যাতে বেশিরভাগ আধুনিক সেশন এবং অ্যাক্সেস-নিয়ন্ত্রণ প্রবাহ ভ্রমণ করে। আকর্ষণটি হলো দাবিগুলো — ব্যবহারকারী কে, তারা কী করতে পারে, টোকেনটি কখন মেয়াদ শেষ করে — JSON হিসেবে টোকেনের ভেতরেই ভ্রমণ করে, তাই গ্রহণকারী পরিষেবা একটি ডেটাবেস অনুসন্ধান ছাড়াই সেগুলো পড়তে পারে।

একটি JWT-এর ঠিক তিনটি dot-এনকোডেড base64url অংশ রয়েছে যা ডট দ্বারা বিভাজিত: header.payload.signature। হেডার অ্যালগরিদম এবং টোকেন ধরনের নাম দেয়। পেলোড হলো দাবিগুলোর একটি JSON অবজেক্ট — নিবন্ধিতগুলো যেমন sub (বিষয়), iat (ইস্যু করা), exp (মেয়াদ শেষ), nbf (এর পরে), প্লাস আপনার অ্যাপ্লিকেশন যা যোগ করে এমন যেকোনো কাস্টম দাবি। স্বাক্ষর হলো যা ইস্যুকারী অন্য দুটি অংশের উপর একটি গোপন বা প্রাইভেট কী দিয়ে গণনা করেছিল; এটি যাচাই করাই প্রমাণ করে যে টোকেনটির কোনো হেরফের হয়নি।

এই পৃষ্ঠাটি একটি JWT ডিকোড করে এবং পরিদর্শন করে। এটি তিনটি অংশকে বিভক্ত করে, হেডার এবং পেলোডকে পাঠযোগ্য JSON-এ base64url-ডিকোড করে, প্রমিল সময় দাবিগুলোকে মানব-পাঠযোগ্য টাইমস্ট্যাম্প হিসেবে প্রকাশ করে, এবং একটি লাইভ স্ট্যাটাস ব্যাজ দেখায় (বৈধ, মেয়াদোত্তীর্ণ, এখনও বৈধ নয়)। এটি ইচ্ছাকৃতভাবে স্বাক্ষর যাচাই করে না — এটির জন্য ইস্যুকারীর গোপন বা পাবলিক কী প্রয়োজন এবং একটি ১০০% ক্লায়েন্ট-সাইড টুলের সুযোগের বাইরে। স্বাক্ষর সেগমেন্টটি অপরিবর্তিত, যেমন গৃহীত হয়েছে তেমনভাবে প্রদর্শিত হয়।

কীভাবে ব্যবহার করবেন#

1. আপনার টোকেনটি বাম দিকের ইনপুট বক্সে পেস্ট করুন। এটি অবশ্যই তিনটি ডট-বিভাজিত সেগমেন্ট হতে হবে; এর চারপাশের সাদাসিধে স্বয়ংক্রিয়ভাবে ছাঁটা হয়।
2. আপনি যদি কেবল দেখতে চান লেআউটটি কীভাবে কাজ করে তবে একটি বিল্ট-ইন উদাহরণ টোকেন (iat/exp/nbf সহ) লোড করতে নমুনা ক্লিক করুন।
3. ইনপুট এবং ফলাফল পেনগুলো খালি করতে মুছুন ক্লিক করুন।
4. ডান দিকের প্যানেলটি পড়ুন:
   • উপরের স্ট্যাটাস ব্যাজ — সবুজ বৈধ, মেয়াদোত্তীর্ণ, বা এখনও বৈধ নয় — বর্তমান সময়ের সাথে তুলনা করে nbf এবং exp দাবির উপর ভিত্তি করে।
   • হেডার কার্ড (শিরোনাম বারে অ্যালগরিদম দেখানো হয়েছে, যেমন HS256)।
   • পেলোড কার্ড, JSON হিসেবে সুন্দরভাবে মুদ্রিত।
   • সময়-দাবি তালিকা — ইস্যু করা, এর পরে, মেয়াদ শেষ — প্রতিটি একটি unix টাইমস্ট্যাম্প এবং একটি পাঠযোগ্য তারিখ হিসেবে রেন্ডার করা।
   • স্বাক্ষর সেগমেন্ট, অপরিবর্তিত দেখানো হয় কারণ এটি এখনও base64url-এনকোডেড বাইট।
5. টোকেনটি যদি বিকৃত হয়, লাল স্ট্যাটাস লাইন আপনাকে জানায় এটি তিন-সেগমেন্ট আকৃতি চেক, base64url ডিকোড, বা JSON পার্সে ব্যর্থ হয়েছে কিনা।

প্রধান বৈশিষ্ট্য#

• লাইভ সময়-দাবি স্ট্যাটাস। iat, nbf, এবং exp পড়ে এবং আপনাকে বলে টোকেনটি বর্তমানে বৈধ, ইতিমধ্যে মেয়াদোত্তীর্ণ, বা এখনও কার্যকর নয় — তিনটি প্রশ্ন আপনি একটি লগইন বাগের সময় সত্যিই জিজ্ঞাসা করেন।
• মানব-পাঠযোগ্য তারিখ। 1700000000-এর মতো Unix epoch সংখ্যাগুলো তাদের প্রতিনিধিত্ব করে এমন UTC তারিখের পাশে দেখানো হয়, তাই আপনি মানসিক epoch পাটিগণিত করা বন্ধ করেন।
• অ্যালগরিদম প্রকাশিত। হেডারের alg মানটি হেডার কার্ডের শিরোনাম বারে টানা হয়, তাই আপনি তাৎক্ষণিকভাবে দেখেন আপনি একটি HS256, RS256, বা অপ্রত্যাশিত কিছু ধরে আছেন কিনা।
• UTF-8 নিরাপদ ডিকোডিং। base64url সেগমেন্টগুলোকে TextDecoder-এর মাধ্যমে বাইট হিসেবে ডিকোড করা হয়, তাই অ-ASCII দাবিগুলো (নাম, অন্যান্য স্ক্রিপ্টে ভূমিকা) মোজিবাকে হিসেবে নয়, সঠিকভাবে রেন্ডার হয়।
• কেবল ডিকোড — কখনো যাচাই করবেন না। টুলটি কখনো একটি গোপন চায় না, যা এটিকে এমন টোকেন পেস্ট করতে নিরাপদ করে তোলে যা আপনি সম্পূর্ণ বিশ্বাস করেন না: কিছুই কোথাও পাঠানো হয় না, এবং স্বাক্ষরটি দেখানো হয় কিন্তু চেক করা হয় না।

ব্যবহারের উদাহরণ#

নমুনা ক্লিক করুন এবং ইনপুটটি একটি টোকেন দিয়ে পূরণ হয় যার হেডার ডিকোড হয়:

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

এবং যার পেলোড ডিকোড হয়:

{
  "sub": "1234567890",
  "name": "ArpGate Demo",
  "iat": 1700000000,
  "exp": 4102444800,
  "nbf": 1699999000
}

তারপর সময়-দাবি তালিকাটি দেখায়:

Issued at   1700000000  (2023-11-14 22:13:20 UTC)
Not before  1699999000  (2023-11-14 21:56:40 UTC)
Expires     4102444800  (2100-01-01 00:00:00 UTC)

স্ট্যাটাস ব্যাজটি পড়ে বৈধ, কারণ বর্তমান সময় nbf-এর পরে এবং exp-এর আগে। স্বাক্ষর সেগমেন্টটি আক্ষরিক স্ট্রিং c2FtcGxlLXNpZ25hdHVyZS1ub3QtdmVyaWZpZWQ হিসেবে দেখানো হয় — যা “sample-signature-not-verified” টেক্সটে ডিকোড হয়, একটি ইচ্ছাকৃত মার্কার যে এই টোকেনের স্বাক্ষরটি চিত্রণমূলক, একটি প্রকৃত HMAC-SHA256 আউটপুট নয়।

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

প্রশ্নোত্তর#

এই টুল কি আমাকে বলতে পারে একটি JWT প্রামাণিক কি না?#

না, এবং সেটি ডিজাইন অনুযায়ী। কেবল ডিকোড করা টোকেনের ভেতরের JSON পড়ে — এটি প্রমাণ করে না যে টোকেনটি যিনি ইস্যু করেছেন বলে দাবি করেছেন তিনি ইস্যু করেছেন। প্রামাণ্যতা যাচাই করতে আপনার alg-উপযুক্ত কী প্রয়োজন (HS256-এর জন্য একটি ভাগ করা গোপন, RS256/ES256-এর জন্য ইস্যুকারীর পাবলিক কী) এবং একটি বিশ্বস্ত ব্যাকএন্ডে একটি যাচাইকরণ রুটিন। একটি পরিষ্কারভাবে ডিকোড করা টোকেনকে কখনো যাচাই করা হিসেবে বিবেচনা করবেন না।

স্ট্যাটাস বলছে “মেয়াদোত্তীর্ণ”। আমি কি এখানে টোকেনটি রিফ্রেশ করতে পারি?#

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

iat, nbf, এবং exp-এর মধ্যে পার্থক্য কী?#

iat (ইস্যু করা) হলো যখন টোকেনটি তৈরি হয়েছিল — তথ্যমূলক। nbf (এর পরে) হলো প্রাচীনতম সময় যখন টোকেনটি গৃহীত হওয়া উচিত; nbf-এর আগে একটি যাচাইকারী সার্ভার এটি প্রত্যাখ্যান করা উচিত এমনকি যদি স্বাক্ষরটি বৈধও হয়। exp (মেয়াদ শেষ) হলো কঠোর কাটঅফ যার পরে টোকেনটি অবশ্যই প্রত্যাখ্যাত হবে। একটি সুগঠিত টোকেনে nbf ≤ iat ≈ এখন এবং exp নিকট ভবিষ্যতে কোথাও থাকে (অ্যাক্সেস টোকেনের জন্য মিনিট, রিফ্রেশ টোকেনের জন্য দীর্ঘতর)।

আমার পেলোডে অ-ASCII অক্ষর আছে এবং সেগুলো অন্য কোথাও গার্বল দেখায়। সেগুলো এখানে কেন ঠিক আছে?#

কারণ কিছু ডিকোডার ভুলভাবে প্রতিটি base64url অক্ষরকে একটি বাইট হিসেবে বিবেচনা করে প্রথমে কাঁচা বাইটে ডিকোড করার বদলে। এই পৃষ্ঠাটি একটি Uint8Array-তে ডিকোড করে এবং তারপর এটিকে TextDecoder-এর মাধ্যমে চালায়, যা বাইটগুলোকে সঠিক UTF-8 হিসেবে ব্যাখ্যা করে। এটিই সঠিক উপায়, এবং এই কারণেই যেকোনো স্ক্রিপ্টে নাম, ভূমিকা, এবং স্কোপ যেমন লেখা হয়েছে তেমনভাবে রেন্ডার হয়।