JWT ڈی کوڈر
JSON Web Token پیسٹ کریں تاکہ اس کا header اور payload پڑھیں، دیکھیں کہ یہ کب ختم ہوگا، اور ہر کلیم سمجھیں۔ آپ کا ٹوکن کبھی آپ کے براؤزر سے باہر نہیں جاتا۔
آپ کے براؤزر میں چلتا ہےسائن اپ کی ضرورت نہیںکچھ اپ لوڈ نہیں ہوتا
ڈی کوڈ کرنا تصدیق نہیں ہے۔ کوئی بھی JWT کا ہیڈر اور payload پڑھ سکتا ہے، کیونکہ وہ صرف base64url میں انکوڈ ہوتے ہیں۔ یہ ٹول دکھاتا ہے کہ ٹوکن کیا دعویٰ کرتا ہے؛ یہ ثابت نہیں کرتا کہ ٹوکن اصلی ہے۔ دستخط کی تصدیق ہمیشہ اپنے سرور پر کریں۔
ہیڈر
Payload
کلیمز کی وضاحت
دستخط کی تصدیق (اختیاری، HS256/HS384/HS512)
آپ کے درج کردہ سیکرٹ سے HMAC دستخط کو آپ کے براؤزر کی Web Crypto API کے ذریعے چیک کرتا ہے۔ سیکرٹ کبھی اس صفحے سے باہر نہیں جاتا۔ RSA/ECDSA ٹوکنز کے لیے جاری کنندہ کی پبلک کلید درکار ہے اور ان کی تصدیق یہاں نہیں ہوتی۔
JWT ڈی کوڈر استعمال کرنے کا طریقہ
- ٹوکن انکوڈ شدہ ٹوکن خانے میں پیسٹ کریں۔ Authorization ہیڈر سے آنے والا شروع کا
Bearerنظر انداز ہو جاتا ہے۔ - header اور payload فوراً ڈی کوڈ ہو کر فارمیٹ شدہ JSON کے طور پر دکھائی دیتے ہیں۔
- کلیمز کی وضاحت ٹیبل پڑھیں:
exp،iatاورnbfتاریخوں میں تبدیل ہوتے ہیں، «ختم ہو گا» / «ختم ہو چکا» اوقات کے ساتھ۔ - میعاد کے مسائل کے لیے سٹیٹس بار اور
alg: noneجیسی خطرناک سیٹنگز کے لیے وارننگز چیک کریں۔ - چاہیں تو HS256، HS384 یا HS512 دستخط کی مقامی تصدیق کے لیے مشترکہ سیکرٹ درج کریں۔
JWT کے اندر کیا ہوتا ہے؟
JSON Web Token (RFC 7519) تین base64url سٹرنگز ہیں جو نقطوں سے جڑی ہوتی ہیں: header.payload.signature۔ header سائننگ الگورتھم (alg) اور ٹوکن کی قسم بتاتا ہے۔ payload میں کلیمز ہوتے ہیں، جیسے صارف کون ہے اور ٹوکن کب ختم ہوگا۔ signature پہلے دو حصوں پر سیکرٹ یا پرائیویٹ کلید سے بنایا جاتا ہے۔
ڈی کوڈ کرنا تصدیق کرنا نہیں ہے
header اور payload صرف انکوڈ ہوتے ہیں، انکرپٹ نہیں، اس لیے ٹوکن رکھنے والا کوئی بھی انہیں پڑھ سکتا ہے۔ اسی لیے JWT payload میں کبھی پاس ورڈز یا سیکرٹس نہ رکھیں۔ ڈی کوڈنگ بتاتی ہے کہ ٹوکن کیا کہتا ہے۔ دستخط کی تصدیق، جو عموماً آپ کے API سرور پر jose یا PyJWT جیسی لائبریری سے ہوتی ہے، ثابت کرتی ہے کہ اسے کس نے جاری کیا اور اس میں تبدیلی نہیں ہوئی۔ سرور کو exp، nbf، iss اور aud بھی چیک کرنے چاہئیں اور غیر متوقع الگورتھمز مسترد کرنے چاہئیں۔
رجسٹرڈ کلیمز کی چیٹ شیٹ
| کلیم | مطلب |
|---|---|
iss | جاری کنندہ: کس نے ٹوکن بنایا اور سائن کیا |
sub | موضوع: عموماً صارف کی ID |
aud | سامعین: ٹوکن کس API کے لیے ہے |
exp | میعاد ختم ہونے کا وقت، یونکس epoch سے سیکنڈز میں |
nbf | اس وقت سے پہلے درست نہیں |
iat | جاری ہونے کا وقت |
jti | منفرد ٹوکن ID، منسوخی کی فہرستوں کے لیے مفید |
«token expired» ایررز کی ڈیبگنگ
اگر کوئی API تازہ لگنے والا ٹوکن مسترد کرے تو exp اور nbf کا سرور کی گھڑی سے موازنہ کریں۔ مشینوں کے درمیان گھڑی کا معمولی فرق عام ہے، اس لیے زیادہ تر لائبریریاں 30-60 سیکنڈ کی گنجائش دیتی ہیں۔ یہ بھی چیک کریں کہ exp سیکنڈز میں ہو: ملی سیکنڈ ویلیو ایک عام بگ ہے جو میعاد کو ہزاروں سال آگے لے جاتا ہے۔
اکثر پوچھے جانے والے سوالات
کیا یہاں پروڈکشن JWT پیسٹ کرنا محفوظ ہے؟
کیا یہ ٹول JWT دستخط کی تصدیق کرتا ہے؟
میرا ٹوکن ختم شدہ کیوں دکھ رہا ہے؟
exp کلیم آپ کے کمپیوٹر کی گھڑی کے مقابلے میں ماضی میں ہے۔ نیا ٹوکن لیں، یا اپنے refresh token سے اسے تازہ کریں۔ اگر اوقات غلط لگیں تو گھڑی کا فرق یا ملی سیکنڈز میں لکھی exp ویلیو چیک کریں۔JWT، JWS اور JWE میں کیا فرق ہے؟
alg «none» خطرناک کیوں ہے؟
alg: none مسترد کرنا چاہیے اور صرف وہی مخصوص الگورتھم قبول کرنا چاہیے جس کی وہ توقع کرتے ہیں۔