JWT: JSON Web Token কী, গঠন এবং ব্যবহার

JWT কী?

JSON Web Token (JWT) একটি উন্মুক্ত মান (RFC 7519) যা পক্ষগুলির মধ্যে JSON অবজেক্ট হিসাবে তথ্য প্রেরণের একটি কমপ্যাক্ট এবং স্ব-সম্পূর্ণ উপায় সংজ্ঞায়িত করে। JWT-তে তথ্যকে claims বলা হয় — বিষয় (ব্যবহারকারী) এবং অতিরিক্ত বৈশিষ্ট্য সম্পর্কে বিবৃতি। প্রতিটি claim একটি কী-ভ্যালু জোড়া: ব্যবহারকারী শনাক্তকারী, ভূমিকা, মেয়াদ শেষ হওয়ার সময়, ইস্যুকারী।

JWT-কে স্ব-সম্পূর্ণ বলা হয় কারণ যাচাইকরণের জন্য সমস্ত প্রয়োজনীয় তথ্য টোকেনের ভিতরেই থাকে। টোকেনের বৈধতা যাচাই করতে সার্ভারের ডেটাবেস বা বাহ্যিক স্টোরেজ অ্যাক্সেস করার প্রয়োজন নেই — শুধুমাত্র স্বাক্ষর পরীক্ষা করতে হবে। এই বৈশিষ্ট্য JWT-কে বিতরণকৃত সিস্টেম এবং মাইক্রোসার্ভিস আর্কিটেকচারের জন্য আদর্শ করে তোলে, যেখানে একাধিক পরিষেবাকে ভাগ করা সেশন স্টোরেজ ছাড়াই অনুরোধ প্রমাণীকরণ করতে হয়।

Auth0, 2025 অনুসারে, 65% এরও বেশি মোবাইল এবং ওয়েব অ্যাপ্লিকেশন API প্রমাণীকরণের জন্য JWT-কে প্রাথমিক টোকেন ফর্ম্যাট হিসাবে ব্যবহার করে, যা অস্বচ্ছ টোকেন এবং সেশন শনাক্তকারীকে ছাড়িয়ে গেছে।

JWT গঠন: header, payload এবং signature

JWT তিনটি অংশ নিয়ে গঠিত যা বিন্দু দ্বারা পৃথক: header.payload.signature। প্রতিটি অংশ একটি Base64url-এনকোডেড JSON। আসুন প্রতিটি অংশ বিস্তারিতভাবে পরীক্ষা করি।

Header — অ্যালগরিদম এবং টোকেন প্রকার

Header-এ দুটি বাধ্যতামূলক ফিল্ড থাকে: alg (algorithm — স্বাক্ষর অ্যালগরিদম) এবং typ (type — টোকেন প্রকার, সর্বদা “JWT”)। অ্যালগরিদম সিমেট্রিক (HS256 — SHA-256 সহ HMAC) বা অ্যাসিমেট্রিক (RS256 — SHA-256 সহ RSA, ES256 — P-256 সহ ECDSA) হতে পারে। অ্যাসিমেট্রিক অ্যালগরিদম পছন্দনীয় কারণ তারা ক্লায়েন্টকে গোপন কী না রেখেই স্বাক্ষর যাচাই করতে দেয়।

একটি ডিকোড করা header-এর উদাহরণ:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-id-1"
}

Payload — claims এবং ডেটা

Payload-এ claims থাকে — বিষয় সম্পর্কে বিবৃতি। Claims তিন প্রকারে বিভক্ত: নিবন্ধিত (iss, sub, aud, exp, nbf, iat, jti), পাবলিক (ডেভেলপার দ্বারা IANA রেজিস্ট্রিতে সংজ্ঞায়িত), এবং প্রাইভেট (পক্ষগুলির মধ্যে সম্মত)। sub (subject) অনন্য ব্যবহারকারী শনাক্তকারী। exp (expiration) টোকেনের মেয়াদ শেষ হওয়ার টাইমস্ট্যাম্প। iss (issuer) টোকেন ইস্যুকারী।

{
  "sub": "user-abc-123",
  "iss": "https://auth.example.com",
  "aud": "my-mobile-app",
  "exp": 1812345678,
  "iat": 1812342078,
  "role": "premium_user"
}

Signature — অখণ্ডতা যাচাইকরণ

Signature গোপন বা প্রাইভেট কী ব্যবহার করে header এবং payload-এর সংযোগে স্বাক্ষর অ্যালগরিদম প্রয়োগ করে তৈরি করা হয়। সূত্র: HMAC-এর জন্য HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret), বা অ্যাসিমেট্রিক অ্যালগরিদমের জন্য RSASHA256(...)। প্রাপক একইভাবে স্বাক্ষর গণনা করে এবং প্রাপ্ত স্বাক্ষরের সাথে তুলনা করে — যদি তারা মেলে, ডেটা পরিবর্তন করা হয়নি।

