কীভাবে ব্যবহার করবেন
- টোকেনটি পেস্ট করুন — "Bearer " প্রিফিক্স-সহ বা ছাড়া। তিনটি অংশ আলাদা রঙে চিহ্নিত।
- ডিকোড করা হেডার ও পেলোড পড়ুন। iat, nbf এবং exp claim তারিখ ও আপেক্ষিক সময় হিসেবে দেখানো হবে।
- সিগনেচার যাচাই করতে HS256/384/512-এর শেয়ার করা সিক্রেট লিখুন, অথবা RS, PS, ES ও EdDSA টোকেনের জন্য পাবলিক কী (PEM বা JWK) পেস্ট করুন।
- অন্যত্র প্রয়োজন হলে ডিকোড করা JSON কপি করুন।
অপশনগুলোর ব্যাখ্যা
- হেডার
- টোকেনের মেটাডেটা, সাধারণত alg (সাইনিং অ্যালগরিদম) এবং typ। kid ফিল্ড থেকে বোঝা যায় কোন কী দিয়ে এটি সই করা হয়েছে।
- পেলোড
- টোকেনের claims। নিবন্ধিত claim-এর মধ্যে sub (subject), iss (issuer), aud (audience), iat (issued at), nbf (not before) এবং exp (expiry) রয়েছে; সব সময় Unix seconds-এ দেওয়া হয়।
- সিগনেচার
- হেডার ও পেলোড বদলানো হয়নি, তা প্রমাণ করে। যাচাই করতে সিক্রেট (HMAC) বা ইস্যুকারীর পাবলিক কী (RSA, ECDSA, EdDSA) দরকার।
- সিক্রেটটি Base64
- কিছু পরিষেবা HMAC সিক্রেট Base64-এ এনকোড করে রাখে। আপনার কাছে থাকা সিক্রেটটি যদি এনকোড করা হয়, এটি টিক দিন।
সাধারণ claims
| Claim | অর্থ | উদাহরণ |
|---|---|---|
sub |
টোকেনটি যে ব্যবহারকারীকে বোঝায় (user ID) | "1234567890" |
iss |
যিনি এটি জারি করেছেন | "https://accounts.example.com" |
aud |
টোকেনটি যার জন্য নির্ধারিত | "my-api" |
exp |
মেয়াদ শেষ হওয়ার সময়, Unix seconds | 1790427600 |
iat |
জারি করার সময়, Unix seconds | 1790424000 |
nbf |
এর আগে বৈধ নয়, Unix seconds | 1790424000 |
jti |
পুনরায় ব্যবহার ঠেকাতে ব্যবহৃত অনন্য token ID | "a1b2c3" |
উদাহরণ
টোকেন eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c ডিকোড করলে হেডার {"alg":"HS256","typ":"JWT"} এবং sub, name ও iat-সহ একটি পেলোড পাওয়া যায় (18 জানুয়ারি 2018)। your-256-bit-secret সিক্রেট ব্যবহার করলে সিগনেচার যাচাই সফল হয়।
সচরাচর জিজ্ঞাসিত প্রশ্ন
এখানে প্রোডাকশন JWT পেস্ট করা কি নিরাপদ?
টোকেনটি আপনার ব্রাউজারে JavaScript দিয়ে ডিকোড হয় এবং আপলোড বা লগ করা হয় না। তবু অ্যাক্সেস টোকেনকে পাসওয়ার্ডের মতো বিবেচনা করুন—যার কাছে বৈধ টোকেন আছে, মেয়াদ শেষ হওয়া পর্যন্ত সে এটি ব্যবহার করতে পারে।
JWT ডিকোড করলে কি এটি আসল প্রমাণ হয়?
না। হেডার ও পেলোড শুধু Base64URL-এ এনকোড করা, তাই যে কেউ এগুলো পড়তে বা জাল করতে পারে। সঠিক কী দিয়ে সিগনেচার সফলভাবে যাচাই হলেই বোঝা যায় টোকেনটি প্রত্যাশিত পক্ষ জারি করেছে।
সঠিক সিক্রেট দিয়েও যাচাই ব্যর্থ কেন হয়?
সিক্রেটটি Base64-এ এনকোড করা কি না, শেষে অতিরিক্ত space বা newline আছে কি না এবং হেডারের অ্যালগরিদম ইস্যুকারী যে অ্যালগরিদম ব্যবহার করেন তার সঙ্গে মেলে কি না দেখুন। টোকেনে এক অক্ষর বদলালেও সিগনেচার ভেঙে যায়।
“alg none” বলতে কী বোঝায়?
টোকেনটি দাবি করে যে এতে কোনো সিগনেচার নেই। সার্ভারকে এমন টোকেন প্রত্যাখ্যান করতে হবে, যদি না তারা স্পষ্টভাবে এমন টোকেন প্রত্যাশা করে; এগুলো গ্রহণ করার কারণে বাস্তবে authentication bypass ঘটেছে।
RS256 টোকেনের পাবলিক কী কীভাবে পাব?
পরিচয় প্রদানকারীরা সাধারণত /.well-known/jwks.json-এ JWKS হিসেবে তাদের কী প্রকাশ করেন। টোকেনের হেডারের kid-এর সঙ্গে মেলে এমন কী কপি করে এখানে JWK হিসেবে পেস্ট করুন।
গোপনীয়তা
এই টুলটি পুরোপুরি আপনার ব্রাউজারে চলে। আপনার ফাইল ও লেখা আপনার ডিভাইসেই প্রসেস হয় এবং কখনো আমাদের সার্ভারে আপলোড হয় না।