JWT কী? JSON Web Token-এর স্পষ্ট গাইড
জেনে নিন JWT (JSON Web Token) কী, এর তিনটি অংশ কিভাবে কাজ করে, কোথায় ব্যবহার হয়, এবং টোকেন সংক্রান্ত সাধারণ নিরাপত্তা টিপস।
JWT সহজ ভাষায়
একটি JWT (JSON Web Token) হল একটি কমপ্যাক্ট, URL-সুরক্ষিত স্ট্রিং যা একটি সেট তথ্য (সাধারণত ব্যবহারকারী বা সেশনের সম্পর্কে) নির্দেশ করে এবং সিস্টেমগুলোর মধ্যে পাঠানো যায়। আপনি এটি সাধারনত eyJ... দিয়ে শুরু হওয়া একটি লম্বা মান হিসেবে পাবেন, এবং এটি HTTP হেডারে পাঠানো হয় যেমন Authorization: Bearer <token>।
কেন টোকেন ব্যবহার করা হয়?
পৌরাণিক লগইনে প্রায়ই সার্ভার সেশন ব্যবহার হয়: সাইন ইন করার পর সার্ভার সেশন ডেটা সংরক্ষণ করে এবং ব্রাউজারকে একটি সেশন আইডি কুকি দেয়। প্রতিটি অনুরোধের সাথে সেই কুকি যায় এবং সার্ভার সেশন দেখাই করে।
টোকেন-ভিত্তিক প্রমাণীকরণ-এ সার্ভার প্রতিটি ব্যবহারকারীর অনুরোধের জন্য স্টেট রাখার প্রয়োজন টেনে নেয় না। ক্লায়েন্ট একটি টোকেন (যেমন JWT) ধরে রাখে এবং API কলগুলোর সাথে এটিকে পাঠায়। এটা API-গুলোর জন্য জনপ্রিয় কারণ:
- একাধিক পরিষেবায় (API গেটওয়ে, মাইক্রোসার্ভিস) ভালভাবে কাজ করে
- মোবাইল ও সিঙ্গল-পেজ অ্যাপ (SPA) যেখানে ক্লায়েন্ট সরাসরি API কল করে তার জন্য মানানসই
- সার্ভারগুলোর মধ্যে শেয়ার সেশন স্টোরেজের প্রয়োজন কমায়
গুরুত্বপূর্ণ নুয়ান্স: “স্টেটলেস” মানেই “কখনও সার্ভার-সাইড যাচাই করা হবে না” নয়। অনেক বাস্তব সিস্টেম এখনও ব্যবহারকারী স্থিতি, কী রোটেশন বা প্রত্যাহার মেকানিজম অনুযায়ী টোকেন যাচাই করে।
প্রমাণীকরণ বনাম অনুমোদন (সহজ ভাষায়)
- প্রমাণীকরণ (Authentication) উত্তর দেয়: তুমি কে? (তুমি সাইন ইন করেছো এবং পরিচয় প্রমাণ করেছো)
- অনুমোদন (Authorization) উত্তর দেয়: তোমার কি করার অনুমতি আছে? (তুমি ইনভয়েস পড়তে পারো, প্রকল্প সম্পাদনা করতে পারো, অ্যাডমিন পেজে যেতে পারো, ইত্যাদি)
JWT সাধারণত প্রমাণীকরণের প্রমাণ বহন করে (তুমি সাইন ইন) এবং বেসিক অনুমোদন ইঙ্গিত (রোল, পারমিশন, স্কোপ) দেয়—কিন্তু সার্ভারকে এখনও অনুমোদন নিয়ম বাস্তবায়ন করতে হবে।
JWT কোথায় দেখা যায়
আপনি সাধারণত JWT-কে অ্যাক্সেস টোকেন হিসেবে দেখতে পাবেন:
- ওয়েব API
- SPA
- মোবাইল অ্যাপস
- OAuth 2.0 বা OpenID Connect (OIDC) ব্যবহার করে এমন সিস্টেম
JWT গঠন: header, payload, signature
একটি JWT হল তিনটি অংশের একটি কমপ্যাক্ট স্ট্রিং, প্রতিটি base64url-এ এনকোডেড এবং ডট দিয়ে পৃথক:
header.payload.signature
উদাহরণ (সংশিপ্ত):
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwiaWF0IjoxNzAwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c…
1) Header
হেডার টোকেনটি কীভাবে তৈরি করা হয়েছে তা বর্ণনা করে—সবচেয়ে গুরুত্বপূর্ণ হলো সাই닝 অ্যালগরিদম (যেমন HS256, RS256/ES256) এবং টোকেন টাইপ।
সাধারণ ফিল্ড:
typ: প্রায়ই"JWT"(অনেকখানি উপেক্ষিত)alg: ব্যবহৃত সাইনের অ্যালগরিদমkid: কী আইডেন্টিফায়ার, কী রোটেশনের সময় ভেরিফায়ারকে সঠিক কী পেতে সাহায্য করে
সুরক্ষা নোট: হেডারকে অন্ধভাবে বিশ্বাস করবেন না। আপনি যে অ্যালগরিদম ব্যবহার করেন সেগুলোর একটি allowlist প্রয়োগ করুন, এবং alg: "none" গ্রহণ করবেন না।
2) Payload
পেলোড-এ ব্যবহারকারী ও টোকেন প্রসঙ্গ সম্পর্কিত “ক্লেইম” থাকে: কার জন্য, কার দ্বারা ইস্যু হয়েছে, এবং কখন মেয়াদ শেষ হবে ইত্যাদি।
গুরুত্বপূর্ণ: JWT স্বয়ংক্রিয়ভাবে এনক্রিপ্ট করা হয় না। Base64url এনকোডিং টোকেনটিকে URL-সুরক্ষিত করে; এটি ডেটা লুকায় না।
যেহেতু যে কেউ টোকেন পেলে হেডার ও পেলোড ডিকোড করে পড়তে পারে, তাই সিক্রেট (পাসওয়ার্ড, API কী) বা সংবেদনশীল ব্যক্তিগত তথ্য JWT-এ রাখা উচিত নয়।
3) Signature
সিগনেচার তৈরি করা হয় হেডার + পেলোড সাইন করে:
- HS256: একটি শেয়ার্ড সিক্রেট সাইন ও ভেরিফাই করে
- RS256/ES256: একটি প্রাইভেট কী সাইন করে; একটি পাবলিক কী ভেরিফাই করে
সিগনেচার ইন্টিগ্রিটি নিশ্চিত করে: এটি সার্ভারকে বলে দেয় টোকেন পরিবর্তিত হয়নি এবং বিশ্বাসযোগ্য সাইজার দ্বারা ইস্যু হয়েছে। এটি গোপনীয়তা দেয় না।
আকার বিবেচনা
কারণ JWT প্রতি অনুরোধে হেডার ও পেলোড বহন করে, বড় টোকেন মানে বেশি ব্যান্ডউইডথ ও ওভারহেড। ক্লেইম সংক্ষেপে রাখুন এবং ভারী ডেটার পরিবর্তে আইডেন্টিফায়ার ব্যবহার করুন।
পেলোড ও ক্লেইম: কি রাখবেন (এবং কি রাখবেন না)
ক্লেইম সাধারণত দুই ভাগে পড়ে: রেজিস্টার্ড (স্ট্যান্ডার্ড নাম) এবং কাস্টম (আপনার অ্যাপের ফিল্ড)।
সাধারণ রেজিস্টার্ড ক্লেইম
iss(issuer): কে টোকেন তৈরি করেছেsub(subject): টোকেন কার সম্পর্কে (সাধারণত একটি ব্যবহারকারী আইডি)aud(audience): টোকেন কার জন্য নির্ধারিত (যেমন একটি নির্দিষ্ট API)exp(expiration time): কখন টোকেন গ্রহণ করা বন্ধ করা হবেiat(issued at): কখন টোকেন তৈরি হয়েছেnbf(not before): টোকেন এটি সময়ের আগে গ্রহণ করা উচিত নয়
কাস্টম ক্লেইম: যতটা সম্ভব সীমিত রাখুন
প্রাপ্ত পরিষেবাটি যদি অনুমোদনের সিদ্ধান্ত নিতে সত্যিকারের প্রয়োজন নেই, তাহলে অতিরিক্ত ক্লেইম যোগ করবেন না।
ভালো উদাহরণ:
- একটি স্থিতিশীল অভ্যন্তরীণ ব্যবহারকারী আইডেন্টিফায়ার (
user_id) - একটি ছোট সেট রোল/পারমিশন (শুধু যদি আপনি এগুলো আপ টু ডেট রাখতে পারেন)
- মাল্টি-টেন্যান্ট অ্যাপে টেন্যান্ট/অর্গানাইজেশন আইডি
অতরিক্ত প্রোফাইল ডেটা এড়ান — এগুলো টোকেন বেঁধে দেয়, দ্রুত পুরনো হয়, এবং টোকেন ফাঁস হলে প্রভাব বাড়ায়।
কী কখনও JWT পেলোডে রাখবেন না
কেননা পেলোড পড়া যায়, তাই রাখবেন না:
- পাসওয়ার্ড, API কী, রিফ্রেশ টোকেন বা কোনো গোপন মান
- পেমেন্ট বিবরণ, সরকারি আইডি, বা সংবেদনশীল ব্যক্তিগত তথ্য
- যা আপনি ব্রাউজার, প্রক্সি বা লগ থেকে কপি হতে চান না
যদি সংবেদনশীল তথ্য প্রয়োজন হয়, সার্ভার-সাইডে তা সংরক্ষণ করুন এবং শুধুমাত্র একটি রেফারেন্স (যেমন একটি আইডি) টোকেনে রাখুন—অথবা প্রয়োজনে এনক্রিপ্টেড টোকেন ফরম্যাট (JWE) ব্যবহার করুন।
সিগনেচার কিভাবে কাজ করে (এবং কি নিশ্চিত করে)
সাইন করা মানে এনক্রিপ্ট করা নয়।
- সাইনিং একটি লেটার সিল করার মতো: মানুষ পড়তে পারে, কিন্তু যাচাই করা যায় যে এটি বদলানো হয়নি।
- এনক্রিপশন লেটারকে তালাবন্দি করার মতো: কেবল কীধারীই পড়তে পারে।
টোকেন ইস্যু করার সময় সার্ভার এনকোড করা হেডার + পেলোড সাইন করে। পরে যখন টোকেন উপস্থাপন করা হয়, সার্ভার পুনরায় সিগনেচার হিসাব করে এবং মিলায়। যদি কেউ এক অক্ষরও বদলে দেয় (যেমন "role":"user" থেকে "role":"admin"), যাচাই ব্যর্থ হয় এবং টোকেন প্রত্যাখ্যাত হয়।
JWT বনাম OAuth, OpenID Connect, এবং টোকেন টাইপ
JWT একটি টোকেন ফরম্যাট। OAuth 2.0 এবং OpenID Connect (OIDC) এমন প্রোটোকল যা অ্যাপস কীভাবে টোকেন অনুরোধ, ইস্যু ও ব্যবহার করবে তা বর্ণনা করে।
OAuth 2.0 এবং অ্যাক্সেস/রিফ্রেশ টোকেন
OAuth 2.0 মূলত অনুমোদন নিয়ে কাজ করে: একটি অ্যাপকে ব্যবহারকারীর পাসওয়ার্ড শেয়ার না করে API-তে অ্যাক্সেস দেওয়া।
- Access token: API-কে অনুমতি প্রদানের জন্য উপস্থাপন করা হয়; এটি JWT বা opaque টোকেন হতে পারে
- Refresh token: নতুন অ্যাক্সেস টোকেন পেতে ব্যবহৃত দীর্ঘজীবী টোকেন
অ্যাক্সেস টোকেন সাধারণত সংক্ষিপ্ত-জীবী (মিনিট পর্যায়ে)। সংক্ষিপ্ত মেয়াদ টোকেন ফাঁস হলে ক্ষতি সীমাবদ্ধ করে।
OpenID Connect (OIDC) এবং ID টোকেন
OIDC OAuth 2.0-কে উপরে প্রমাণীকরণ যোগ করে এবং একটি ID টোকেন পরিচয় করায়, যা বেশিরভাগ ক্ষেত্রে JWT।
- ID token: ক্লায়েন্ট অ্যাপকে ব্যবহারকারীর পরিচয় নিশ্চিত করার জন্য
- Access token: API-কে অনুরোধ অনুমোদনের জন্য
একটি গুরুত্বপূর্ণ নিয়ম: ID টোকেন API কল করতে ব্যবহার করবেন না।
আরও প্র্যাকটিক্যাল ফ্লো জানতে দেখুন /blog/jwt-authentication-flow.
সাধারণ JWT প্রমাণীকরণ ফ্লো
একটি টিপিক্যাল ফ্লো দেখতে এমন:
1) লগইন
ব্যবহারকারী সাইন ইন করে (ইমেইল/পাসওয়ার্ড, SSO ইত্যাদি)। সফল হলে সার্ভার একটি JWT তৈরি করে (সাধারণত একটি অ্যাক্সেস টোকেন) যেখানে বিষয় ও মেয়াদ শেষের মতো অপরিহার্য ক্লেইম থাকে।
2) টোকেন ইস্যু
সার্ভার টোকেন সাইন করে এবং ক্লায়েন্টকে (ওয়েব অ্যাপ, মোবাইল অ্যাপ, বা অন্য সার্ভিস) ফেরত দেয়।
3) API কল
প্রটেকটেড এন্ডপয়েন্টের জন্য ক্লায়েন্ট Authorization হেডারে JWT অন্তর্ভুক্ত করে:
Authorization: Bearer <JWT>
4) যাচাই
অনুরোধ পরিবেশন করার আগে API সাধারণত পরীক্ষা করে:
- signature (ইন্টিগ্রিটি + বিশ্বাসযোগ্য issuer)
exp(মেয়াদ শেষ হয়নি)iss(আশা করা issuer)aud(এই API-র জন্য টোকেনটি উদ্দেশ্যপ্রণোদিত)
যদি সব চেক পাস করে, API ব্যবহারকারীকে প্রমাণিত হিসেবে গ্রহণ করে এবং অনুমোদনের নিয়ম (যেমন রেকর্ড-স্তরের অনুমতি) প্রয়োগ করে।
5) ক্লক স্কিউ সম্পর্কে একটি দ্রুত নোট
সিস্টেমের ঘড়ি বিচ্যুতির কারণে, অনেক সিস্টেম টাইম-বেসড ক্লেইম যাচাই করার সময় ছোট clock skew মঞ্জুর করে (যেমন exp বা nbf)। স্কিউ ছোট রাখুন যাতে টোকেনের বৈধতা অনিচ্ছাকৃতভাবে বাড়ে না।
JWT কোথায় নিরাপদে সংরক্ষণ করবেন
সংরক্ষণ পছন্দ কী ধরনের আক্রমণকারী টোকেনটি চুরি করতে পারে এবং কত সহজে তারা টোকেন পুনরায় ব্যবহার করতে পারে তা বদলে দেয়।
ব্রাউজার অ্যাপ: মেমোরি বনাম localStorage বনাম কুকি
ইন-মেমোরি স্টোরেজ (SPA-এর জন্য প্রায়শই পরামর্শিত) অ্যাক্সেস টোকেনকে JS স্টেটে রাখে। রিফ্রেশে ক্লিয়ার হয় এবং “পরে ধরে নিয়ে যাওয়া” কমায়, কিন্তু সক্রিয় XSS হলে ইতিমধ্যে পেজ চলাকালীন তা পড়া যায়। সংক্ষিপ্ত-জীবী অ্যাক্সেস টোকেন এবং একটি সুরক্ষিত রিফ্রেশ ফ্লো জোড়া লাগান।
localStorage/sessionStorage সুবিধাজনক কিন্তু ঝুঁকিপূর্ণ: কোনো XSS ভালনারেবিলিটি টোকেন চুরি করে নিতে পারে। এগুলো ব্যবহার করলে XSS প্রতিরোধ অপরিহার্য (CSP, আউটপুট স্কেপিং, ডিপেন্ডেন্সি পরিচর্যা) এবং টোকেন সংক্ষিপ্ত-জীবী রাখুন।
Secured cookies (ওয়েবের জন্য প্রায়শই সবচেয়ে নিরাপদ ডিফল্ট) টোকেন HttpOnly কুকিতে রাখে যাতে জাভাস্ক্রিপ্ট তা পড়তে না পারে—XSS-ভিত্তিক টোকেন চুরি কমায়। ট্রেড-অফ হল CSRF ঝুঁকি, কারণ ব্রাউজার কুকি স্বয়ংক্রিয়ভাবে পাঠায়।
কুকি ব্যবহার করলে সেট করুন:
HttpOnlySecure(শুধু HTTPS)SameSite=LaxবাSameSite=Strict(কিছু ক্রস-সাইট ফ্লোSameSite=None; Secureচাইতে পারে)
স্টেট-চেঞ্জিং অনুরোধগুলোর জন্য CSRF টোকেনও বিবেচনা করুন।
মোবাইল অ্যাপ: OS-র সিকিউর স্টোরেজ প্রাধান্য দিন
iOS/Android-এ টোকেন প্ল্যাটফর্মের সিকিউর স্টোরেজে (Keychain / Keystore-backed) রাখুন। সাধারণ ফাইল বা প্রেফারেন্স এড়িয়ে চলুন। আপনার থ্রেট মডেলে রুটেড/জেলব্রোকেন ডিভাইস থাকলে, তথ্য উদ্ধারের সম্ভাবনা সামনে ধরুন এবং সংক্ষিপ্ত-জীবী টোকেন ও সার্ভার-সাইড নিয়ন্ত্রণ বিশ্বাস করুন।
লিস্ট প্রিভিলেজ
একটি টোকেন কী করতে পারে তা সীমিত করুন: সর্বনিম্ন স্কোপ/ক্লেইম ব্যবহার করুন, অ্যাক্সেস টোকেন সংক্ষিপ্ত-জীবী রাখুন, এবং সংবেদনশীল ডেটা এমবেড করা এড়ান।
প্রচলিত JWT সিকিউরিটি ত্রুটি যা এড়ানো উচিত
JWT সুবিধাজনক, কিন্তু অনেক ঘটনার কারণ হলো পূর্বনির্ধারিত ভুল। JWT-কে নগদের মতো বিবেচনা করুন: যাঁর কাছে আছে তাঁরাই সাধারণত এটাকে ব্যয় করতে পারে।
1) অত্যধিক দীর্ঘ মেয়াদ
যদি টোকেন দিনের বা সপ্তাহের জন্য থাকে, টোকেন ফাঁস হলে আক্রমণকারী পুরো উইন্ডোটা ব্যবহার করতে পারে।
সংক্ষিপ্ত-জীবী অ্যাক্সেস টোকেন (মিনিট) পছন্দ করুন এবং একটি নিরাপদ পদ্ধতিতে রিফ্রেশ করুন। “রিমেমবার মি” দরকার হলে রিফ্রেশ টোকেন ও সার্ভার-সাইড নিয়ন্ত্রণ ব্যবহার করুন।
2) issuer ও audience চেক বাদ দেওয়া
ভ্যালিড সিগনেচারই যথেষ্ট নয়। iss ও aud যাচাই করুন, এবং টাইম-বেসড ক্লেইম যেমন exp, nbf যাচাই করুন।
3) ডিকোড করা পেলোডে বিশ্বাস করা
ডিকোড করা মানে যাচাই করা নয়। সবসময় সার্ভারে সিগনেচার যাচাই করুন এবং অনুমোদন সার্ভার-সাইডে প্রয়োগ করুন।
4) অ্যালগরিদম কনফিউশন ও কী মিশম্যাচ
- টোকেন যে অ্যালগরিদম দাবি করে তা গ্রহণ করবেন না। প্রত্যাশিত অ্যালগরিদম allowlist করুন।
- সিমেট্রিক কী (HS256) এবং পাবলিক/প্রাইভেট কী (RS256/ES256) মিশাবেন না।
- পরিবেশ অনুযায়ী কী পৃথক করুন এবং রোটেট করুন যাতে বিস্ফোরণ পরিধি কম থাকে।
5) URL, লগ ও রেফারারে টোকেন ফাঁস
JWT-কে কুয়েরি প্যারামে রাখবেন না। সেগুলো ব্রাউজার ইতিহাসে, সার্ভার লগে, অ্যানালিটিক্স টুলে এবং রেফারার হেডারে পৌঁছে যেতে পারে।
Authorization: Bearer ... ব্যবহার করুন।
6) কী রোটেশন বা প্রত্যাহার পরিকল্পনা নেই
ধারণা করুন কী ও টোকেন ফাঁস হতে পারে। সাইনিং কী রোটেট করুন, kid ব্যবহার করে মসৃণ রোটেশন সহায় করুন, এবং প্রত্যাহারের কৌশল রাখুন (সংক্ষিপ্ত মেয়াদ + অ্যাকাউন্ট/সেশন নিষ্ক্রিয় করার ক্ষমতা)। স্টোরেজ নির্দেশিকার জন্য দেখুন /blog/where-to-store-jwts-safely.
কখন JWT ব্যবহার করবেন (এবং কখন নয়)
JWT কার্যকর, কিন্তু এটা স্বয়ংক্রিয়ভাবে সর্বোচ্চ পছন্দ নয়। বাস্তব প্রশ্ন হলো—আপনি কি এমন একটি স্ব-নির্ভর টোকেন থেকে লাভ পাবেন যা প্রতিটি অনুরোধে ডাটাবেস লুকআপ ছাড়া ভেরিফাই করা যায়।
JWT-এর ভাল ব্যবহার ক্ষেত্র
- স্কেলে স্টেটলেস API: লোকাল ভেরিফিকেশন (সিগনেচার + এক্সপায়ারি) দিয়ে প্রতি অনুরোধে সেশন লুকআপ দরকার নেই
- একাধিক সার্ভিস / মাইক্রোসার্ভিস: শেয়ার করা ভেরিফিকেশন নিয়ম ও পাবলিক কী ব্যবহার করা যায়
- SPA ও মোবাইল অ্যাপ: ক্লায়েন্ট সরাসরি API কল করে
- সংক্ষিপ্ত-জীবী অ্যাক্সেস টোকেন: চুরি হলে ক্ষতি কম
কখন JWT অনুচিত
- তারাতারি প্রত্যাহার আবশ্যক: যদি ‘সকল জায়গায় এখনই লগআউট’ দরকার হয়, তাহলে সেশন সহজ হতে পারে যদি অতিরিক্ত ইনফ্রাস্ট্রাকচার না চান
- সংবেদনশীল ডাটা বহন করতে হয়: সাধারণ JWT সাইন করা হয়, এনক্রিপ্ট করা নয়
- দীর্ঘজীবী টোকেন: এগুলো উচ্চ-মূল্যের এবং চুরি হলে ঝুঁকি বেশি
যখন সাধারণ সেশন কুকি ভাল
পारম্পরিক সার্ভার-রেন্ডার করা ওয়েব অ্যাপের জন্য যেখানে সরল ইনভ্যালিডেশন জরুরি, সার্ভার-সাইড সেশন ও HttpOnly কুকি প্রায়ই সহজতর ও নিরাপদ ডিফল্ট।
দ্রুত সিদ্ধান্ত চেকলিস্ট
আপনি যদি সার্ভিস জুড়ে স্টেটলেস ভেরিফিকেশন প্রয়োজন এবং টোকেন সংক্ষিপ্ত-জীবী রাখতে পারেন, JWT বেছে নিন।
যদি তাৎক্ষণিক প্রত্যাহার দরকার, টোকেন-এ সংবেদনশীল ডাটা রাখার পরিকল্পনা থাকে, বা আপনি সেশন কুকি সহজে ব্যবহার করতে পারেন—তাহলে JWT এড়িয়ে চলুন।
প্র্যাকটিক্যাল চেকলিস্ট ও FAQ
যাচাই চেকলিস্ট (প্রতিবার কি যাচাই করবেন)
- Signature বৈধ
সঠিক কী ও প্রত্যাশিত অ্যালগরিদম ব্যবহার করে যাচাই করুন। ভুল সিগনেচারকে প্রত্যাখ্যান করুন—কোনও ব্যতিক্রম নেই।
exp(মেয়াদ)
টোকেন মেয়াদোত্তীর্ণ হয়নি কি না নিশ্চিত করুন।
nbf(নট বিফোর)
যদি উপস্থিত থাকে, টোকেন খুব আগেই ব্যবহার করা হচ্ছে না কিনা দেখুন।
aud(অডিয়েন্স)
নিশ্চিত করুন টোকেনটি আপনার API/সেবা জন্য ইচ্ছিত।
iss(ইস্যুয়ার)
নিশ্চিত করুন টোকেন প্রত্যাশিত ইস্যুকারী থেকে এসেছে।
- স্যানিটি চেক (প্রস্তাবিত)
টোকেন ফরম্যাট যাচাই করুন, সর্বাধিক আকার জারি করুন, এবং অপ্রত্যাশিত ক্লেইম ধরণ প্রত্যাখ্যান করুন যাতে প্রান্ত-ঘটনা বাগ কমে।
HS256 vs RS256/ES256 বাছাই
-
HS256 (সিমেট্রিক কী): একটি শেয়ার্ড সিক্রেট সাইন ও ভেরিফাই করে।
- ভাল: একটি একাই কন্ট্রোল করা অ্যাপ/এপিআই-এর জন্য।
- সতর্কতা: যে ভেরিফায়ারটির কাছে সিক্রেট আছে, সে একইসাথে টোকেন মেন্টও করতে পারে।
-
RS256 / ES256 (অ্যাসিমেট্রিক কীগুলো): প্রাইভেট কী সাইন করে; পাবলিক কী ভেরিফাই করে।
- ভাল: একাধিক সার্ভিস টোকেন যাচাই করলে; পাবলিক কী বিতরণ করে সাইনিং সক্ষম নয় এমন ভেরিফায়ার তৈরি করা যায়।
- অপারেশনাল নোট: রোটেশন সাধারণত নিরাপদ কারণ শুধুমাত্র সাইনকারী প্রাইভেট কী রাখে।
রুল অব থাম্ব: যদি একাধিক স্বতন্ত্র সিস্টেম টোকেন যাচাই করে (বা আপনি প্রতিটি ভেরিফায়ারকে পুরোপুরি বিশ্বাস করেন না), তবে RS256/ES256 পছন্দ করুন।
মনিটরিং ও লগিং (টোকেন ফাঁস না করে)
- কাঁচা টোকেন লগ করবেন না (হেডার, কুকি, কুয়েরি স্ট্রিং)।
- যদি করিলেশন দরকার হয়, একটি টোকেন ফিঙ্গারপ্রিন্ট (যেমন হ্যাশ) বা নিরাপদ মেটাডেটা (
iss,aud, এবং নীতিমতো ব্যবহারকারীর আইডি) লগ করুন। - অস্বাভাবিকতা দেখুন: সিগনেচার ব্যর্থতা, মেয়াদোত্তীর্ণ টোকেন স্পাইক, অস্বাভাবিক audience/issuer, এবং সন্দেহজনক রিফ্রেশ প্যাটার্ন।
FAQs
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.
Koder.ai দিয়ে JWT-প্রটেক্টেড অ্যাপ দ্রুত তৈরি করা
আপনি যদি নতুন API বা SPA-তে JWT অথেনটিকেশন ইমপ্লিমেন্ট করে থাকেন, অনেক কাজ পুনরাবৃত্তিমূলক: মিডলওয়্যার ওয়্যারিং, iss/aud/exp যাচাই, কুকি ফ্ল্যাগ সেট করা, এবং লগ থেকে টোকেন হ্যান্ডলিং দূরে রাখা।
Koder.ai দিয়ে আপনি দ্রুত একটি ওয়েব অ্যাপ (React), ব্যাকএন্ড সার্ভিস (Go + PostgreSQL), বা Flutter মোবাইল অ্যাপ তৈরি করতে পারেন—চ্যাট-চালিত ওয়ার্কফ্লো ব্যবহার করে, পরে প্ল্যানিং মোডে পুনরায় সাজিয়ে নিরাপত্তা, কী রোটেশন কৌশল এবং ডেপ্লয়মেন্ট সেটিংস কনফিগার করতে পারেন। এটা JWT-ভিত্তিক প্রমাণীকরণ ফ্লো দ্রুত গড়ে তুলতে কার্যকর একটি উপায়।
সাধারণ প্রশ্ন
What is a JWT, and where do I usually send it?
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.
How is JWT authentication different from server sessions?
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.
What are the three parts of a JWT (header, payload, signature)?
A JWT is three Base64URL-encoded parts separated by dots:
header.payload.signature
The header describes how it was signed, the payload contains claims (like sub, exp, aud), and the signature lets the server detect tampering.
Is a JWT encrypted, and can people read what’s inside?
No. Standard JWTs are usually signed, not encrypted.
- Signing proves integrity (it wasn’t modified) and authenticity (issued by a trusted signer).
- Anyone who obtains the token can Base64URL-decode and read the header and payload.
If you need confidentiality, consider JWE (encrypted tokens) or keep sensitive data server-side and store only an identifier in the JWT.
What does the JWT signature guarantee—and what doesn’t it guarantee?
The signature lets the server verify the token hasn’t been altered and was minted by someone with the signing key.
It does not:
- hide payload contents
- prove the user is still active (unless you check)
- automatically revoke tokens before
exp
Treat the token like a credential: if it leaks, it can often be replayed until it expires.
What are `alg` and `kid` in the JWT header, and why do they matter?
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:
- Allowlist expected algorithms; don’t accept arbitrary
algvalues. - Never accept
alg: "none". - Don’t let an untrusted
kidvalue cause unsafe key lookup behavior.
Which JWT claims should I include in the payload?
Start with standard registered claims and keep custom ones minimal.
Common registered claims:
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.
How do JWT, OAuth 2.0, and OpenID Connect relate (access tokens vs ID tokens)?
JWT is a token format; OAuth 2.0 and OpenID Connect are protocols.
Typical mapping:
- Access token: used to call an API (may be a JWT or opaque).
- ID token (OIDC): used by the client app to confirm identity (usually a JWT).
- Refresh token: used to obtain new access tokens (often opaque; treat as highly sensitive).
Important: don’t use an ID token to call an API just because it “looks like” a JWT access token.
Where should I store JWTs safely in a browser app?
For browser-based apps, common options are:
- In memory: reduces “steal it later” risk, but still vulnerable during an active XSS.
localStorage/sessionStorage: convenient, but any XSS can exfiltrate tokens.- HttpOnly Secure cookies: often safest for web because JS can’t read them, but requires CSRF protections (e.g.,
SameSite+ CSRF tokens for state-changing requests).
Whatever you choose, keep access tokens short-lived and minimize token privileges.
What checks should my API perform when validating a JWT?
At minimum, validate:
- signature (with the correct key and allowlisted algorithm)
exp(not expired)iss(expected issuer)aud(meant for your API)nbf(if present)
Also add practical guardrails:
- enforce maximum token size
- reject unexpected claim types
- allow small clock skew to avoid time drift issues