پروڈکشن میں آپ کی تصدیق (authentication) ٹوٹ گئی ہے۔ صارفین کو "Invalid Token” کی خرابیاں مل رہی ہیں، اور آپ کو جلد از جلد وجہ معلوم کرنی ہے۔ آپ JWT کو کھولتے ہیں، تو وہ بے معنی الفاظ کی طرح لگتا ہے: نقطوں سے الگ تین بلاکس۔ ڈیٹا وہیں موجود ہے، مگر ایک parser کے بغیر آپ اسے پڑھ نہیں سکتے۔
ایک JWT Parser ایک خاص ٹول ہے جو JSON Web Token کے تین حصوں — Header، Payload، اور Signature — کو RFC 7519 معیار کے مطابق تقسیم کرتا ہے۔ اپریل 2026 تک، یہ parsers Base64URL-encoded ڈیٹا کو ڈی کوڈ کرتے ہیں اور signatures کو secrets یا public keys کے ذریعے تصدیق دیتے ہیں تاکہ یقین ہو سکے کہ ٹوکن میں رد و بدل نہیں کیا گیا، اور "alg: none” جیسے خطرات کو روکتے ہیں۔
ایک JWT Parser دراصل کیا کرتا ہے
JWT parser کو ایک ترجمان سمجھیں۔ یہ ایک طویل، غیر شفاف string لیتا ہے اور اسے دوبارہ پڑھنے کے قابل JSON اشیاء میں بدل دیتا ہے۔ یہ جدید ایپلیکیشنز میں صارف کی شناخت کو منظم کرنے اور ڈیٹا کے تبادلے کو محفوظ بنانے کے لیے بنیادی اہمیت رکھتا ہے۔
اندرونی طور پر، parser دو نقطوں (.) کو تلاش کرتا ہے جو ٹوکن کو تین حصوں میں تقسیم کرتے ہیں:
| Section | مقصد | Encoded? | Key کے بغیر پڑھنے کے قابل؟ |
|---|---|---|---|
| Header | میٹا ڈیٹا: signing algorithm (HS256, RS256) | Base64URL | ہاں |
| Payload | Claims: صارف ڈیٹا، ختم ہونے کا وقت، کردار | Base64URL | ہاں |
| Signature | اصل کی ثبوت دینے والا ڈیجیٹل مہر | HMAC/RSA | نہیں — key درکار ہے |
مرحلہ وار ڈی کوڈنگ: اندر کیا ہوتا ہے
آئیے ایک حقیقی ٹوکن کا جائزہ لیں۔ اس مثالی JWT کو دیکھیں:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4iLCJpYXQiOjE3MDAwMDAwMDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
مرحلہ 1: نقطوں پر تقسیم کریں
[0] eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
[1] eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4iLCJpYXQiOjE3MDAwMDAwMDB9
[2] SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
مرحلہ 2: Base64URL-decode حصہ [0] (Header)
{
"alg": "HS256",
"typ": "JWT"
}
مرحلہ 3: Base64URL-decode حصہ [1] (Payload)
{
"sub": "1234567890",
"name": "John",
"iat": 1700000000
}
مرحلہ 4: حصہ [2] (Signature) کی تصدیق — secret key درکار ہے
parser Base64URL-encoded header + ".” + payload لیتا ہے، پھر secret کے ساتھ HMAC-SHA256 حساب کرتا ہے۔ اگر نتیجہ حصہ [2] سے میل کھاتا ہے، تو ٹوکن اصل ہے۔
اہم سیکیورٹی نوٹ: Base64URL انکرپشن نہیں ہے
نئے ڈویلپرز کے لیے ایک عام غلط فہمی یہ ہے کہ encoded header اور payload انکرپٹ ہیں۔ ایسا نہیں ہے۔ جیسا کہ JustUse.me وضاحت کرتا ہے، Base64URL encoding صرف JSON کو URLs اور headers کے ذریعے محفوظ طریقے سے بھیجنے کے قابل بناتی ہے۔ جس کے پاس ٹوکن ہے، وہ پاس ورڈ یا key کے بغیر payload کو ڈی کوڈ کر سکتا ہے۔
حساس ڈیٹا (پاس ورڈز، SSNs، API keys) کبھی بھی JWT payload میں محفوظ نہ کریں۔ یہ ہر اس شخص کو نظر آتا ہے جو ٹوکن کو روک لیتا ہے۔
Signature تصدیق: سیکیورٹی کا گیٹ
اگرچہ کوئی بھی ٹوکن کا ڈیٹا پڑھ سکتا ہے، signature verification وہی ہے جو آپ کے سسٹم کو واقعی محفوظ رکھتی ہے۔ ایک JWT parser صرف معلومات نہیں پڑھتا — یہ ثابت کرتا ہے کہ یہ کہاں سے آیا ہے۔
parser header، payload، اور ایک key کا استعمال کر کے signature کو دوبارہ حساب کرتا ہے، پھر چیک کرتا ہے کہ نتیجہ ٹوکن پر موجود signature سے میل کھاتا ہے یا نہیں۔ اگر میل نہیں کھاتے، تو ٹوکن میں رد و بدل کیا گیا ہے۔
دو Algorithm خاندان
| Algorithm | Key کی قسم | یہ کیسے کام کرتا ہے | عام استعمال کا معاملہ |
|---|---|---|---|
| HS256 (HMAC) | Symmetric — sign اور verify کے لیے ایک ہی secret key | دونوں فریق ایک secret شیئر کرتے ہیں | Single-service auth، ایک ہی ٹیم کے اندر microservices |
| RS256 (RSA) | Asymmetric — private key sign کرتی ہے، public key verify کرتی ہے | بھیجنے والا private key رکھتا ہے؛ public key رکھنے والا کوئی بھی verify کر سکتا ہے | OAuth2 providers، تہرے فریق API integrations |
| ES256 (ECDSA) | Asymmetric — RSA جیسا ماڈل مگر elliptic curves کے ساتھ | چھوٹے keys، تیز تصدیق | موبائل ایپس، کارکردگی حساس سروسز |
"alg: none” حملہ
یہ JWT کی سب سے خطرناک کمزوریوں میں سے ایک ہے۔ ایک حملہ آور header کو تبدیل کر کے "alg": "none" کا دعویٰ کرتا ہے اور signature ہٹا دیتا ہے۔ ایک کمزور parser اسے قبول کر سکتا ہے، اور بغیر کسی تصدیق کے ٹوکن کو درست سمجھ سکتا ہے۔
دفاع: آپ کے parser کو ہر اس ٹوکن کو صریح طور پر مسترد کرنا چاہیے جہاں algorithm "none” ہو یا آپ کی متوقع algorithm سے میل نہ کھاتا ہو۔ Stas Persiianenko، جنہوں نے Apify JWT ٹول تیار کیا، تاکید کرتے ہیں کہ اگرچہ ٹوکنز ڈیزائن کے لحاظ سے شفاف ہیں، ان کی سیکیورٹی اس بات پر منحصر ہے کہ parser غیر sign شدہ یا رد و بدل شدہ ٹوکنز کو سختی سے مسترد کرے۔
decoded = jwt.decode(token, key, algorithms=None) # NEVER do this
decoded = jwt.decode(token, key, algorithms=["HS256"])
معیاری JWT Claims: ہر فیلڈ کا مطلب
ایک JWT parser payload سے "claims” نکالتا ہے۔ یہ کراس سسٹم مطابقت کے لیے JOSE (JSON Object Signing and Encryption) framework کی پیروی کرتے ہیں۔
| Claim | مکمل نام | مقصد | مثال قدر |
|---|---|---|---|
iss |
Issuer | ٹوکن کس نے جاری کیا | "auth.example.com" |
sub |
Subject | وہ صارف یا entity جس کی نمائندگی ٹوکن کرتا ہے | "user:12345" |
aud |
Audience | ٹوکن کا مطلوبہ وصول کنندہ | "api.example.com" |
exp |
Expiration Time | جب ٹوکن غیر درست ہو جاتا ہے | 1700000000 (Unix timestamp) |
iat |
Issued At | ٹوکن کب بنایا گیا | 1699999999 |
nbf |
Not Before | ٹوکن اس وقت سے پہلے درست نہیں | 1699999999 |
jti |
JWT ID | ٹوکن کا منفرد شناخت کنندہ | "a1b2c3d4" |
جب asymmetric signatures استعمال ہوتی ہیں، تو parsers اکثر ایک JWK (JSON Web Key) کا حوالہ دیتے ہیں — ایک JSON ساخت جو public key کی نمائندگی کرتی ہے۔ parser جاری کنندہ کے metadata endpoint سے درست JWK کو خود بخود حاصل کرتا ہے تاکہ ٹوکن کی تصدیق کر سکے۔
نفاذ: پروڈکشن کے لیے حقیقی کوڈ
PHP کے ساتھ lcobucci/jwt
PHP ماحول کا معیار lcobucci/jwt ہے۔ Packagist کے ڈیٹا کے مطابق اپریل 2026 تک اس کی 322 million سے زائد انسٹالیشنز ہو چکی ہیں، جو اسے Laravel اور Symfony پروجیکٹس کا پسندیدہ انتخاب بناتی ہیں۔
use Lcobucci\JWT\Configuration;
use Lcobucci\JWT\Signer\Hmac\Sha256;
use Lcobucci\JWT\Signer\Key\InMemory;
$config = Configuration::forSymmetricSigner(
new Sha256(),
InMemory::plainText('your-secret-key')
);
// Parsing and validating a token
$token = $config->parser()->parse($jwtString);
// Verify constraints: expiration, issuer, etc.
$constraints = [
new \Lcobucci\JWT\Validation\Constraint\IssuedBy('auth.example.com'),
new \Lcobucci\JWT\Validation\Constraint\PermittedFor('api.example.com'),
new \Lcobucci\JWT\Validation\Constraint\SignedWith(
$config->signer(),
$config->signingKey()
),
];
$isValid = $config->validator()->validate($token, ...$constraints);
Hono (Edge/Serverless) Web Crypto کے ساتھ
ہلکے پھلکے edge ایپلیکیشنز کے لیے، Hono JWT Helper ایک مختصر decode() فنکشن فراہم کرتا ہے جو serverless پلیٹ فارمز کے لیے بہترین ہے جہاں آپ کو تیز cold starts اور کم dependencies درکار ہوں۔
import { jwt } from 'hono/jwt'
// Middleware to verify JWT on every request
app.use('/api/*', jwt({ secret: 'your-secret' }))
// Access decoded claims in your handler
app.get('/api/profile', (c) => {
const payload = c.get('jwtPayload')
return c.json({ user: payload.sub })
})
MCP کے ساتھ AI سے چلائی جانے والی JWT تجزیہ
2026 تک، Model Context Protocol (MCP) Claude Code یا Cursor جیسے AI معاونین کو براہ راست JWT ٹولز سے بات کرنے کے قابل بناتا ہے۔ ایک MCP server سیٹ اپ کریں، اور ایک ڈویلپر AI سے کہہ سکتا ہے کہ "ان logs میں تمام JWTs کو ختم ہونے کی خرابیوں کے لیے چیک کرو” — agent کمانڈ لائن کے ذریعے parsing سنبھال لیتا ہے۔
Apify کے مطابق، 2026 تک بلک پروسیسنگ کی لاگت تقریباً $11.50 فی 10,000 tokens ہے۔ یہ خودکاری AI agents کو ختم ہو چکے ٹوکنز تلاش کرنے اور فوراً ایپ کی سیکیورٹی ترتیبات کے لیے کوڈ کے حل تجویز کرنے کے قابل بناتی ہے۔
نتیجہ
ایک JWT parser صرف ڈیبگنگ کی سہولت سے زیادہ ہے — یہ ایک اہم سیکیورٹی چیک پوائنٹ ہے۔ یہ signature checks کے ذریعے یقین دلاتا ہے کہ ٹوکنز اصل ہیں اور claim verification کے ذریعے درست ہیں۔ وہ دو اصول یاد رکھیں جو سب سے زیادہ اہم ہیں: Base64URL انکرپشن نہیں ہے، اس لیے secrets کو payload میں ہرگز نہ رکھیں۔ اور "alg: none” حملوں سے بچنے کے لیے ہمیشہ صریح طور پر allowed algorithms بیان کریں۔
پروڈکشن ایپس کے لیے، اپنا parser بنانے کے بجائے ثابت شدہ لائبریریاں جیسے lcobucci/jwt یا Hono کا JWT helper استعمال کریں۔ ڈیبگنگ اور بلک تجزیے کے لیے، AI سے چلنے والے MCP ٹولز سیکیورٹی آڈٹس کو خودکار اور جامع رکھنے کا جدید طریقہ ہیں۔
FAQ
کیا میرے براؤزر میں ملنے والا JWT ٹوکن ڈی کوڈ کرنا قانونی ہے؟
ہاں، یہ مکمل طور پر قانونی ہے۔ JWTs شفاف ہونے کے لیے ڈیزائن کیے گئے ہیں — header اور payload نقل کے لیے encode کیے جاتے ہیں، رازداری کے لیے انکرپٹ نہیں۔ ٹوکن کا حامل ہونا اس بات کا اشارہ ہے کہ آپ کے پاس اس کے claims میں ڈیٹا تک رسائی ہے۔ تاہم، جب ٹوکنز میں ذاتی معلومات ہوں تو ہمیشہ GDPR جیسے مقامی ڈیٹا تحفظ کے قوانین کی پاسداری کریں۔
میرا JWT parser ایک ایسے ٹوکن کے لیے جو میں نے ابھی بنایا ہے، isExpired: true کیوں دکھاتا ہے؟
یہ عموماً ٹوکن بنانے والے server اور اسے parse کرنے والے سسٹم کے درمیان clock drift کی وجہ سے ہوتا ہے۔ اگر دونوں سسٹمز کی گھڑیاں (UTC/NTP کے ذریعے) ہم وقت نہیں ہیں، تو exp یا nbf claims غیر درست نظر آنے لگتی ہیں۔ اسے اس طرح دور کریں کہ دونوں سسٹمز وقت کی ہم آہنگی کے لیے NTP استعمال کریں، یا اپنی parsing لائبریری میں ایک مختصر "leeway” (عموماً 60 seconds) شامل کریں تاکہ معمولی فرق کا حساب رہے۔
کیا میں secret یا public key کے بغیر JWT ڈی کوڈ کر سکتا ہوں؟
ہاں، آپ ہمیشہ key کے بغیر Header اور Payload کو ڈی کوڈ کر کے پڑھ سکتے ہیں کیونکہ وہ محض Base64URL-encoded JSON ہیں۔ تاہم، آپ متعلقہ secret (HS256 کے لیے) یا public key (RS256 کے لیے) کے بغیر Signature کی تصدیق نہیں کر سکتے یا یقین نہیں کر سکتے کہ ڈیٹا اصل ہے۔ تصدیق کے بغیر، ڈیٹا کو غیر تصدیق شدہ اور ممکنہ طور پر رد و بدل شدہ سمجھیں۔
"alg: none” حملہ کیا ہے اور میں اسے کیسے روکوں؟
"alg: none” حملہ ان parsers کا فائدہ اٹھاتا ہے جو ٹوکن header میں بیان کردہ algorithm کو بغیر تصدیق کے قبول کر لیتے ہیں۔ ایک حملہ آور header کو "alg": "none" میں بدل دیتا ہے اور signature ہٹا دیتا ہے، جس سے ایک کمزور parser ٹوکن کو درست قبول کر لیتا ہے۔ اسے اپنے verification کوڈ میں ہمیشہ صریح طور پر allowed algorithms بیان کر کے روکیں — کبھی "none” قبول نہ کریں اور نہ ہی ٹوکن کو یہ فیصلہ کرنے دیں کہ کون سی algorithm استعمال ہو۔