JWT কীভাবে কাজ করে: তৈরি এবং যাচাইকরণ

JWT-এর সাথে কাজের প্রক্রিয়া দুটি ধাপ নিয়ে গঠিত: প্রমাণীকরণ সার্ভার দ্বারা টোকেন তৈরি (ইস্যু) এবং ক্লায়েন্ট বা রিসোর্স সার্ভার দ্বারা টোকেন যাচাইকরণ। প্রমাণীকরণ সার্ভার ব্যবহারকারীর পরিচয়পত্র গ্রহণ করে, claims সহ payload তৈরি করে এবং স্বাক্ষর করে। ফলস্বরূপ JWT লগইন অনুরোধের উত্তরে বা OAuth 2.0 / OpenID Connect প্রতিক্রিয়া বডিতে ক্লায়েন্টকে পাঠানো হয়।

মোবাইল প্রমাণীকরণে JWT

মোবাইল অ্যাপ্লিকেশনে, JWT নিম্নলিখিতভাবে ব্যবহৃত হয়: সফল লগইনের পরে, ব্যবহারকারী JWT ফর্ম্যাটে একটি অ্যাক্সেস টোকেন পায়। অ্যাপ্লিকেশনটি এটি একটি নিরাপদ স্টোরেজে (iOS-এ Keychain, Android-এ EncryptedSharedPreferences) সংরক্ষণ করে। প্রতিটি API অনুরোধের সাথে, অ্যাপ্লিকেশনটি Authorization: Bearer <token> হেডার যোগ করে। API সার্ভার JWT স্বাক্ষর যাচাই করে, claims বের করে এবং সেগুলির ভিত্তিতে অ্যাক্সেস সিদ্ধান্ত নেয় — ডেটাবেস কোয়েরি না করেই।

Google Codelabs, 2025 অনুসারে, Firebase Authentication-এ JWT ব্যবহার সেশন টোকেনের তুলনায় প্রমাণীকরণ সার্ভারে অনুরোধের সংখ্যা 40–60% কমিয়ে দেয়, কারণ ডেটা প্রতিটি মাইক্রোসার্ভিসে স্থানীয়ভাবে যাচাই করা হয়। এটি উচ্চ-লোড আর্কিটেকচারের জন্য বিশেষভাবে গুরুত্বপূর্ণ, যেখানে বিলম্বের প্রতিটি মিলিসেকেন্ড ব্যবহারকারীর অভিজ্ঞতাকে প্রভাবিত করে। প্রতি মিনিটে 50,000 অনুরোধে, JWT-তে স্যুইচ করলে ইন্ট্রোস্পেকশন অনুরোধগুলি পরিচালনা করা 10টি সার্ভার ইনস্ট্যান্স পর্যন্ত বাঁচানো যায়।

JWT বনাম Session Token

JWT এবং Session Token একই সমস্যার সমাধান করে — অনুরোধ প্রমাণীকরণ — কিন্তু আর্কিটেকচারে মৌলিকভাবে ভিন্ন। Session Token একটি এলোমেলো শনাক্তকারী স্ট্রিং যা সার্ভারে সংরক্ষিত সেশন ডেটাকে নির্দেশ করে (stateful)। JWT একটি স্ব-সম্পূর্ণ টোকেন যা নিজের মধ্যে সমস্ত ডেটা ধারণ করে (stateless)।

JWT-এর সুবিধা এবং অসুবিধা

JWT বিতরণকৃত সিস্টেমে জয়ী হয়: মাইক্রোসার্ভিসগুলি ভাগ করা স্টোরেজ ছাড়াই স্থানীয়ভাবে টোকেন যাচাই করতে পারে। উদাহরণস্বরূপ, পাঁচটি মাইক্রোসার্ভিসের আর্কিটেকচারে, প্রতিটি পরিষেবা নেটওয়ার্ক কল ছাড়াই 1–2 মিলিসেকেন্ডে JWT যাচাই করে, যেখানে session Token-এর প্রতিটি অনুরোধে একটি কেন্দ্রীয় Redis কোয়েরির প্রয়োজন হয়, যা 10–30 মিলিসেকেন্ড বিলম্ব যোগ করে। তবে, JWT বাতিল করা কঠিন — একবার ইস্যু হয়ে গেলে, এটি মেয়াদ শেষ না হওয়া পর্যন্ত বৈধ থাকে। Session Token DB বা Redis থেকে রেকর্ড মুছে সহজেই বাতিল করা যায়।

