JWT ڈیکوڈر

ایک JSON Web Token تین base64url-انکوڈڈ حصے ہیں جنہیں نقطوں سے جوڑا گیا ہے: header.payload.signature۔ ہیڈر اور پے لوڈ JSON ہیں؛ دستخط پہلے دو حصوں پر HMAC یا RSA/ECDSA آؤٹ پٹ ہے۔ یہ ٹول نقطوں پر تقسیم کرتا ہے، ہر حصے کو base64url-ڈیکوڈ کرتا ہے، JSON پارس کرتا ہے، اور exp جیسے معیاری وقتی کلیمز کو انسان-پڑھنے کے قابل تاریخوں میں دکھاتا ہے۔ یہ دستخط کی تصدیق نہیں کرتا — کیوں، نیچے FAQ دیکھیں۔

مثال

JWT اسپیک سے نمونہ ٹوکن (HS256 سے your-256-bit-secret سیکرٹ کے ساتھ دستخط شدہ):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

ڈیکوڈ شدہ ہیڈر:

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

ڈیکوڈ شدہ پے لوڈ:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

میرا JWT دستخط غلط کیوں نشان زد ہے؟

یہ ڈیکوڈر دستخط چیک نہیں کرتا (FAQ دیکھیں)، مگر اگر سرور-سائیڈ ویریفائر آپ کا ٹوکن مسترد کر رہا ہے، یہ عام وجوہات ہیں۔

• غلط سیکرٹ یا کی۔ HMAC سیکرٹ میں ایک حرف کا فرق بھی بالکل مختلف دستخط پیدا کرتا ہے۔ یقینی بنائیں کہ ویلیڈیٹنگ سروس پر JWT_SECRET env var جاری کنندہ سے مطابقت رکھتا ہے۔
• الگورتھم عدم مطابقت۔ HS256 سے دستخط شدہ ٹوکن RS256 سے تصدیق نہیں ہو سکتا۔ ہیڈر میں alg کلیم چیک کریں اور یقینی بنائیں کہ ویریفائر اسی الگورتھم کے لیے کنفیگرڈ ہے۔
• میعاد ختم ٹوکن۔ درست دستخط شدہ JWT بھی exp ماضی میں چلا جائے تو تصدیق ناکام ہو جاتی ہے۔ وقتی کلیمز کا خلاصہ ڈیکوڈنگ کے بعد یہ واضح دکھاتا ہے۔
• گھڑی کا فرق۔ nbf (not-before) قریبی مستقبل میں اور سرور گھڑی کی بہاؤ "token not yet valid" غلطیاں دیتی ہیں۔ اپنے ویریفائر میں تھوڑی چھوٹ (مثلاً 60 سیکنڈ) رکھیں۔
• پیسٹ شدہ ٹوکن میں وائٹ اسپیس۔ کاپی پیسٹ کبھی شروع میں اسپیس یا آخر میں نئی لائن شامل کرتا ہے۔ ایک JWT بالکل header.payload.signature ہونا چاہیے، ارد گرد وائٹ اسپیس کے بغیر۔
• alg: none۔ اگر ہیڈر کہتا ہے "alg": "none"، ٹوکن بغیر دستخط ہے۔ ویریفائر پر انہیں مسترد کریں — انہیں کبھی درست نہ سمجھیں۔

کیا یہ ٹول JWT دستخط کی تصدیق کر سکتا ہے؟

نہیں، اور یہ جان بوجھ کر ہے۔ دستخط کی تصدیق کے لیے سائننگ کی درکار ہے — HMAC مشترکہ سیکرٹ یا غیر متناسب عوامی کی۔ وہ کی اس سرور پر ہونی چاہیے جو ٹوکن جاری یا استعمال کرتا ہے، ویب پیج پر پیسٹ نہیں۔ یہ ٹول صرف ڈیکوڈ اور دکھاتا ہے؛ تصدیق آپ کے بیک اینڈ کے سرور-سائیڈ پر ہوتی ہے۔

JWT کے تین حصوں میں سے ہر ایک میں کیا ہوتا ہے؟

ایک JWT ہے header.payload.signature۔ ہیڈر JSON ہے جو الگورتھم (alg) اور ٹوکن کی قسم بیان کرتا ہے۔ پے لوڈ JSON ہے جس میں sub، iat، exp جیسے کلیمز ہوتے ہیں۔ دستخط پہلے دو حصوں کو سیکرٹ یا پرائیویٹ کی سے دستخط کرنے کا base64url-انکوڈڈ آؤٹ پٹ ہے۔ پہلے دو صرف انکوڈ ہیں، انکرپٹ نہیں۔

میرا JWT میعاد ختم ہو گیا — کیسے معلوم کروں؟

پے لوڈ میں exp کلیم دیکھیں۔ یہ سیکنڈز میں Unix ٹائم اسٹیمپ ہے۔ اگر Date.now() / 1000 exp سے بڑا ہے، ٹوکن میعاد ختم۔ یہ ٹول پے لوڈ کے نیچے exp، iat، اور nbf کو انسان-پڑھنے کے قابل تاریخوں کے طور پر رینڈر کرتا ہے، تاکہ آپ بغیر خود حساب کیے ایک نظر میں جان سکیں۔

alg: none کا کیا مطلب ہے اور یہ کیوں خطرناک ہے؟

alg: none JWT کی ایک خصوصیت ہے جہاں دستخط خالی ہوتا ہے اور چیک نہیں ہوتا۔ بہت سی لائبریریاں تاریخی طور پر ایسے ٹوکنز قبول کرتی رہی ہیں، جس نے حملہ آوروں کو پے لوڈ بنا کر alg کو none پر سیٹ کر کے JWTs جعل سازی کرنے دی۔ یہ ہیڈر ویلیو دیکھیں تو ٹوکن بغیر دستخط — کسی سرور پر بھروسہ نہ کریں جو اسے قبول کرتا ہے۔

کیا آپ یہاں پیسٹ کیے گئے JWTs محفوظ کرتے ہیں؟

نہیں۔ ڈیکوڈر میں پیسٹ کیا گیا کوئی ٹوکن ہم محفوظ نہیں کرتے۔ آپ جو بھی چھوڑتے ہیں وہ ٹیب بند یا ریفریش کرنے پر ضائع — کچھ لاگ نہیں، اور جن ٹوکنز کا آپ نے معائنہ کیا ان کا ہمارے پاس کوئی ریکارڈ نہیں۔ البتہ: JWT اپنے exp تک رسائی دیتا ہے: اسے پاسورڈ کی طرح لیں اور جس بھی پروڈکشن ٹوکن کو ڈیبگ کریں اسے روٹیٹ کریں۔

دستخط والا حصہ ایک ناقابلِ پڑھ بلاب دکھا رہا ہے — کیا یہ نارمل ہے؟

جی ہاں۔ دستخط HMAC یا RSA/ECDSA کا بائنری آؤٹ پٹ ہے، base64url-انکوڈڈ۔ یہ انسانی طور پر پڑھنے کے لیے نہیں ہے — یہ صرف کرپٹوگرافک چیک کے طور پر کام آتا ہے۔ ڈیکوڈ شدہ ہیڈر اور پے لوڈ JSON حصے ہیں جن پر آپ عمل کرتے ہیں۔ خالی دستخط کا مطلب ہے ٹوکن بغیر دستخط (alg: none)۔