একটি JSON Web Token, RFC 7519, দাবির একটি সেট একটি পক্ষ থেকে অন্য পক্ষে
পরিবহন করার একটি সংক্ষিপ্ত পদ্ধতি, যাতে প্রাপক পক্ষ বিশ্বাস করতে পারে কে তা
পাঠিয়েছে, অথবা কমপক্ষে যাচাই করতে পারে পরিবহনে কিছুই পরিবর্তন হয়নি। প্রতিটি JWT যা
আপনি Authorization: Bearer হেডারে দেখবেন সেগুলি একই তিনটি অংশ ডট দ্বারা জুড়ে:
header.payload.signature।
তিনটি অংশ
হেডার এবং পেলোড প্রতিটি একটি JSON অবজেক্ট, base64url এনকোডেড। হেডার
সিগনিং অ্যালগোরিদম এবং টোকেন ধরনের নাম দেয়, সাধারণত কিছু
ছোট {"alg":"HS256","typ":"JWT"}। পেলোড দাবি ধারণ করে: টোকেন প্রকৃতপক্ষে যে
ডেটা পরিবহন করছে, সাথে সংজ্ঞায়িত অর্থ সহ কয়েকটি নিবন্ধিত নাম, iss (প্রকাশক), sub (বিষয়), aud (দর্শক), iat
(প্রকাশিত), nbf (আগে নয়) এবং exp (মেয়াদ শেষ) এবং jti (একটি টোকেন আইডি)। এগুলির
কোনোটিই বিনির্দেশ দ্বারা প্রয়োজনীয় নয় প্রকাশক যা অন্তর্ভুক্ত করতে চায় তার বাইরে,
তাই দুটি ভিন্ন সার্ভিস থেকে দুটি JWT সম্পূর্ণ ভিন্ন দাবি পরিবহন করতে পারে।
সিগনেচার সম্পূর্ণভাবে JSON নয়। এটি হেডার এবং পেলোড চালানোর আউটপুট,
এখনও তাদের এনকোডেড আকারে, হেডারে নামকৃত অ্যালগোরিদম দিয়ে, HS256 (HMAC একটি
শেয়ার্ড সিক্রেট সহ) এবং RS256/ES256 (RSA বা
ECDSA একটি প্রাইভেট কী সহ) আপনি সবচেয়ে বেশি দেখবেন। base64url দ্বারা সিগনেচার ডিকোড
করলে আপনাকে কাঁচা বাইট দেয় যাতে আর পড়ার কোনো কাঠামো নেই।
এনকোডেড মানে এনক্রিপ্টেড নয়
Base64url একটি এনকোডিং, একটি সাইফার নয়। JWT ধরে রাখা যেকোনো ব্যক্তি হেডার এবং পেলোড শুধুমাত্র একটি টেক্সট এডিটর দিয়ে ডিকোড করতে পারে, যা ঠিক JWT Decoder করে। এর মানে হলো একটি JWT কখনই এমন কিছুর জন্য সঠিক জায়গা নয় যা আপনি URL-এ না রাখবেন: একটি পাসওয়ার্ড, একটি ক্রেডিট কার্ড নম্বর, কারো পূর্ণ নাম যাকে প্রকাশ করার সম্মতি দেওয়া হয়নি। যদি পেলোডকে শুধুমাত্র অপরিবর্তনযোগ্যের পরিবর্তে গোপনীয় থাকতে হয়, তাহলে একটি JSON Web Encryption টোকেন প্রয়োজন, একটি ভিন্ন এবং কম সাধারণ ফরম্যাট, একটি শক্তিশালী অ্যালগোরিদম সহ স্বাক্ষরিত JWT নয়।
ডিকোড করা বিশ্বাস সম্পর্কে কিছুই বলে না
এটিই অংশ যার জন্য ডিকোডারকে সবচেয়ে বেশি দোষ দেওয়া হয়, তাই স্পষ্ট বলা মূল্যবান: JWT থেকে দাবি পড়া প্রমাণ করে না যে টোকেন আসল। সিগনেচার যাচাই করার মানে হল এটি পুনর্গণনা করা প্রকৃত সিক্রেট বা পাবলিক কী দিয়ে টোকেন স্বাক্ষরিত হয়েছিল এবং যাচাই করা এটি মিলে যায়, বাইট দর বাইট। একটি ডিকোডার যা শুধুমাত্র টোকেনকে তার ডটে ভাগ করে এবং তিনটির মধ্যে দুটি অংশ base64url ডিকোড করে, যা প্রতিটি শুদ্ধ ক্লায়েন্ট সাইড ডিকোডার করে, তার কী-তে প্রবেশ নেই এবং সেই যাচাই করতে পারে না। এটি আপনাকে বলতে পারে টোকেন কী দাবি করে। এটি আপনাকে বলতে পারে না সেটি বিশ্বাস করা উচিত কিনা।
একটি সুষ্ঠুভাবে গঠিত, পরিষ্কারভাবে ডিকোডেড টোকেন এখনও জালিয়াতি, মেয়াদোত্তীর্ণ,
অথবা এমন একটি কী দ্বারা স্বাক্ষরিত হতে পারে যা কখনই এটি প্রকাশ করার জন্য নির্ধারিত ছিল না। exp এবং nbf মূল্যবান
প্রতিটি ডিকোডিংয়ে যাচাই করার জন্য ঠিক এই কারণে: মেয়াদ শেষের পরে টোকেন,
অথবা এখনও বৈধ নয়, তা অবৈধ তার সিগনেচার সঠিক হোক বা না হোক,
এবং সেই দুটি ফিল্ডকে যে টাইমস্ট্যাম্প তারা প্রতিনিধিত্ব করে তা হিসাবে পড়া
কাঁচা সংখ্যার পরিবর্তে হাতিয়ার দ্বারা ধরা সবচেয়ে দ্রুত উপায়।
এটি কী কাজে আসে
সেই সীমাবদ্ধতা সত্ত্বেও, যাচাই না করে ডিকোড করার প্রকৃত, দৈনিক ব্যবহার আছে: API ইন্টিগ্রেশন ডিবাগ করার সময় একটি অ্যাক্সেস টোকেন কোন স্কোপ দ্বারা প্রকাশিত হয়েছে তা পড়া, যাচাই করা আপনার অ্যাপ যে টোকেন এইমাত্র পেয়েছে তা প্রকৃতপক্ষে মেয়াদোত্তীর্ণ হয়েছে (একটি অস্পষ্ট 401 থেকে অনুমান করার পরিবর্তে), অথবা একটি তৃতীয় পক্ষের টোকেন কী ধারণ করে তা পরিদর্শন করা আপনার সার্ভিসকে বিশ্বাস করতে হবে কিনা তা ঠিক করার আগে। এগুলির কোনোটির জন্যই সিগনিং কী প্রয়োজন নেই, শুধুমাত্র টোকেন নিজেই। JWT Decoder-এ একটি পেস্ট করুন এবং এটি হেডার, নিবন্ধিত দাবি এবং অবশিষ্ট পেলোডকে তাদের নিজস্ব পঙ্ক্তিতে আলাদা করে, একটি মেয়াদোত্তীর্ণ বা এখনও বৈধ নয় টোকেনকে সাথে সাথে ফ্ল্যাগ করে, এবং কাঁচা সিগনেচার বাইট দেখায় কোনো কিছুর সাথে যাচাই করার দাবি না করে।