১৭ অক্টো, ২০২৫·5 মিনিট
JWT কী? JSON Web Token-এর স্পষ্ট গাইড
জেনে নিন JWT (JSON Web Token) কী, এর তিনটি অংশ কিভাবে কাজ করে, কোথায় ব্যবহার হয়, এবং টোকেন সংক্রান্ত সাধারণ নিরাপত্তা টিপস।
জেনে নিন JWT (JSON Web Token) কী, এর তিনটি অংশ কিভাবে কাজ করে, কোথায় ব্যবহার হয়, এবং টোকেন সংক্রান্ত সাধারণ নিরাপত্তা টিপস।
একটি JWT (JSON Web Token) হল একটি কমপ্যাক্ট, URL-সুরক্ষিত স্ট্রিং যা একটি সেট তথ্য (সাধারণত ব্যবহারকারী বা সেশনের সম্পর্কে) নির্দেশ করে এবং সিস্টেমগুলোর মধ্যে পাঠানো যায়। আপনি এটি সাধারনত eyJ... দিয়ে শুরু হওয়া একটি লম্বা মান হিসেবে পাবেন, এবং এটি HTTP হেডারে পাঠানো হয় যেমন Authorization: Bearer <token>।
পৌরাণিক লগইনে প্রায়ই সার্ভার সেশন ব্যবহার হয়: সাইন ইন করার পর সার্ভার সেশন ডেটা সংরক্ষণ করে এবং ব্রাউজারকে একটি সেশন আইডি কুকি দেয়। প্রতিটি অনুরোধের সাথে সেই কুকি যায় এবং সার্ভার সেশন দেখাই করে।
টোকেন-ভিত্তিক প্রমাণীকরণ-এ সার্ভার প্রতিটি ব্যবহারকারীর অনুরোধের জন্য স্টেট রাখার প্রয়োজন টেনে নেয় না। ক্লায়েন্ট একটি টোকেন (যেমন JWT) ধরে রাখে এবং API কলগুলোর সাথে এটিকে পাঠায়। এটা API-গুলোর জন্য জনপ্রিয় কারণ:
গুরুত্বপূর্ণ নুয়ান্স: “স্টেটলেস” মানেই “কখনও সার্ভার-সাইড যাচাই করা হবে না” নয়। অনেক বাস্তব সিস্টেম এখনও ব্যবহারকারী স্থিতি, কী রোটেশন বা প্রত্যাহার মেকানিজম অনুযায়ী টোকেন যাচাই করে।
JWT সাধারণত প্রমাণীকরণের প্রমাণ বহন করে (তুমি সাইন ইন) এবং বেসিক অনুমোদন ইঙ্গিত (রোল, পারমিশন, স্কোপ) দেয়—কিন্তু সার্ভারকে এখনও অনুমোদন নিয়ম বাস্তবায়ন করতে হবে।
আপনি সাধারণত JWT-কে অ্যাক্সেস টোকেন হিসেবে দেখতে পাবেন:
একটি JWT হল তিনটি অংশের একটি কমপ্যাক্ট স্ট্রিং, প্রতিটি base64url-এ এনকোডেড এবং ডট দিয়ে পৃথক:
header.payload.signature
উদাহরণ (সংশিপ্ত):
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwiaWF0IjoxNzAwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c…
হেডার টোকেনটি কীভাবে তৈরি করা হয়েছে তা বর্ণনা করে—সবচেয়ে গুরুত্বপূর্ণ হলো সাই닝 অ্যালগরিদম (যেমন HS256, RS256/ES256) এবং টোকেন টাইপ।
সাধারণ ফিল্ড:
typ: প্রায়ই "JWT" (অনেকখানি উপেক্ষিত)alg: ব্যবহৃত সাইনের অ্যালগরিদমkid: কী আইডেন্টিফায়ার, কী রোটেশনের সময় ভেরিফায়ারকে সঠিক কী পেতে সাহায্য করেসুরক্ষা নোট: হেডারকে অন্ধভাবে বিশ্বাস করবেন না। আপনি যে অ্যালগরিদম ব্যবহার করেন সেগুলোর একটি allowlist প্রয়োগ করুন, এবং alg: "none" গ্রহণ করবেন না।
পেলোড-এ ব্যবহারকারী ও টোকেন প্রসঙ্গ সম্পর্কিত “ক্লেইম” থাকে: কার জন্য, কার দ্বারা ইস্যু হয়েছে, এবং কখন মেয়াদ শেষ হবে ইত্যাদি।
গুরুত্বপূর্ণ: JWT স্বয়ংক্রিয়ভাবে এনক্রিপ্ট করা হয় না। Base64url এনকোডিং টোকেনটিকে URL-সুরক্ষিত করে; এটি ডেটা লুকায় না।
যেহেতু যে কেউ টোকেন পেলে হেডার ও পেলোড ডিকোড করে পড়তে পারে, তাই সিক্রেট (পাসওয়ার্ড, API কী) বা সংবেদনশীল ব্যক্তিগত তথ্য JWT-এ রাখা উচিত নয়।
সিগনেচার তৈরি করা হয় হেডার + পেলোড সাইন করে:
সিগনেচার ইন্টিগ্রিটি নিশ্চিত করে: এটি সার্ভারকে বলে দেয় টোকেন পরিবর্তিত হয়নি এবং বিশ্বাসযোগ্য সাইজার দ্বারা ইস্যু হয়েছে। এটি গোপনীয়তা দেয় না।
কারণ JWT প্রতি অনুরোধে হেডার ও পেলোড বহন করে, বড় টোকেন মানে বেশি ব্যান্ডউইডথ ও ওভারহেড। ক্লেইম সংক্ষেপে রাখুন এবং ভারী ডেটার পরিবর্তে আইডেন্টিফায়ার ব্যবহার করুন।
ক্লেইম সাধারণত দুই ভাগে পড়ে: রেজিস্টার্ড (স্ট্যান্ডার্ড নাম) এবং কাস্টম (আপনার অ্যাপের ফিল্ড)।
iss (issuer): কে টোকেন তৈরি করেছেsub (subject): টোকেন কার সম্পর্কে (সাধারণত একটি ব্যবহারকারী আইডি)aud (audience): টোকেন কার জন্য নির্ধারিত (যেমন একটি নির্দিষ্ট API)exp (expiration time): কখন টোকেন গ্রহণ করা বন্ধ করা হবেiat (issued at): কখন টোকেন তৈরি হয়েছেnbf (not before): টোকেন এটি সময়ের আগে গ্রহণ করা উচিত নয়প্রাপ্ত পরিষেবাটি যদি অনুমোদনের সিদ্ধান্ত নিতে সত্যিকারের প্রয়োজন নেই, তাহলে অতিরিক্ত ক্লেইম যোগ করবেন না।
ভালো উদাহরণ:
user_id)অতরিক্ত প্রোফাইল ডেটা এড়ান — এগুলো টোকেন বেঁধে দেয়, দ্রুত পুরনো হয়, এবং টোকেন ফাঁস হলে প্রভাব বাড়ায়।
কেননা পেলোড পড়া যায়, তাই রাখবেন না:
যদি সংবেদনশীল তথ্য প্রয়োজন হয়, সার্ভার-সাইডে তা সংরক্ষণ করুন এবং শুধুমাত্র একটি রেফারেন্স (যেমন একটি আইডি) টোকেনে রাখুন—অথবা প্রয়োজনে এনক্রিপ্টেড টোকেন ফরম্যাট (JWE) ব্যবহার করুন।
সাইন করা মানে এনক্রিপ্ট করা নয়।
টোকেন ইস্যু করার সময় সার্ভার এনকোড করা হেডার + পেলোড সাইন করে। পরে যখন টোকেন উপস্থাপন করা হয়, সার্ভার পুনরায় সিগনেচার হিসাব করে এবং মিলায়। যদি কেউ এক অক্ষরও বদলে দেয় (যেমন "role":"user" থেকে "role":"admin"), যাচাই ব্যর্থ হয় এবং টোকেন প্রত্যাখ্যাত হয়।
JWT একটি টোকেন ফরম্যাট। OAuth 2.0 এবং OpenID Connect (OIDC) এমন প্রোটোকল যা অ্যাপস কীভাবে টোকেন অনুরোধ, ইস্যু ও ব্যবহার করবে তা বর্ণনা করে।
OAuth 2.0 মূলত অনুমোদন নিয়ে কাজ করে: একটি অ্যাপকে ব্যবহারকারীর পাসওয়ার্ড শেয়ার না করে API-তে অ্যাক্সেস দেওয়া।
অ্যাক্সেস টোকেন সাধারণত সংক্ষিপ্ত-জীবী (মিনিট পর্যায়ে)। সংক্ষিপ্ত মেয়াদ টোকেন ফাঁস হলে ক্ষতি সীমাবদ্ধ করে।
OIDC OAuth 2.0-কে উপরে প্রমাণীকরণ যোগ করে এবং একটি ID টোকেন পরিচয় করায়, যা বেশিরভাগ ক্ষেত্রে JWT।
একটি গুরুত্বপূর্ণ নিয়ম: ID টোকেন API কল করতে ব্যবহার করবেন না।
আরও প্র্যাকটিক্যাল ফ্লো জানতে দেখুন /blog/jwt-authentication-flow.
একটি টিপিক্যাল ফ্লো দেখতে এমন:
ব্যবহারকারী সাইন ইন করে (ইমেইল/পাসওয়ার্ড, SSO ইত্যাদি)। সফল হলে সার্ভার একটি JWT তৈরি করে (সাধারণত একটি অ্যাক্সেস টোকেন) যেখানে বিষয় ও মেয়াদ শেষের মতো অপরিহার্য ক্লেইম থাকে।
সার্ভার টোকেন সাইন করে এবং ক্লায়েন্টকে (ওয়েব অ্যাপ, মোবাইল অ্যাপ, বা অন্য সার্ভিস) ফেরত দেয়।
প্রটেকটেড এন্ডপয়েন্টের জন্য ক্লায়েন্ট Authorization হেডারে JWT অন্তর্ভুক্ত করে:
Authorization: Bearer <JWT>
অনুরোধ পরিবেশন করার আগে API সাধারণত পরীক্ষা করে:
exp (মেয়াদ শেষ হয়নি)iss (আশা করা issuer)aud (এই API-র জন্য টোকেনটি উদ্দেশ্যপ্রণোদিত)যদি সব চেক পাস করে, API ব্যবহারকারীকে প্রমাণিত হিসেবে গ্রহণ করে এবং অনুমোদনের নিয়ম (যেমন রেকর্ড-স্তরের অনুমতি) প্রয়োগ করে।
সিস্টেমের ঘড়ি বিচ্যুতির কারণে, অনেক সিস্টেম টাইম-বেসড ক্লেইম যাচাই করার সময় ছোট clock skew মঞ্জুর করে (যেমন exp বা nbf)। স্কিউ ছোট রাখুন যাতে টোকেনের বৈধতা অনিচ্ছাকৃতভাবে বাড়ে না।
সংরক্ষণ পছন্দ কী ধরনের আক্রমণকারী টোকেনটি চুরি করতে পারে এবং কত সহজে তারা টোকেন পুনরায় ব্যবহার করতে পারে তা বদলে দেয়।
ইন-মেমোরি স্টোরেজ (SPA-এর জন্য প্রায়শই পরামর্শিত) অ্যাক্সেস টোকেনকে JS স্টেটে রাখে। রিফ্রেশে ক্লিয়ার হয় এবং “পরে ধরে নিয়ে যাওয়া” কমায়, কিন্তু সক্রিয় XSS হলে ইতিমধ্যে পেজ চলাকালীন তা পড়া যায়। সংক্ষিপ্ত-জীবী অ্যাক্সেস টোকেন এবং একটি সুরক্ষিত রিফ্রেশ ফ্লো জোড়া লাগান।
localStorage/sessionStorage সুবিধাজনক কিন্তু ঝুঁকিপূর্ণ: কোনো XSS ভালনারেবিলিটি টোকেন চুরি করে নিতে পারে। এগুলো ব্যবহার করলে XSS প্রতিরোধ অপরিহার্য (CSP, আউটপুট স্কেপিং, ডিপেন্ডেন্সি পরিচর্যা) এবং টোকেন সংক্ষিপ্ত-জীবী রাখুন।
Secured cookies (ওয়েবের জন্য প্রায়শই সবচেয়ে নিরাপদ ডিফল্ট) টোকেন HttpOnly কুকিতে রাখে যাতে জাভাস্ক্রিপ্ট তা পড়তে না পারে—XSS-ভিত্তিক টোকেন চুরি কমায়। ট্রেড-অফ হল CSRF ঝুঁকি, কারণ ব্রাউজার কুকি স্বয়ংক্রিয়ভাবে পাঠায়।
কুকি ব্যবহার করলে সেট করুন:
HttpOnlySecure (শুধু HTTPS)SameSite=Lax বা SameSite=Strict (কিছু ক্রস-সাইট ফ্লো SameSite=None; Secure চাইতে পারে)স্টেট-চেঞ্জিং অনুরোধগুলোর জন্য CSRF টোকেনও বিবেচনা করুন।
iOS/Android-এ টোকেন প্ল্যাটফর্মের সিকিউর স্টোরেজে (Keychain / Keystore-backed) রাখুন। সাধারণ ফাইল বা প্রেফারেন্স এড়িয়ে চলুন। আপনার থ্রেট মডেলে রুটেড/জেলব্রোকেন ডিভাইস থাকলে, তথ্য উদ্ধারের সম্ভাবনা সামনে ধরুন এবং সংক্ষিপ্ত-জীবী টোকেন ও সার্ভার-সাইড নিয়ন্ত্রণ বিশ্বাস করুন।
একটি টোকেন কী করতে পারে তা সীমিত করুন: সর্বনিম্ন স্কোপ/ক্লেইম ব্যবহার করুন, অ্যাক্সেস টোকেন সংক্ষিপ্ত-জীবী রাখুন, এবং সংবেদনশীল ডেটা এমবেড করা এড়ান।
JWT সুবিধাজনক, কিন্তু অনেক ঘটনার কারণ হলো পূর্বনির্ধারিত ভুল। JWT-কে নগদের মতো বিবেচনা করুন: যাঁর কাছে আছে তাঁরাই সাধারণত এটাকে ব্যয় করতে পারে।
যদি টোকেন দিনের বা সপ্তাহের জন্য থাকে, টোকেন ফাঁস হলে আক্রমণকারী পুরো উইন্ডোটা ব্যবহার করতে পারে।
সংক্ষিপ্ত-জীবী অ্যাক্সেস টোকেন (মিনিট) পছন্দ করুন এবং একটি নিরাপদ পদ্ধতিতে রিফ্রেশ করুন। “রিমেমবার মি” দরকার হলে রিফ্রেশ টোকেন ও সার্ভার-সাইড নিয়ন্ত্রণ ব্যবহার করুন।
ভ্যালিড সিগনেচারই যথেষ্ট নয়। iss ও aud যাচাই করুন, এবং টাইম-বেসড ক্লেইম যেমন exp, nbf যাচাই করুন।
ডিকোড করা মানে যাচাই করা নয়। সবসময় সার্ভারে সিগনেচার যাচাই করুন এবং অনুমোদন সার্ভার-সাইডে প্রয়োগ করুন।
JWT-কে কুয়েরি প্যারামে রাখবেন না। সেগুলো ব্রাউজার ইতিহাসে, সার্ভার লগে, অ্যানালিটিক্স টুলে এবং রেফারার হেডারে পৌঁছে যেতে পারে।
Authorization: Bearer ... ব্যবহার করুন।
ধারণা করুন কী ও টোকেন ফাঁস হতে পারে। সাইনিং কী রোটেট করুন, kid ব্যবহার করে মসৃণ রোটেশন সহায় করুন, এবং প্রত্যাহারের কৌশল রাখুন (সংক্ষিপ্ত মেয়াদ + অ্যাকাউন্ট/সেশন নিষ্ক্রিয় করার ক্ষমতা)। স্টোরেজ নির্দেশিকার জন্য দেখুন /blog/where-to-store-jwts-safely.
JWT কার্যকর, কিন্তু এটা স্বয়ংক্রিয়ভাবে সর্বোচ্চ পছন্দ নয়। বাস্তব প্রশ্ন হলো—আপনি কি এমন একটি স্ব-নির্ভর টোকেন থেকে লাভ পাবেন যা প্রতিটি অনুরোধে ডাটাবেস লুকআপ ছাড়া ভেরিফাই করা যায়।
পारম্পরিক সার্ভার-রেন্ডার করা ওয়েব অ্যাপের জন্য যেখানে সরল ইনভ্যালিডেশন জরুরি, সার্ভার-সাইড সেশন ও HttpOnly কুকি প্রায়ই সহজতর ও নিরাপদ ডিফল্ট।
আপনি যদি সার্ভিস জুড়ে স্টেটলেস ভেরিফিকেশন প্রয়োজন এবং টোকেন সংক্ষিপ্ত-জীবী রাখতে পারেন, JWT বেছে নিন।
যদি তাৎক্ষণিক প্রত্যাহার দরকার, টোকেন-এ সংবেদনশীল ডাটা রাখার পরিকল্পনা থাকে, বা আপনি সেশন কুকি সহজে ব্যবহার করতে পারেন—তাহলে JWT এড়িয়ে চলুন।
সঠিক কী ও প্রত্যাশিত অ্যালগরিদম ব্যবহার করে যাচাই করুন। ভুল সিগনেচারকে প্রত্যাখ্যান করুন—কোনও ব্যতিক্রম নেই।
exp (মেয়াদ)টোকেন মেয়াদোত্তীর্ণ হয়নি কি না নিশ্চিত করুন।
nbf (নট বিফোর)যদি উপস্থিত থাকে, টোকেন খুব আগেই ব্যবহার করা হচ্ছে না কিনা দেখুন।
aud (অডিয়েন্স)নিশ্চিত করুন টোকেনটি আপনার API/সেবা জন্য ইচ্ছিত।
iss (ইস্যুয়ার)নিশ্চিত করুন টোকেন প্রত্যাশিত ইস্যুকারী থেকে এসেছে।
টোকেন ফরম্যাট যাচাই করুন, সর্বাধিক আকার জারি করুন, এবং অপ্রত্যাশিত ক্লেইম ধরণ প্রত্যাখ্যান করুন যাতে প্রান্ত-ঘটনা বাগ কমে।
HS256 (সিমেট্রিক কী): একটি শেয়ার্ড সিক্রেট সাইন ও ভেরিফাই করে।
RS256 / ES256 (অ্যাসিমেট্রিক কীগুলো): প্রাইভেট কী সাইন করে; পাবলিক কী ভেরিফাই করে।
রুল অব থাম্ব: যদি একাধিক স্বতন্ত্র সিস্টেম টোকেন যাচাই করে (বা আপনি প্রতিটি ভেরিফায়ারকে পুরোপুরি বিশ্বাস করেন না), তবে RS256/ES256 পছন্দ করুন।
iss, aud, এবং নীতিমতো ব্যবহারকারীর আইডি) লগ করুন।Is JWT encrypted?
Not by default. Most JWTs are signed, not encrypted, meaning the contents can be read by anyone who has the token. Use JWE or keep sensitive data out of JWTs.
Can I revoke a JWT?
Not easily if you rely only on self-contained access tokens. Common approaches include short-lived access tokens, deny-lists for high-risk events, or refresh tokens with rotation.
How long should exp be?
As short as your UX and architecture allow. Many APIs use minutes for access tokens, paired with refresh tokens for longer sessions.
আপনি যদি নতুন API বা SPA-তে JWT অথেনটিকেশন ইমপ্লিমেন্ট করে থাকেন, অনেক কাজ পুনরাবৃত্তিমূলক: মিডলওয়্যার ওয়্যারিং, iss/aud/exp যাচাই, কুকি ফ্ল্যাগ সেট করা, এবং লগ থেকে টোকেন হ্যান্ডলিং দূরে রাখা।
Koder.ai দিয়ে আপনি দ্রুত একটি ওয়েব অ্যাপ (React), ব্যাকএন্ড সার্ভিস (Go + PostgreSQL), বা Flutter মোবাইল অ্যাপ তৈরি করতে পারেন—চ্যাট-চালিত ওয়ার্কফ্লো ব্যবহার করে, পরে প্ল্যানিং মোডে পুনরায় সাজিয়ে নিরাপত্তা, কী রোটেশন কৌশল এবং ডেপ্লয়মেন্ট সেটিংস কনফিগার করতে পারেন। এটা JWT-ভিত্তিক প্রমাণীকরণ ফ্লো দ্রুত গড়ে তুলতে কার্যকর একটি উপায়।
A JWT (JSON Web Token) is a compact, URL-safe string that carries claims (data fields) and can be verified by a server. It’s commonly sent on API requests via:
Authorization: Bearer <token>The key idea: the server can validate the token’s integrity (via its signature) without needing a per-user session record for every request.
Session auth typically stores state on the server (a session record keyed by a cookie/session ID). With JWT-based auth, the client presents a signed token each request, and the API validates it.
JWTs are popular for APIs and multi-service architectures because verification can be done locally, reducing shared session storage needs.
“Stateless” still often includes server-side checks like revocation lists, user status checks, or key rotation handling.
A JWT is three Base64URL-encoded parts separated by dots:
header.payload.signatureThe header describes how it was signed, the payload contains claims (like sub, exp, aud), and the signature lets the server detect tampering.
No. Standard JWTs are usually signed, not encrypted.
If you need confidentiality, consider JWE (encrypted tokens) or keep sensitive data server-side and store only an identifier in the JWT.
The signature lets the server verify the token hasn’t been altered and was minted by someone with the signing key.
It does not:
expTreat the token like a credential: if it leaks, it can often be replayed until it expires.
alg tells the verifier which algorithm was used (e.g., HS256 vs RS256). kid is a key identifier that helps pick the right verification key during key rotation.
Security rules of thumb:
Start with standard registered claims and keep custom ones minimal.
Common registered claims:
JWT is a token format; OAuth 2.0 and OpenID Connect are protocols.
Typical mapping:
For browser-based apps, common options are:
localStorage/sessionStorage: convenient, but any XSS can exfiltrate tokens.At minimum, validate:
exp (not expired)iss (expected issuer)aud (meant for your API)nbf (if present)Also add practical guardrails:
alg values.alg: "none".kid value cause unsafe key lookup behavior.iss (issuer)sub (subject / user identifier)aud (audience / intended API)exp (expiration)iat (issued at)nbf (not before)Avoid putting secrets or sensitive personal data in the payload, since it’s readable if the token is exposed.
Important: don’t use an ID token to call an API just because it “looks like” a JWT access token.
SameSiteWhatever you choose, keep access tokens short-lived and minimize token privileges.