JWT

2টি টুল

JWT EncoderCreate and sign JSON Web Tokens with HS256, HS384, HS512 JWT DecoderDecode and inspect JSON Web Tokens

ওয়েব নিরাপত্তার মূল বিষয়

ওয়েব নিরাপত্তা হল ওয়েব অ্যাপ্লিকেশন ও API-কে অননুমোদিত প্রবেশাধিকার, ডেটা লঙ্ঘন এবং আক্রমণ থেকে রক্ষা করার পদ্ধতি। আধুনিক অ্যাপ্লিকেশনগুলি নিরাপত্তার সীমানা কার্যকর করতে প্রমাণীকরণ (আপনি কে তা প্রমাণ করা), অনুমোদন (আপনি কী করতে পারেন তা প্রমাণ করা) এবং ক্রিপ্টোগ্রাফি ব্যবহার করে।

JSON Web Token (JWT) হল আধুনিক ওয়েব ডেভেলপমেন্টে সবচেয়ে প্রচলিত স্টেটলেস প্রমাণীকরণ পদ্ধতি। JWT কীভাবে কাজ করে — এর কাঠামো, সাইনিং অ্যালগরিদম এবং দুর্বলতাসহ — তা বোঝা নিরাপদ API ও অ্যাপ্লিকেশন তৈরির জন্য অপরিহার্য।

JSON Web Token (JWT)

JWT হল দুটি পক্ষের মধ্যে দাবি উপস্থাপনের একটি সংক্ষিপ্ত, URL-safe উপায়। এটি ডট দিয়ে আলাদা তিনটি Base64url-এনকোড করা অংশ নিয়ে গঠিত। signature সম্পূর্ণ token কভার করে বলে ডেটাবেস অনুসন্ধান ছাড়াই JWT যাচাই করা যায়।

JWT-এর তিনটি অংশ

Header

token সম্পর্কে মেটাডেটা ধারণ করে: সাইনিং অ্যালগরিদম (alg) এবং token-এর ধরন (typ)। সবসময় Base64url-এনকোড করা JSON। এখানে অ্যালগরিদমের পছন্দ সম্পূর্ণ token-এর নিরাপত্তাকে প্রভাবিত করে।

এনকোড করা

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

ডিকোড করা

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

দাবিগুলি ধারণ করে: ব্যবহারকারী সম্পর্কে বিবৃতি এবং অতিরিক্ত মেটাডেটা। এটিও Base64url-এনকোড করা JSON। যে কেউ এটি ডিকোড করতে পারে — payload ডেটা এনক্রিপ্ট নয়, শুধুমাত্র সাইন করা।

এনকোড করা

eyJzdWIiOiJ1c2VyXzEyMyIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTcxNzIwMDAwMH0

ডিকোড করা

{
  "sub": "user_123",
  "role": "admin",
  "exp": 1717200000
}

Signature

এনকোড করা header ও payload-এর উপর একটি ক্রিপ্টোগ্রাফিক signature। এই signature যাচাই করলে নিশ্চিত হয় যে token-এ কোনো পরিবর্তন করা হয়নি। গোপন কী (HMAC) বা private key (RSA/ECDSA) কখনো token-এ অন্তর্ভুক্ত থাকে না।

এনকোড করা

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

ডিকোড করা

HMACSHA256(
  base64url(header) + "." +
  base64url(payload),
  secret
)

JWT-এর স্ট্যান্ডার্ড দাবিসমূহ

JWT স্পেসিফিকেশন স্ট্যান্ডার্ড দাবির নাম নির্ধারণ করে। এগুলি ব্যবহার করলে বিভিন্ন JWT লাইব্রেরি ও পরিষেবার মধ্যে ইন্টারঅপারেবিলিটি নিশ্চিত হয়:

