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 ایک بے ترتیب شناخت کنندہ سٹرنگ ہے جو سرور پر ذخیرہ کردہ سیشن ڈیٹا کا حوالہ دیتی ہے (حالت دار)۔ JWT ایک خود مکمل ٹوکن ہے جو تمام ڈیٹا کو اپنے اندر رکھتا ہے (بے حالت)۔

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 میں انگوٹھے کے نشان (thumbprint) کے ذریعے ٹوکن سے عوامی کلید منسلک کرنا۔ اگر سرور ہر کلائنٹ کے لیے متوقع انگوٹھے کا نشان محفوظ کرتا ہے، تو 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
    }
}