মোবাইল অ্যাপ্লিকেশনের জন্য, একটি সম্মিলিত পদ্ধতি — সংক্ষিপ্ত আয়ু (15–30 মিনিট) সহ JWT এবং Refresh Token — কর্মক্ষমতা এবং নিরাপত্তার মধ্যে ভারসাম্য প্রদান করে। JWT API অ্যাক্সেসের জন্য ব্যবহৃত হয়, যখন refresh token (সাধারণত অস্বচ্ছ) নতুন JWT পাওয়ার জন্য ব্যবহৃত হয়। যদি JWT-এর সাথে আপস করা হয়, আক্রমণকারীর 15–30 মিনিটের জন্য অ্যাক্সেস থাকে; যদি refresh token-এর সাথে আপস করা হয়, তাহলে রোটেশন এবং পুনঃব্যবহার সনাক্তকরণের মাধ্যমে সেশন ব্লক করা হয়।

JWT নিরাপত্তা

JWT-এর নিরাপত্তা সঠিক বাস্তবায়নের উপর নির্ভর করে। সবচেয়ে সাধারণ দুর্বলতা হল “alg none” আক্রমণ: আক্রমণকারী টোকেনের header পরিবর্তন করে “alg”: “none” করে, এবং সার্ভার অ্যালগরিদম যাচাই না করেই জাল টোকেন গ্রহণ করে। সুরক্ষা: সর্বদা পরীক্ষা করুন যে header-এর অ্যালগরিদম প্রত্যাশিত (RS256, ES256) এর সাথে মেলে, এবং alg: none সহ টোকেন প্রত্যাখ্যান করুন।

সাধারণ দুর্বলতা

JWT দুর্বলতা এর মধ্যে আরও রয়েছে: HMAC-এর জন্য দুর্বল গোপন কী (মিনিটের মধ্যে ব্রুট-ফোর্স), প্রাইভেট কী ফাঁস (সার্ভারের পক্ষে যেকোনো ডেটা স্বাক্ষর করা), payload-এ সংবেদনশীল ডেটা সংরক্ষণ (JWT এনক্রিপ্ট করে না, শুধুমাত্র স্বাক্ষর করে), JWK header ইনজেকশন আক্রমণ (কাস্টম পাবলিক কী ইনজেক্ট করা)। বিশ্বস্ত লাইব্রেরি — Nimbus JOSE + JWT, jjwt (io.jsonwebtoken), PyJWT — ব্যবহার করা এই দুর্বলতাগুলি শোষণের ঝুঁকি হ্রাস করে।

একটি অতিরিক্ত নিরাপত্তা ব্যবস্থা হল JWK Thumbprint (RFC 7638): header-এ থাম্বপ্রিন্টের মাধ্যমে টোকেনের সাথে একটি পাবলিক কী বাঁধা। যদি সার্ভার প্রতিটি ক্লায়েন্টের জন্য প্রত্যাশিত থাম্বপ্রিন্ট সংরক্ষণ করে, তাহলে JWK header ইনজেকশন অসম্ভব হয়ে যায় — সার্ভার যেকোনো কী প্রত্যাখ্যান করে যা নিবন্ধিত কী-এর সাথে মেলে না। OAuth Security Workshop 2025 আর্থিক এবং চিকিৎসা অ্যাপ্লিকেশনে ব্যবহৃত সমস্ত JWT-এর জন্য JWK Thumbprint বাধ্যতামূলক সুরক্ষা হিসাবে সুপারিশ করে।

কোড উদাহরণ: Kotlin-এ JWT নিয়ে কাজ করা

jjwt লাইব্রেরি (auth0/java-jwt) Android অ্যাপ্লিকেশনে কয়েক লাইনে JWT তৈরি এবং যাচাই করার অনুমতি দেয়। নীচের উদাহরণে, সার্ভার sub এবং role সহ একটি টোকেন তৈরি করে, এবং ক্লায়েন্ট স্বাক্ষর যাচাই করে। সার্ভারে গোপন কী-এর নিরাপদ স্টোরেজের জন্য, পরিবেশ পরিবর্তনশীল বা HSM (হার্ডওয়্যার সিকিউরিটি মডিউল) ব্যবহার করুন — কোড বা কনফিগারেশন ফাইলে কী সংরক্ষণ করা একটি গুরুতর নিরাপত্তা ত্রুটি।

JWT জেনারেশন

val secret = "my-256-bit-secret-key-here"
val token = JWT.create()
    .withSubject("user-abc-123")
    .withIssuer("auth.example.com")
    .withClaim("role", "premium_user")
    .withExpiresAt(Date(System.currentTimeMillis() + 3600000))
    .sign(Algorithm.HMAC256(secret))

// ক্লায়েন্টের কাছে টোকেন পাঠানো
println("JWT: $token")

JWT যাচাইকরণ

fun verifyToken(token: String): Boolean {
    return try {
        val decoded = JWT.require(Algorithm.HMAC256(secret))
            .withIssuer("auth.example.com")
            .build()
            .verify(token)
        // স্বাক্ষর বৈধ, claims বের করা হয়েছে
        println("Subject: ${decoded.subject}")
        true
    } catch (e: Exception) {
        println("টোকেন অবৈধ: ${e.message}")
        false
    }
}