দাবি	নাম	বিবরণ
iss	Issuer	token ইস্যুকারী পক্ষ চিহ্নিত করে (যেমন, আপনার auth সার্ভারের URL)
sub	Subject	token-এর বিষয়বস্তু হওয়া পক্ষ চিহ্নিত করে (যেমন, ব্যবহারকারীর ID)
aud	Audience	token যাদের জন্য নির্ধারিত তাদের চিহ্নিত করে (যেমন, আপনার API URL)
exp	Expiration	Unix timestamp যার পরে token প্রক্রিয়াকরণের জন্য গ্রহণ করা উচিত নয়
nbf	Not Before	Unix timestamp যার আগে token প্রক্রিয়াকরণের জন্য গ্রহণ করা উচিত নয়
iat	Issued At	Unix timestamp যখন token ইস্যু করা হয়েছিল — বয়স নির্ধারণে ব্যবহৃত
jti	JWT ID	token-এর অনন্য পরিচয়কারী, token রিপ্লে আক্রমণ প্রতিরোধে ব্যবহৃত

সাইনিং অ্যালগরিদম

সাইনিং অ্যালগরিদম JWT header-এ ঘোষণা করা হয়। আপনার ব্যবহারের ক্ষেত্রে সঠিক অ্যালগরিদম বেছে নেওয়া নিরাপত্তার জন্য অপরিহার্য:

HS256 / HS384 / HS512সিমেট্রিক (HMAC)

সাইনিং ও যাচাইয়ের জন্য একটি ভাগ করা গোপন কী ব্যবহার করে। বাস্তবায়ন সহজ কিন্তু সব যাচাইকারীকে গোপন কী জানতে হয়।

কখন ব্যবহার করবেন: অভ্যন্তরীণ পরিষেবায় যেখানে আপনি সব পক্ষ নিয়ন্ত্রণ করেন। তৃতীয় পক্ষের token যাচাই প্রয়োজন হলে কখনো ব্যবহার করবেন না।

RS256 / RS384 / RS512অ্যাসিমেট্রিক (RSA)

সাইনিংয়ে private key এবং যাচাইয়ে public key ব্যবহার করে। private key কখনো auth সার্ভার ছাড়ে না।

কখন ব্যবহার করবেন: মাইক্রোসার্ভিস আর্কিটেকচার, তৃতীয় পক্ষের token যাচাই, OAuth2 ও OpenID Connect।

ES256 / ES384 / ES512অ্যাসিমেট্রিক (ECDSA)

RSA-র মতো কিন্তু ছোট কী এবং দ্রুততর সাইনিং সহ। সমতুল্য নিরাপত্তা ও ভালো কার্যক্ষমতা প্রদান করে।

কখন ব্যবহার করবেন: মোবাইল ও IoT অ্যাপ্লিকেশনে যেখানে কার্যক্ষমতা গুরুত্বপূর্ণ। RSA-র আধুনিক বিকল্প।

"alg": "none"স্বাক্ষরহীন — বিপজ্জনক

কোনো signature নেই। alg:none সহ একটি token-এর কোনো অখণ্ডতার নিশ্চয়তা নেই এবং যে কেউ এটি জাল করতে পারে।

কখন ব্যবহার করবেন: প্রোডাকশনে কখনো ব্যবহার করবেন না। কিছু JWT লাইব্রেরি ঐতিহাসিকভাবে alg:none গ্রহণ করত, যা গুরুতর দুর্বলতার দিকে নিয়ে গিয়েছিল।

প্রমাণীকরণ প্রবাহ

পাসওয়ার্ড গ্রান্ট (সরাসরি)

1.ব্যবহারকারী লগইন এন্ডপয়েন্টে ব্যবহারকারীর নাম ও পাসওয়ার্ড জমা দেন
2.সার্ভার ব্যবহারকারী ডেটাবেসের বিপরীতে শংসাপত্র যাচাই করে
3.সার্ভার ব্যবহারকারীর দাবি ও মেয়াদোত্তীর্ণের সময়সহ একটি JWT সাইন করে
4.ক্লায়েন্ট JWT সংরক্ষণ করে (localStorage, cookie, বা মেমোরিতে)
5.ক্লায়েন্ট পরবর্তী অনুরোধের জন্য Authorization: Bearer header-এ JWT পাঠায়

অথরাইজেশন কোড + PKCE (OAuth2)

