JWT ডিকোডার
নতুনJSON Web Token ডিকোড করুন, claim পরিদর্শন করুন এবং HS256 সিগনেচার স্থানীয়ভাবে যাচাই করুন।
A JWT is a credential. This decoder, verifier and encoder run 100% in your browser — your token and secret are never uploaded, logged, or sent to any server. Even so, never paste a real production token into a site you don't fully trust.
The signature is a keyed hash of the header and payload. It proves the token wasn't altered — verify it below.
| Claim | Value |
|---|
This payload has no standard claims (iss, sub, exp…). All of its data is shown in the Payload panel above.
Runs entirely in your browser. Nothing is uploaded.
আপনার ব্রাউজারেই যেকোনো JSON Web Token ডিকোড করুন
এই JWT ডিকোডার একটি অস্বচ্ছ eyJ… স্ট্রিংকে মুহূর্তে পড়ার-যোগ্য JSON-এ রূপান্তর করে। একটি JSON Web Token পেস্ট করুন আর এটি ডট বরাবর ভেঙে হেডার ও পেলোড Base64URL-ডিকোড করে এবং দুটি পাশাপাশি প্রিটি-প্রিন্ট করে, আর কাঁচা সিগনেচার আলাদাভাবে দেখায়। এটি একটি অথ ফ্লো ডিবাগ করা, একটি API রেসপন্স থেকে টোকেন পরিদর্শন করা, বা আপনার ব্যাকএন্ড ঠিক কোন ক্লেইম ইস্যু করছে তা নিশ্চিত করার দ্রুততম উপায়।
টোকেনের প্রতিটি অংশ — হেডার, পেলোড এবং সিগনেচার — রঙ দিয়ে চিহ্নিত, তাই header.payload.signature-এর তিনটি অংশ এক নজরে আলাদা করা সহজ। কোনো অ্যাকাউন্ট নেই, কোনো সার্ভার আপলোড নেই, এবং কোনো দৈনিক ডিকোড সীমা নেই।
ক্লেইমগুলো পড়ুন এবং এক নজরে এক্সপায়ারি চেক করুন
ডিকোডারটি RFC 7519-এ সংজ্ঞায়িত স্ট্যান্ডার্ড রেজিস্টার্ড ক্লেইমগুলো — iss, sub, aud, exp, nbf, iat এবং jti — একটি পরিষ্কার টেবিলে হাইলাইট করে প্রতিটির সহজ বাংলা-সমতুল্য অর্থসহ। তিনটি টাইমস্ট্যাম্প ক্লেইম Unix epoch সেকেন্ড, যা ভুল পড়া সহজ, তাই টুলটি এগুলোকে আপনার স্থানীয় তারিখ ও সময়ে রূপান্তর করে এবং 'ইস্যু হয়েছিল ৫ মিনিট আগে' বা 'মেয়াদ শেষ হবে ৫৯ মিনিটে' এর মতো একটি আপেক্ষিক ইঙ্গিত যোগ করে।
সবচেয়ে গুরুত্বপূর্ণ, এটি সেই প্রশ্নের উত্তর দেয় যা আপনি সাধারণত একটি JWT debugger খুলে জিজ্ঞেস করেন: এই টোকেনটি কি এখনও বৈধ? exp ক্লেইমটি বর্তমান সময়ের বিপরীতে চেক করা হয় আর টোকেনটি Valid বা Expired চিহ্নিত হয়, nbf-ও মানা হয়, তাই আপনি এক নজরে দেখতে পারেন একটি মেয়াদোত্তীর্ণ টোকেনই কোনো রিকোয়েস্ট প্রত্যাখ্যানের কারণ কিনা। jwt.io কাঁচা টাইমস্ট্যাম্প দেখায় কিন্তু স্বয়ংক্রিয়ভাবে এক্সপায়ারি স্ট্যাটাস চিহ্নিত করে না — নিজেই হিসাব করতে হয়।
সিগনেচার ভেরিফাই করুন — HS256, RS256 এবং ES256
ডিকোডিং দেখায় একটি টোকেন কী বলছে; ভেরিফিকেশন প্রমাণ করে আপনি সেটি বিশ্বাস করতে পারেন কিনা। এই টুলটি একটি JWT signature verifier-ও: এটি হেডার থেকে অ্যালগরিদম পড়ে আর ব্রাউজারের Web Crypto API দিয়ে স্থানীয়ভাবে সিগনেচার ভেরিফাই করে। HS256, HS384 এবং HS512-এর জন্য আপনি শেয়ার্ড HMAC সিক্রেট দেন; RS256, PS256 এবং ES256 (এবং তাদের 384/512 ভ্যারিয়েন্ট)-এর জন্য আপনি ইস্যুয়ারের পাবলিক কী PEM ফরম্যাটে পেস্ট করেন।
গণিতটি আপনার ডিভাইসে চলে বলে, আপনি নিশ্চিত করতে পারেন একটি টোকেন প্রকৃত — যে কেউ পেলোড পরিবর্তন করেনি — টোকেন, সিক্রেট বা কী কোনো সার্ভারে না পাঠিয়ে। একটি সবুজ চেক মানে সিগনেচার মিলেছে; একটি লাল ক্রস মানে টোকেনটি পরিবর্তিত হয়েছে বা আপনি ভুল কী ব্যবহার করছেন। jwt.io একটি কাস্টম পাবলিক কী দিয়ে RS256 টোকেন ভেরিফাই করতে অ্যাকাউন্ট আপগ্রেড দরকার — এই টুল সেটি ফ্রি করে, সবসময়।
একটি JWT তৈরি ও এনকোডও করুন
উল্টো দিকে যেতে হবে? বিল্ট-ইন JWT encoder আপনাকে শূন্য থেকে একটি টোকেন তৈরি করতে দেয়। হেডার এবং পেলোড JSON হিসেবে এডিট করুন, একটি HMAC অ্যালগরিদম বেছে নিন, একটি সিক্রেট লিখুন, আর এটি একটি সঠিকভাবে সাইন করা header.payload.signature টোকেন তৈরি করে যা একটি রিকোয়েস্ট বা টেস্টে কপি করার জন্য প্রস্তুত। সুবিধাজনক শর্টকাট নতুন iat এবং exp ক্লেইম যোগ করে যাতে আপনার টেস্ট টোকেনে বাস্তবসম্মত টাইমস্ট্যাম্প থাকে।
এটিই UtiloKit-কে একটি সম্মিলিত jwt decoder and encoder বানায় — আপনার API থেকে ফেরত আসা টোকেন পরিদর্শন করুন এবং পাঠানোর জন্য নতুন তৈরি করুন, একই জায়গায়। এটি jwt.io-এর সাথে ডেভেলপাররা যে ওয়ার্কফ্লো ব্যবহার করে তার মতোই, কিন্তু কোনো সার্ভার বা অ্যাকাউন্ট ছাড়া।
এটি jwt.io, token.dev এবং jwtdecode.com-এর সাথে কীভাবে তুলনীয়
jwt.io ওয়েবের সবচেয়ে পরিচিত JWT টুল — Auth0 তৈরি করেছে, ডকুমেন্টেশনে ব্যাপকভাবে লিংক করা হয়, এবং লক্ষ লক্ষ ডেভেলপার বিশ্বাস করেন। এর মূল সীমাবদ্ধতা প্রাইভেসি: jwt.io কিছু কনফিগারেশনে আপনার টোকেন Auth0-এর সার্ভারে পাঠায়, এবং এটি Auth0-এর বাণিজ্যিক পণ্যের সাথে ইন্টিগ্রেট হয়। আপনি যদি একটি প্রতিযোগী অথ সিস্টেমের টোকেন বা একটি গোপনীয় ইন্টারনাল API ডিবাগ করেন, সেটি একটি সমস্যা।
token.dev এবং jwtdecode.com মৌলিক ডিকোডিং কভার করে কিন্তু একটি PEM কী দিয়ে RS256/ES256 সিগনেচার ভেরিফিকেশন সমর্থন করে না, যা Auth0, Google, Microsoft Azure AD, Okta এবং বেশিরভাগ এন্টারপ্রাইজ OIDC প্রোভাইডারের ব্যবহৃত অ্যালগরিদম। আপনাকে শেষে প্রোভাইডারের JWKS এন্ডপয়েন্ট থেকে পাবলিক কী কপি করে কোডে হাতে ভেরিফাই করতে হয়।
এই UtiloKit ডিকোডার এই সবকিছু ব্রাউজারে সামলায়: ডিকোড, এক্সপায়ারি চেক, এবং HS/RS/PS/ES অ্যালগরিদম পরিবারজুড়ে সম্পূর্ণ সিগনেচার ভেরিফিকেশন — ফ্রি, কোনো অ্যাকাউন্ট ছাড়া, কোনো দৈনিক সীমা ছাড়া, এবং আপনার ডিভাইস থেকে কিছু না বেরিয়ে। দৈনন্দিন অথ ডিবাগিং কাজের জন্য এটিই সঠিক টুল।
JWT নিরাপত্তা: টোকেন কী রক্ষা করতে পারে আর কী পারে না
একটি JWT অখণ্ডতার জন্য সাইন করা, গোপনীয়তার জন্য এনক্রিপ্ট করা নয়। যার কাছেই টোকেন থাকে সে পেলোডের প্রতিটি ক্লেইম পড়তে পারে — Base64URL এনকোডিং সহজেই বিপরীত করা যায়, যেমনটা এই ডিকোডার প্রদর্শন করে। তাই পেলোডে শুধু অ-সংবেদনশীল আইডেন্টিফায়ার থাকা উচিত: একটি ইউজার আইডি, রোল, বা ইমেইল। কখনও পাসওয়ার্ড, পেমেন্ট বিবরণ, বা API কী একটি JWT পেলোডে রাখবেন না।
সিগনেচারটি টেম্পারিং থেকে রক্ষা করে: কোনো আক্রমণকারী পেলোডের একটি অক্ষরও পরিবর্তন করলে, সিগনেচার আর মিলবে না আর সঠিক কী দিয়ে ভেরিফাই করা যেকোনো সার্ভার টোকেনটি প্রত্যাখ্যান করবে। ক্লাসিক alg: none আক্রমণ এটি এড়িয়ে যায় দাবি করে যে কোনো অ্যালগরিদম ব্যবহার হচ্ছে না — একটি সুপরিচিত দুর্বলতা (CVE-2015-9235) যা যেকোনো প্রোডাকশন JWT লাইব্রেরির ব্লক করা উচিত। এই টুল none টোকেন চিহ্নিত করে এবং সেগুলোকে বৈধ বলতে অস্বীকার করে।
টোকেনের আয়ুষ্কাল exp দিয়ে ছোট রাখুন, HTTPS-এর মাধ্যমে ট্রান্সমিট করুন, মেমরিতে বা httpOnly কুকিতে সংরক্ষণ করুন (localStorage-এ নয়), এবং প্রতিটি রিকোয়েস্টে সিগনেচার ভেরিফাই করুন। প্রোডাকশনে ডিপ্লয় করার আগে এই বৈশিষ্ট্যগুলো সঠিকভাবে সেট করা আছে কিনা নিশ্চিত করতে এই ফ্রি টুল দিয়ে আপনার টোকেন ডিকোড ও পরিদর্শন করুন।
JWT স্পেসিফিকেশন: RFC 7519 এবং তিনটি অংশ কীভাবে কাজ করে
RFC 7519, IETF কর্তৃক ২০১৫ সালে প্রকাশিত, JSON Web Token-এর জন্য নিয়ামক স্পেসিফিকেশন। এটি একটি টোকেনকে তিনটি Base64URL-এনকোডেড সেগমেন্ট হিসেবে সংজ্ঞায়িত করে ডট দিয়ে পৃথক — header.payload.signature — যেখানে Base64URL হলো Base64-এর একটি URL-নিরাপদ ভার্সন যা +-কে - দিয়ে, /-কে _ দিয়ে প্রতিস্থাপন করে এবং প্যাডিং = অক্ষর সরিয়ে দেয়, যাতে টোকেনটি অতিরিক্ত এনকোডিং ছাড়াই একটি URL কোয়েরি স্ট্রিং-এ এম্বেড করা যায়। হেডারটি একটি JSON অবজেক্ট যা টোকেন টাইপ (typ: "JWT") এবং সাইনিং অ্যালগরিদম (alg) ঘোষণা করে: HS256 (HMAC-SHA-256)-এর মতো সিমেট্রিক অ্যালগরিদম বা RS256 (RSA-SHA-256) বা ES256 (ECDSA-P256)-এর মতো অ্যাসিমেট্রিক।
পেলোড ক্লেইম বহন করে — সাবজেক্ট সম্পর্কে দাবি। RFC 7519 তিনটি বিভাগ আলাদা করে। রেজিস্টার্ড ক্লেইম হলো সাতটি স্ট্যান্ডার্ড ফিল্ড: iss (ইস্যুয়ার — টোকেন কে তৈরি করেছে), sub (সাবজেক্ট — সাধারণত ইউজার আইডি), aud (অডিয়েন্স — উদ্দিষ্ট প্রাপক পরিষেবা), exp (এক্সপায়ারেশন — Unix টাইমস্ট্যাম্প যার পরে টোকেন প্রত্যাখ্যান করতে হবে), nbf (নট-বিফোর — এই সময়ের আগে টোকেন অবৈধ), iat (ইস্যুড-অ্যাট — কখন তৈরি হয়েছিল), এবং jti (রিপ্লে-প্রতিরোধের জন্য একটি অনন্য টোকেন আইডি)। পাবলিক ক্লেইম হলো IANA JSON Web Token Claims Registry-তে নিবন্ধিত নাম যাতে সংঘর্ষ এড়ানো যায়। প্রাইভেট ক্লেইম হলো কাস্টম অ্যাপ্লিকেশন-নির্দিষ্ট ফিল্ড — রোল, টেন্যান্ট আইডি, প্ল্যান টিয়ার, বা আপনার সিস্টেমের প্রয়োজনীয় অন্য যেকোনো ডেটা — ইস্যুয়ার এবং কনজিউমারের মধ্যে সম্মত।
সিগনেচারটি গণনা করা হয় ASCII স্ট্রিং base64url(header) + '.' + base64url(payload)-এর ওপর। HS256-এর জন্য, সার্ভার সেই স্ট্রিংকে একটি শেয়ার্ড সিক্রেট দিয়ে HMAC-SHA-256 ব্যবহার করে হ্যাশ করে। RS256-এর জন্য, সার্ভার একটি প্রাইভেট RSA কী দিয়ে সাইন করে, এবং সংশ্লিষ্ট পাবলিক কী ধারণকারী যেকোনো পক্ষ প্রাইভেট কী না জেনেই সিগনেচার ভেরিফাই করতে পারে। এই অ্যাসিমেট্রিই RS256-কে ফেডারেটেড আইডেন্টিটির জন্য উপযুক্ত করে তোলে: একটি আইডেন্টিটি প্রোভাইডার (IdP) তাদের প্রাইভেট কী দিয়ে টোকেন সাইন করে, আর একটি সংস্থার প্রতিটি API প্রকাশিত পাবলিক কী দিয়ে সেগুলো ভেরিফাই করতে পারে — কোনো সিক্রেট বণ্টনের প্রয়োজন ছাড়াই।
alg:none দুর্বলতা — কেন হেডারকে কখনও বিশ্বাস করবেন না
২০১৫ সালে নিরাপত্তা গবেষক Tim McLean একাধিক JWT লাইব্রেরিকে প্রভাবিত করা একটি গুরুতর ত্রুটি প্রকাশ করেন: অনেক ইমপ্লিমেন্টেশন সিগনেচার কীভাবে ভেরিফাই করবে তা ঠিক করতে টোকেন হেডার থেকে alg ফিল্ড পড়ে। একজন আক্রমণকারী হেডারে "alg": "none" সহ একটি টোকেন তৈরি করতে পারত, সিগনেচার সম্পূর্ণভাবে সরিয়ে ফেলতে পারত, তাদের রোল admin-এ উন্নীত করতে পেলোড পরিবর্তন করতে পারত, আর হেডার ও পেলোড আবার এনকোড করতে পারত। যেসব লাইব্রেরি alg: none ভ্যালুকে সম্মান করত তারা সিগনেচার ভেরিফিকেশন এড়িয়ে যেত — কোনো সিগনেচার উপস্থিত না থাকা সত্ত্বেও ভেরিফিকেশন ধাপটি সফলভাবে সম্পন্ন করত। এটি CVE-2015-9235 হিসেবে ক্যাটালগভুক্ত এবং সেই যুগের Node.js, Python, PHP, Ruby এবং Java JWT লাইব্রেরিকে প্রভাবিত করে।
আক্রমণটির একটি সম্পর্কিত ভ্যারিয়েন্ট RS256 এবং HS256-এর মধ্যে অ্যালগরিদম বিভ্রান্তিকে টার্গেট করেছিল। একটি সার্ভার যদি RS256 আশা করে (অ্যাসিমেট্রিক, একটি পাবলিক কী দিয়ে ভেরিফাই করে) কিন্তু একজন আক্রমণকারী alg: HS256 সহ একটি টোকেন জমা দেয়, কিছু লাইব্রেরি সিমেট্রিক ভেরিফিকেশনে সুইচ করত — পাবলিক কী-কে HMAC সিক্রেট হিসেবে ব্যবহার করে। যেহেতু পাবলিক কী, সংজ্ঞা অনুযায়ী, প্রকাশ্যে জানা, আক্রমণকারী নিজেই জাল টোকেনটি সাইন করতে পারত আর সার্ভার সেটিকে প্রকৃত হিসেবে ভেরিফাই করত। মূল শিক্ষা একই: ভেরিফিকেশনের জন্য ব্যবহৃত অ্যালগরিদম সার্ভার-সাইডে স্থির থাকতে হবে, অবিশ্বাস্য টোকেন হেডার থেকে পড়া যাবে না।
আধুনিক, ভালোভাবে রক্ষণাবেক্ষণকৃত JWT লাইব্রেরি (python-jose, jsonwebtoken ≥ 9, java-jwt, nimbus-jose-jwt) কলারদের প্রত্যাশিত অ্যালগরিদম স্পষ্টভাবে নির্দিষ্ট করতে বাধ্য করে এবং টোকেনের alg ভিন্ন হলে একটি এরর ছুড়ে দেয়। alg: none অপশনটি ডিফল্টভাবে নিষ্ক্রিয় এবং একটি ফ্ল্যাগ দিয়ে ইচ্ছাকৃতভাবে সক্রিয় করতে হয় — প্রাথমিক লাইব্রেরি ডিজাইন থেকে একটি উল্লেখযোগ্য পরিবর্তন। JWT ইমপ্লিমেন্টেশন পর্যালোচনা করার সময়, সবসময় নিশ্চিত করুন যে algorithms (বা সমতুল্য) প্যারামিটার হার্ডকোড করা এবং আসা টোকেন হেডার থেকে নেওয়া হয় না। এই ডিকোডার alg: none টোকেনগুলোকে unverified চিহ্নিত করে ডিবাগিংয়ের সময় ঝুঁকিটি দৃশ্যমান করার জন্য।
JWT বনাম সেশন কুকি — স্টেটলেস টোকেন এবং রিভোকেশন সমস্যা
ঐতিহ্যবাহী ওয়েব প্রমাণীকরণ সেশন কুকি ব্যবহার করে: সার্ভার একটি র্যান্ডম সেশন আইডি তৈরি করে, সেশন স্টেট (ইউজার আইডি, রোল, পছন্দসমূহ) একটি ডাটাবেস বা Redis-এর মতো ক্যাশে সংরক্ষণ করে, এবং শুধু সেশন আইডিটি ব্রাউজারে একটি কুকি হিসেবে পাঠায়। প্রতিটি পরবর্তী রিকোয়েস্টে সার্ভার ইউজারের স্টেট পুনরুদ্ধার করতে স্টোরে সেশন আইডি লুকআপ করে। এই মডেলটি স্টেটফুল: সার্ভার সত্য বজায় রাখে। ইনভ্যালিডেশন তাৎক্ষণিক — সেশন রেকর্ড মুছে ফেলুন আর পরবর্তী রিকোয়েস্টে কুকিটি অকেজো হয়ে যায়। অসুবিধা হলো স্কেলেবিলিটি: প্রতিটি রিকোয়েস্টে একটি ডাটাবেস রাউন্ড-ট্রিপ লাগে, আর অনুভূমিকভাবে স্কেল করা সার্ভারগুলোর একটি শেয়ার্ড সেশন স্টোর প্রয়োজন যাতে যেকোনো নোড যেকোনো সেশন লুকআপ করতে পারে।
JWT স্টেটলেস: টোকেনটিই সেশন। সার্ভার ইউজারের পরিচয় ও অনুমতি সরাসরি একটি ক্রিপ্টোগ্রাফিকভাবে সাইন করা পেলোডে এম্বেড করে এবং ক্লায়েন্টের কাছে পাঠায়। পরবর্তী রিকোয়েস্টে ক্লায়েন্ট টোকেনটি ফেরত পাঠায়, আর সাইনিং কী (বা RS256-এর জন্য পাবলিক কী) জানা যেকোনো সার্ভার ডাটাবেস স্পর্শ না করেই সেটি ভেরিফাই এবং পড়তে পারে। এর মানে মাইক্রোসার্ভিসের একটি বহর একটি কেন্দ্রীয় অথ লুকআপ ছাড়াই স্বাধীনভাবে টোকেন ভ্যালিডেট করতে পারে — ডিস্ট্রিবিউটেড আর্কিটেকচারের জন্য আদর্শ। হরাইজন্টাল স্কেলিং তুচ্ছ হয়ে যায় কারণ সিঙ্ক্রোনাইজ করার মতো কোনো শেয়ার্ড স্টেট নেই।
স্টেটলেসনেসের মূল্য হলো রিভোকেশন সমস্যা। একটি JWT সার্ভারে যাই ঘটুক না কেন তার exp টাইমস্ট্যাম্প পর্যন্ত বৈধ থাকে। একজন ইউজার লগ আউট করলে, তাদের টোকেন বৈধ থেকে যায়। একটি অ্যাডমিন অ্যাকাউন্ট আপস হয়ে ডাটাবেসে ইউজারকে নিষ্ক্রিয় করলেও, তাদের JWT মেয়াদ শেষ না হওয়া পর্যন্ত রিকোয়েস্ট প্রমাণীকরণ করতে থাকে। সাধারণ প্রতিকার হলো অ্যাক্সেস টোকেনের আয়ুষ্কাল ছোট রাখা (১৫ মিনিট একটি সাধারণ ডিফল্ট) দীর্ঘস্থায়ী রিফ্রেশ টোকেন-এর সাথে যা সার্ভার-সাইডে সংরক্ষিত এবং প্রত্যাখ্যান করা যায়, JWT-তে একটি generation বা tokenVersion ক্লেইম যোগ করা এবং প্রতিটি রিকোয়েস্টে ডাটাবেসের বিপরীতে চেক করা (যা একটি ডাটাবেস কল পুনরায় চালু করে কিন্তু শুধু সেই একটি স্কেলারের জন্য), বা উচ্চ-নিরাপত্তা অপারেশনের জন্য একটি টোকেন ব্লকলিস্ট বজায় রাখা যেমন পাসওয়ার্ড রিসেট এবং অধিকার প্রত্যাহার। বেশিরভাগ ভোক্তা অ্যাপ্লিকেশনের জন্য, রিফ্রেশ টোকেন রোটেশনসহ স্বল্পস্থায়ী JWT সঠিক ভারসাম্য তৈরি করে।
OAuth 2.0, OpenID Connect, এবং আধুনিক আইডেন্টিটিতে JWT-এর ভূমিকা
OAuth 2.0 (RFC 6749) একটি অথরাইজেশন ফ্রেমওয়ার্ক — এটি সংজ্ঞায়িত করে কীভাবে একজন ইউজার একটি তৃতীয়-পক্ষের অ্যাপ্লিকেশনকে অন্য পরিষেবায় তাদের ডেটায় সীমিত অ্যাক্সেস দেয়, কিন্তু টোকেন ফরম্যাট সম্পর্কে কিছু বলে না। OAuth অ্যাক্সেস টোকেন অস্বচ্ছ র্যান্ডম স্ট্রিং বা JWT হতে পারে; এটি অথরাইজেশন সার্ভারের ওপর নির্ভর করে। OpenID Connect (OIDC) হলো OAuth 2.0-এর ওপর নির্মিত একটি প্রমাণীকরণ স্তর যা বাধ্যতামূলকভাবে একটি JWT দাবি করে: id_token। ID টোকেন রেজিস্টার্ড OIDC ক্লেইম বহন করে (sub, iss, aud, iat, exp, nonce) এবং ক্লায়েন্ট অ্যাপ্লিকেশন কে প্রমাণীকৃত হয়েছে তা জানতে সেটি ডিকোড করে — ইউজারের পরিচয়। অ্যাক্সেস টোকেনটি অ্যাকশন অনুমোদন করতে রিসোর্স API-তে পাঠানো হয়; ID টোকেনটি পরিচয় প্রতিষ্ঠা করতে রিলাইং পার্টি খায়। এদের মিশিয়ে ফেলা (একটি API-তে একটি ID টোকেন পাঠানো, বা ইউজার প্রোফাইল ডেটা আশা করে একটি অ্যাক্সেস টোকেন ডিকোড করা) সূক্ষ্ম অথ বাগের একটি সাধারণ উৎস।
সব প্রধান আইডেন্টিটি প্রোভাইডার OIDC ব্যবহার করে এবং RS256 বা ES256 JWT ইস্যু করে: Google Identity, Microsoft Azure AD, Auth0, Okta, Keycloak, AWS Cognito, Firebase Authentication, এবং Supabase Auth। প্রতিটি একটি JWKS (JSON Web Key Set) এন্ডপয়েন্ট প্রকাশ করে — একটি পাবলিক URL যা একটি স্ট্যান্ডার্ড JSON ফরম্যাটে পাবলিক কী-গুলোর বর্তমান সেট ফেরত দেয়। JWT হেডার একটি kid (Key ID) ক্লেইম বহন করে যা চিহ্নিত করে JWKS-এর কোন কী টোকেন সাইন করতে ব্যবহৃত হয়েছিল। একটি ভেরিফাইং পরিষেবা JWKS ফেচ করে, kid দিয়ে মিলে যাওয়া কী খুঁজে পায়, এবং সিগনেচার ভেরিফাই করে। এই কী রোটেশন মেকানিজম প্রোভাইডারদের সব বিদ্যমান টোকেন ইনভ্যালিড না করে তাদের সাইনিং কী ঘোরাতে দেয় — পুরনো কীটি JWKS-এ থেকে যায় বিদ্যমান টোকেন মেয়াদ শেষ না হওয়া পর্যন্ত, আর নতুন টোকেন নতুন কী দিয়ে সাইন করা হয়।
OAuth 2.0 বিভিন্ন ব্যবহারের ক্ষেত্রের জন্য বেশ কিছু গ্র্যান্ট ফ্লো সংজ্ঞায়িত করে। Authorization Code Flow সার্ভার-সাইড ওয়েব অ্যাপ্লিকেশনে ব্যবহৃত হয় — সার্ভার একটি স্বল্পস্থায়ী কোড টোকেনের বিনিময়ে করে, অ্যাক্সেস টোকেনকে ব্রাউজার থেকে দূরে রেখে। Authorization Code with PKCE (Proof Key for Code Exchange, RFC 7636) এটিকে সিঙ্গেল-পেজ অ্যাপ্লিকেশন এবং মোবাইল অ্যাপে প্রসারিত করে, অথরাইজেশন কোড ইন্টারসেপশন আক্রমণ প্রতিরোধ করতে একটি ক্রিপ্টোগ্রাফিক চ্যালেঞ্জ-রেসপন্স যোগ করে; OAuth 2.1 সব পাবলিক ক্লায়েন্টের জন্য PKCE বাধ্যতামূলক করে। Client Credentials Flow মেশিন-টু-মেশিন প্রমাণীকরণের জন্য — একটি পরিষেবা সরাসরি একটি ক্লায়েন্ট আইডি ও সিক্রেট দিয়ে প্রমাণীকরণ করে এবং পরিষেবা-স্তরের অনুমতিসহ একটি অ্যাক্সেস টোকেন পায়, কোনো ইউজার জড়িত ছাড়াই। কোন ফ্লো একটি টোকেন ইস্যু করেছিল — এবং তাই কোন ক্লেইম আশা করা উচিত — তা বোঝা সিস্টেমের বিভিন্ন অংশের JWT ডিকোড ও ডিবাগ করার সময় অপরিহার্য প্রসঙ্গ।
Frequently asked questions
JWT (JSON Web Token) কী?
একটি JWT হলো দুই পক্ষের মধ্যে সাইন করা তথ্য বহন করার একটি কমপ্যাক্ট, URL-নিরাপদ উপায় — বেশিরভাগ ক্ষেত্রে একটি লগইন টোকেন। এটি ডট দিয়ে যুক্ত তিনটি Base64URL অংশ: header.payload.signature। হেডার সাইনিং অ্যালগরিদমের নাম দেয়, পেলোড ক্লেইম (ডেটা) ধারণ করে, আর সিগনেচার প্রাপককে নিশ্চিত করতে দেয় যে টোকেনটি বিকৃত করা হয়নি। JWT OAuth 2.0, OpenID Connect, Auth0, Firebase, Supabase, AWS Cognito এবং বেশিরভাগ আধুনিক প্রমাণীকরণ সিস্টেমে ব্যবহৃত হয়। এগুলো অনেক আর্কিটেকচারে সেশন কুকিকে প্রতিস্থাপিত করেছে কারণ এগুলো স্টেটলেস — সার্ভারকে সেশন ডেটা সংরক্ষণের দরকার নেই।
আমি কীভাবে একটি JWT ডিকোড করব?
টোকেনটিকে দুটি ডট বরাবর ভাগ করুন এবং প্রথম দুটি অংশ Base64URL-ডিকোড করুন। হেডার এবং পেলোড ডিকোড করার পর সাধারণ JSON হয়ে যায়; তৃতীয় অংশ (সিগনেচার) বাইনারি থেকে যায়। এই টুলটি তাৎক্ষণিকভাবে এটি করে — টোকেনটি পেস্ট করুন আর ডিকোড করা হেডার ও পেলোড প্রিটি-প্রিন্ট করা অবস্থায় দেখা যায়, সিগনেচারটি আলাদাভাবে দেখানো হয়। কোথাও কিছু পাঠানো হয় না; ডিকোডিং আপনার ব্রাউজারে চলে। একটি JWT ডিকোড করতে সিক্রেট বা প্রাইভেট কী প্রয়োজন হয় না — ডিকোডিংয়ের জন্য শুধু টোকেনটিই দরকার।
অনলাইনে JWT ডিকোড করা কি নিরাপদ?
এই টুল দিয়ে, হ্যাঁ — প্রতিটি বাইট আপনার ব্রাউজারে জাভাস্ক্রিপ্ট দিয়ে স্থানীয়ভাবে ডিকোড হয়, এবং আপনার টোকেন কখনও কোনো সার্ভার, লগ, বা নেটওয়ার্ক রিকোয়েস্ট স্পর্শ করে না। jwt.io, সবচেয়ে ব্যাপকভাবে পরিচিত অনলাইন JWT টুল, Auth0 (এখন Okta) দ্বারা পরিচালিত এবং কিছু ব্যবহার মোডে আপনার টোকেন তাদের সার্ভারে পাঠায়। এই টুলটি সবকিছু ক্লায়েন্ট-সাইডে প্রসেস করে কোনো ব্যাকএন্ড এবং টোকেন কনটেন্টে কোনো অ্যানালিটিক্স ট্র্যাকিং ছাড়াই। তবুও, একটি JWT এখনও একটি ক্রেডেনশিয়াল: আপনি বিশ্বাস করেন না এমন কোনো ওয়েবসাইটে একটি লাইভ প্রোডাকশন টোকেন পেস্ট করবেন না, কারণ যে কেউ এটি ক্যাপচার করলে তার মেয়াদ শেষ হওয়া পর্যন্ত আপনার ছদ্মবেশ ধারণ করতে পারে।
একটি JWT-এর ভেতরে কী থাকে?
তিনটি অংশ। হেডারটি JSON যা টাইপ এবং সাইনিং অ্যালগরিদম বর্ণনা করে, যেমন {"alg":"HS256","typ":"JWT"}। পেলোডটি JSON যা ক্লেইম ধারণ করে — উভয় রেজিস্টার্ড (sub, exp, iat…) এবং যেকোনো কাস্টম ডেটা যেমন রোল বা একটি ইউজার আইডি। সিগনেচারটি হেডার এবং পেলোডের একটি কীযুক্ত হ্যাশ যা প্রমাণ করে সেগুলো পরিবর্তিত হয়নি। শুধু সিগনেচারের জন্যই একটি সিক্রেট বা কী প্রয়োজন; হেডার এবং পেলোড শুধু Base64URL-এনকোডেড, এনক্রিপ্টেড নয়। টোকেন থাকা যে কেউ পেলোডটি প্লেইন টেক্সটে পড়তে পারে, তাই পাসওয়ার্ড বা সিক্রেট কখনও এতে রাখবেন না।
স্ট্যান্ডার্ড JWT ক্লেইমগুলো কী?
RFC 7519 সাতটি রেজিস্টার্ড ক্লেইম সংজ্ঞায়িত করে: iss (ইস্যুয়ার), sub (সাবজেক্ট — সাধারণত ইউজার আইডি), aud (অডিয়েন্স — টোকেন কার জন্য), exp (এক্সপায়ারেশন সময়), nbf (নট-বিফোর সময়), iat (ইস্যুড-অ্যাট সময়), এবং jti (একটি অনন্য টোকেন আইডি)। তিনটি সময়ের ক্লেইম সেকেন্ডে Unix টাইমস্ট্যাম্প — এই টুল সেগুলোকে আপনার স্থানীয় তারিখ ও সময়ে রূপান্তর করে এবং দেখায় কতক্ষণ আগে বা কতটা আগে। ইমেইল, রোল, বা পারমিশনের মতো কাস্টম ক্লেইম RFC-এর বাইরে কিন্তু Auth0, Firebase এবং Supabase JWT-তে সাধারণ।
একটি JWT মেয়াদোত্তীর্ণ কিনা কীভাবে চেক করব?
exp ক্লেইমটি পড়ুন — সেকেন্ডে একটি Unix টাইমস্ট্যাম্প। exp বর্তমান সময়ের আগে হলে, টোকেনটি মেয়াদোত্তীর্ণ এবং প্রত্যাখ্যান করা উচিত। এই ডিকোডার exp-কে একটি পড়ার-যোগ্য তারিখে রূপান্তর করে, 'মেয়াদ শেষ হয়েছে ৩ ঘণ্টা আগে' বা 'মেয়াদ শেষ হবে ৫৯ মিনিটে' এর মতো একটি আপেক্ষিক সময় দেখায়, এবং স্বয়ংক্রিয়ভাবে টোকেনটি Valid বা Expired চিহ্নিত করে, তাই আপনাকে হাতে epoch সেকেন্ড রূপান্তর করতে হয় না। এটিই সবচেয়ে সাধারণ কারণ যে জন্য একজন ডেভেলপার একটি JWT টুল খোলে: একটি মেয়াদোত্তীর্ণ টোকেন কি ৪০১ Unauthorized রেসপন্সের কারণ তা নিশ্চিত করতে। jwt.io কাঁচা টাইমস্ট্যাম্প দেখায় কিন্তু স্বয়ংক্রিয়ভাবে এক্সপায়ারি স্ট্যাটাস চিহ্নিত করে না।
আমি কীভাবে একটি JWT সিগনেচার ভেরিফাই করব?
alg পড়তে হেডার ডিকোড করুন, তারপর header.payload-এর ওপর সিগনেচার পুনর্গণনা করে তুলনা করুন। HS256/384/512-এর জন্য আপনার শেয়ার্ড সিক্রেট প্রয়োজন; RS256, PS256 বা ES256-এর জন্য আপনার ইস্যুয়ারের PEM ফরম্যাটে পাবলিক কী প্রয়োজন। এই টুল Web Crypto API দিয়ে স্থানীয়ভাবে এগুলো সব ভেরিফাই করে — মিলে যাওয়া অ্যালগরিদম বেছে নিন, সিক্রেট বা পাবলিক কী পেস্ট করুন, আর এটি রিপোর্ট করবে সিগনেচারটি প্রকৃত কিনা। jwt.io-ও সিগনেচার ভেরিফাই করে কিন্তু কিছু কনফিগারেশনে আপনার টোকেন ও কী Auth0-এর সার্ভারে পাঠায় — এই টুল কখনও তা করে না।
HS256 এবং RS256-এর মধ্যে পার্থক্য কী?
HS256 সিমেট্রিক: একটি শেয়ার্ড সিক্রেট উভয়ই সাইন এবং ভেরিফাই করে, তাই যে কেউ ভেরিফাই করতে পারে সে টোকেন জালও তৈরি করতে পারে — একটি একক বিশ্বস্ত পরিষেবার মধ্যে ঠিক আছে যেখানে উভয় পক্ষ আপনার নিয়ন্ত্রণে। RS256 (এবং ES256) অ্যাসিমেট্রিক: একটি প্রাইভেট কী সাইন করে আর একটি আলাদা পাবলিক কী ভেরিফাই করে। আপনি সাইনিং কী কখনও প্রকাশ না করেই টোকেন চেক করতে যেকোনো সংখ্যক ক্লায়েন্টকে পাবলিক কী দিতে পারেন, যে কারণে RS256 Auth0, Okta, Google এবং Microsoft Azure AD-এর মতো OAuth/OIDC প্রোভাইডারের ডিফল্ট। আপনি যদি একটি বাহ্যিক IdP থেকে টোকেন ভ্যালিডেট করা একটি মাইক্রোসার্ভিস তৈরি করেন, আপনি প্রায় সবসময় RS256 নিয়ে কাজ করবেন।
আমি কি সিক্রেট ছাড়া একটি JWT ডিকোড করতে পারি?
হ্যাঁ। ডিকোডিং শুধু Base64URL-এনকোডেড হেডার এবং পেলোড পড়ে, যাতে কোনো কী-ই লাগে না — এই কারণেই কখনও JWT পেলোডে সিক্রেট রাখা উচিত নয়। সিক্রেট বা পাবলিক কী শুধু সিগনেচার ভেরিফাই করতে দরকার, অর্থাৎ প্রমাণ করতে টোকেনটি প্রকৃত এবং অপরিবর্তিত। ডিকোডিং আপনাকে বলে একটি টোকেন কী দাবি করছে; ভেরিফাইং বলে সেটি বিশ্বাস করবেন কিনা। এই পার্থক্যটি অনেক ডেভেলপারকে বিভ্রান্ত করে যারা মনে করেন যেহেতু টোকেন 'এনক্রিপ্টেড মনে হয়', পড়তে একটি কী দরকার — আসলে দরকার নেই।
একটি JWT ডিকোড করা কি সংবেদনশীল ডেটা প্রকাশ করে?
হতে পারে। পেলোডটি Base64URL-এনকোডেড, এনক্রিপ্টেড নয় — টোকেন থাকা যে কেউ প্রায় এক সেকেন্ডে প্লেইন টেক্সটে প্রতিটি ক্লেইম পড়তে পারে। তাই কখনও পাসওয়ার্ড, API কী, ক্রেডিট কার্ড নম্বর, বা প্রাইভেট ব্যক্তিগত ডেটা একটি JWT পেলোডে সংরক্ষণ করবেন না। শুধু অ-সংবেদনশীল আইডেন্টিফায়ার (ইউজার আইডি, রোল, ইমেইল) সেখানে রাখুন, exp দিয়ে টোকেনের আয়ুষ্কাল ছোট রাখুন, এবং HTTPS ব্যবহার করুন যাতে ট্রানজিটে টোকেন ইন্টারসেপ্ট না হয়। JWT অখণ্ডতার জন্য সাইন করা, গোপনীয়তার জন্য এনক্রিপ্টেড নয় — পেলোড গোপন রাখা দরকার হলে, সাধারণ JWT-এর বদলে JWE (JSON Web Encryption) ব্যবহার করুন।
আমি কীভাবে একটি JWT তৈরি বা এনকোড করব?
Encode ট্যাবে সুইচ করুন, হেডার এবং পেলোড JSON এডিট করুন, HS256/384/512 বেছে নিন, একটি সিক্রেট লিখুন, আর টুলটি Web Crypto দিয়ে HMAC-এর মাধ্যমে টোকেনটি সাইন করে এবং একটি কপি-করার-জন্য-প্রস্তুত header.payload.signature স্ট্রিং আউটপুট দেয়। দ্রুত বাটন iat (এখন ইস্যু) এবং exp (এক ঘণ্টা পর) যোগ করে দেয়। এখানে সবকিছুর মতোই, সাইনিং সম্পূর্ণভাবে আপনার ব্রাউজারে হয় — আপনার সিক্রেট কখনও পেজ ছেড়ে যায় না। এটি উপকারী ডেভেলপমেন্টে টেস্ট টোকেন জেনারেট করার জন্য যখন আপনার অথ সার্ভার উপলব্ধ নয়, বা একটি নির্দিষ্ট ক্লেইম কনফিগারেশন ডিবাগ করার সময়।
আমার JWT কেন অবৈধ?
সাধারণ কারণগুলো: স্ট্রিংটি তিনটি ডট-পৃথক অংশ নয় (একটি কপি-পেস্ট সিগনেচার কেটে দিয়েছিল), হেডার বা পেলোড বৈধ Base64URL JSON নয় (প্রায়ই একটি ভুলবশত স্পেস, নিউলাইন, বা টার্মিনাল থেকে পেস্ট করার সময় বিকৃত হওয়া একটি কোট-অক্ষর), alg আপনি যে কী দিয়ে ভেরিফাই করছেন তার সাথে মেলে না, বা exp পার হয়ে গেছে তাই টোকেনটি মেয়াদোত্তীর্ণ। এই ডিকোডার শুধু 'invalid token' না বলে ঠিক কোনটা তা চিহ্নিত করে। এটি টোকেনের কোন নির্দিষ্ট অংশ পার্স করতে ব্যর্থ হয়েছে তাও হাইলাইট করে, যা jwt.io-এর জেনেরিক এরর মেসেজের চেয়ে ডিবাগিং দ্রুত করে।
এই JWT ডিকোডার কোন কোন অ্যালগরিদম ভেরিফাই করতে পারে?
সিগনেচার ভেরিফিকেশন সম্পূর্ণ মূলধারা সেট সমর্থন করে: HMAC (HS256, HS384, HS512) একটি শেয়ার্ড সিক্রেট সহ, RSA (RS256/384/512 এবং PS256/384/512) একটি PEM পাবলিক কী সহ, এবং ECDSA (ES256, ES384, ES512) একটি PEM পাবলিক কী সহ। এটি ব্রাউজারের নেটিভ Web Crypto API ব্যবহার করে, তাই ভেরিফিকেশন প্রকৃত ক্রিপ্টোগ্রাফি যা আপনার হার্ডওয়্যারে চলে — কোনো সরলীকৃত লুকআপ নয়। এটি Auth0, Okta, Firebase, Supabase, AWS Cognito এবং Azure AD-এর ব্যবহৃত সব অ্যালগরিদম কভার করে, আর ফ্রি টিয়ার কোনো অ্যাকাউন্ট আপগ্রেড ছাড়াই সবগুলো ভেরিফাই করে।
'alg: none' মানে কী এবং এটা কি নিরাপদ?
alg: none মানে টোকেনটি সাইন করা নয় — চেক করার জন্য কোনো সিগনেচার নেই। এটি স্পেকে সেসব টোকেনের জন্য বিদ্যমান যা ইতিমধ্যে অন্যভাবে সুরক্ষিত (যেমন একটি TLS-প্রমাণীকৃত সেশনের ভেতরে প্রেরিত হচ্ছে), কিন্তু এটি একটি ক্লাসিক আক্রমণ ভেক্টর: একটি সার্ভার 'none' গ্রহণ করতে প্রতারিত হলে, একজন আক্রমণকারী JSON এডিট করে এবং কোনো কী ছাড়াই পুনরায় এনকোড করে যেকোনো পেলোড জাল করতে পারে। এটিই CVE-2015-9235। কখনও প্রমাণীকরণের জন্য একটি সাইন-না-করা JWT বিশ্বাস করবেন না। এই টুল none টোকেন চিহ্নিত করে এবং সেগুলোকে ভেরিফাইড বলতে অস্বীকার করে।
এটি jwt.io-এর সাথে কীভাবে তুলনীয়?
jwt.io Auth0 (এখন Okta)-এর রেফারেন্স টুল এবং ব্যাপকভাবে বিশ্বস্ত, কিন্তু এর দুটি অসুবিধা রয়েছে: এটি কিছু কনফিগারেশনে আপনার টোকেন Auth0-এর ব্যাকএন্ডে পাঠায়, এবং একটি PEM কী দিয়ে RS256/ES256 টোকেন ভেরিফাই করতে একটি অ্যাকাউন্ট আপগ্রেড প্রয়োজন। এই টুল সব স্ট্যান্ডার্ড অ্যালগরিদম (HS256, RS256, ES256, এবং তাদের 384/512 ভ্যারিয়েন্ট) সম্পূর্ণভাবে আপনার ব্রাউজারে ভেরিফাই করে কোনো সার্ভার জড়িত ছাড়া এবং কোনো অ্যাকাউন্ট ছাড়া। এটি টাইমস্ট্যাম্প ক্লেইমও পড়ার-যোগ্য তারিখে রূপান্তর করে এবং স্বয়ংক্রিয়ভাবে মেয়াদোত্তীর্ণ টোকেন চিহ্নিত করে — এমন ধাপ যা jwt.io-তে হাতে করতে হয়।
এই টুল কি আইফোন এবং অ্যান্ড্রয়েডে কাজ করে?
হ্যাঁ। ডিকোডার এবং এনকোডার উভয়ই যেকোনো আধুনিক মোবাইল ব্রাউজারে চলে — আইফোনে Safari, অ্যান্ড্রয়েডে Chrome, Firefox Mobile এবং Samsung Internet। আপনার JWT ইনপুট ফিল্ডে পেস্ট করুন আর ডিকোড করা হেডার, পেলোড, এবং ক্লেইম টেবিল সঙ্গে সঙ্গে স্ক্রিনে দেখা যাবে। ইন্টারফেসটি ছোট স্ক্রিনের জন্য খাপ খায় যাতে কোনো অনুভূমিক স্ক্রল ছাড়াই ক্লেইম পড়া যায়। কোনো অ্যাপ ডাউনলোডের দরকার নেই, আর আপনার টোকেন পুরো সময় আপনার ডিভাইসেই থাকে।
Related tools
সব টুল দেখুন
নতুন ক্রেডিট কার্ড ভ্যালিডেটর
Luhn অ্যালগরিদম দিয়ে কার্ড নম্বর যাচাই করুন এবং এর ব্র্যান্ড শনাক্ত করুন।
নতুন পাসফ্রেজ জেনারেটর
একটি নিরাপদ র্যান্ডম জেনারেটর দিয়ে মনে রাখার মতো, শব্দ-ভিত্তিক পাসফ্রেজ তৈরি করুন।
হ্যাশ জেনারেটর
MD5, SHA-1 ও SHA-256 হ্যাশ স্থানীয়ভাবে গণনা করুন।
নতুন পাসওয়ার্ড শক্তি পরীক্ষক
এনট্রপি, ক্র্যাক-সময়ের আনুমানিক হিসাব ও পরামর্শ সহ পাসওয়ার্ডের শক্তি পরীক্ষা করুন।
নতুন টেক্সট এনক্রিপ্ট / ডিক্রিপ্ট করুন
পাসফ্রেজ দিয়ে বার্তা AES-256 এনক্রিপ্ট ও ডিক্রিপ্ট করুন — সম্পূর্ণ আপনার ব্রাউজারে।
নতুন Tax Bracket Calculator
See your 2024 US federal income tax bracket, effective rate and marginal rate — for any filing status.