1.ক্লায়েন্ট কোড চ্যালেঞ্জসহ ব্যবহারকারীকে অথরাইজেশন সার্ভারে রিডাইরেক্ট করে
2.ব্যবহারকারী প্রমাণীকরণ করেন এবং ক্লায়েন্ট অ্যাপ্লিকেশনকে অনুমোদন দেন
3.auth সার্ভার একটি একক-ব্যবহারযোগ্য অথরাইজেশন কোডসহ ফিরে রিডাইরেক্ট করে
4.ক্লায়েন্ট কোড + ভেরিফায়ার বিনিময় করে access ও refresh token পায়
5.ক্লায়েন্ট API কলের জন্য access token এবং নবায়নের জন্য refresh token ব্যবহার করে

JWT-এর সাধারণ দুর্বলতাসমূহ

সঠিকভাবে বাস্তবায়িত হলে JWT নিরাপদ। এগুলি সবচেয়ে সাধারণ বাস্তবায়নের ভুল যা নিরাপত্তা দুর্বলতার দিকে নিয়ে যায়:

অ্যালগরিদম বিভ্রান্তি (alg:none)গুরুতর

কিছু লাইব্রেরি alg:none (কোনো signature নেই) সহ token গ্রহণ করে। একজন আক্রমণকারী payload পরিবর্তন করে alg-কে none সেট করে যেকোনো JWT জাল করতে পারে। সবসময় অনুমোদিত অ্যালগরিদম স্পষ্টভাবে নির্দিষ্ট ও যাচাই করুন।

HS256 / RS256 বিভ্রান্তিগুরুতর

যদি একটি লাইব্রেরি RS256 যাচাই করার প্রত্যাশিত হয় কিন্তু HS256 গ্রহণ করে, তবে একজন আক্রমণকারী HMAC সিক্রেট হিসেবে public key ব্যবহার করে একটি token সাইন করতে পারে। লাইব্রেরি সফলভাবে এটি যাচাই করে। সবসময় প্রত্যাশিত অ্যালগরিদম নির্দিষ্ট করুন।

মেয়াদোত্তীর্ণ যাচাইয়ের অনুপস্থিতিউচ্চ

exp দাবি ছাড়া একটি JWT, বা exp যাচাই না করা কোড, ব্যবহারকারী লগআউট বা নিষিদ্ধ হওয়ার পরেও token অনির্দিষ্টকালের জন্য ব্যবহারের অনুমতি দেয়। সবসময় ছোট মেয়াদোত্তীর্ণের সময় নির্ধারণ করুন এবং exp দাবি যাচাই করুন।

payload-এ সংবেদনশীল ডেটাউচ্চ

JWT payload Base64-এনকোড করা, এনক্রিপ্ট নয়। যে কেউ একটি JWT আটকে দিয়ে payload ডিকোড ও পড়তে পারে। JWT দাবিতে কখনো পাসওয়ার্ড, ক্রেডিট কার্ড নম্বর বা অন্যান্য গোপন তথ্য সংরক্ষণ করবেন না।

দুর্বল গোপন কী (HS256)মাঝারি

ছোট বা পূর্বানুমানযোগ্য সিক্রেট দিয়ে HMAC-সাইন করা JWT অফলাইনে ব্রুট-ফোর্স করা যায়। একজন আক্রমণকারী যিনি একটি JWT পান তিনি প্রতি সেকেন্ডে কোটি কোটি কী চেষ্টা করতে পারেন। কমপক্ষে ২৫৬ বিটের ক্রিপ্টোগ্রাফিকভাবে র্যান্ডম সিক্রেট ব্যবহার করুন।

signature যাচাইয়ের অনুপস্থিতিমাঝারি

signature যাচাই না করে JWT গ্রহণ করা payload-কে সম্পূর্ণ বিশ্বাস করে। এটি একটি গুরুতর বাগ যা যেকোনো ব্যবহারকারীকে যেকোনো দাবি তৈরি করার সুযোগ দেয়। যেকোনো দাবি বিশ্বাস করার আগে সবসময় signature যাচাই করুন।

প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

JWT কি এনক্রিপ্ট করা?

স্ট্যান্ডার্ড JWT (JWS — JSON Web Signature) সাইন করা কিন্তু এনক্রিপ্ট নয়। payload Base64url-এনকোড করা, যা সহজেই উল্টানো যায়। যে কেউ একটি JWT পেলে এর বিষয়বস্তু পড়তে পারে। JWE (JSON Web Encryption) এনক্রিপশন প্রদান করে, কিন্তু এটি অনেক কম প্রচলিত।

JWT কতদিন বৈধ থাকা উচিত?

access token স্বল্পকালীন হওয়া উচিত: সাধারণত ৫–৬০ মিনিট। দীর্ঘস্থায়ী token বিপজ্জনক কারণ token ব্লকলিস্ট ছাড়া এগুলি বাতিল করা যায় না। নতুন access token পেতে refresh token (দীর্ঘস্থায়ী, নিরাপদে সংরক্ষিত) ব্যবহার করুন।

ব্রাউজারে JWT কোথায় সংরক্ষণ করা উচিত?

HttpOnly cookie সবচেয়ে নিরাপদ বিকল্প — এগুলি JavaScript থেকে অ্যাক্সেস করা যায় না, XSS চুরি প্রতিরোধ করে। localStorage XSS আক্রমণের প্রতি দুর্বল কিন্তু CSRF এড়ায়। মেমোরি (JavaScript ভেরিয়েবল) সবচেয়ে নিরাপদ কিন্তু পেজ রিফ্রেশে টিকে থাকে না। কোনো নিখুঁত বিকল্প নেই।

মেয়াদ শেষ হওয়ার আগে JWT বাতিল করা যায়?

সার্ভার-সাইড স্টেট ছাড়া নয়। JWT-এর স্টেটলেস প্রকৃতির মানে সার্ভার এগুলি অবৈধ করতে পারে না। সমাধান: ছোট মেয়াদোত্তীর্ণের সময়, token ব্লকলিস্ট (Redis), রোটেটিং refresh token, বা সংবেদনশীল অপারেশনের জন্য opaque সেশন token-এ স্যুইচ করা।

JWT ও সেশন cookie-র মধ্যে পার্থক্য কী?

সেশন cookie একটি র্যান্ডম সেশন ID সংরক্ষণ করে; সার্ভার সেশন ডেটা খোঁজে। JWT স্ব-সম্পূর্ণ — সার্ভার ডেটাবেস অনুসন্ধান ছাড়াই signature যাচাই করে। JWT একাধিক সার্ভারে ভালো স্কেল করে কিন্তু অতিরিক্ত অবকাঠামো ছাড়া বাতিল করা যায় না।

JWT-এ কোন দাবিগুলি অন্তর্ভুক্ত করা উচিত?

ন্যূনতম: sub (ব্যবহারকারীর ID), exp (মেয়াদোত্তীর্ণ), এবং iat (ইস্যু করার সময়)। মাল্টি-সার্ভিস সেটআপের জন্য iss (ইস্যুকারী) যোগ করুন। payload ছোট রাখুন — প্রতিটি অনুরোধের সাথে JWT পাঠানো হয়। সংবেদনশীল ডেটা বা বড় প্রোফাইল অবজেক্ট অন্তর্ভুক্ত করবেন না।

RS256 কি HS256-এর চেয়ে ভালো?

RS256 (অ্যাসিমেট্রিক) বেশিরভাগ প্রোডাকশন সিস্টেমের জন্য ভালো কারণ শুধুমাত্র auth সার্ভারের private key দরকার। একাধিক পরিষেবা গোপন তথ্য ভাগ না করেই public key ব্যবহার করে token যাচাই করতে পারে। HS256 সহজ কিন্তু সব যাচাইকারীকে ভাগ করা সিক্রেট জানতে হয়।

PKCE কী এবং এটি কেন গুরুত্বপূর্ণ?

PKCE (Proof Key for Code Exchange) হল OAuth2 অথরাইজেশন কোড প্রবাহের একটি এক্সটেনশন যা অথরাইজেশন কোড আটকানোর আক্রমণ প্রতিরোধ করে। পাবলিক ক্লায়েন্টের (SPA, মোবাইল অ্যাপ) জন্য এটি প্রয়োজনীয় যারা নিরাপদে client secret সংরক্ষণ করতে পারে না।