مواد پر جائیں
ڈویلپر ٹولز

JWT محفوظ طریقے سے ڈی کوڈ کریں: ڈی کوڈ کرنا تصدیق نہیں

از · شائع

JSON Web Token (JWT) وہ لمبی سٹرنگ ہے جو آپ کے Authorization header، کوکی یا local storage میں eyJ سے شروع ہوتی ہے۔ جب لاگ ان خراب ہو یا API بار بار 401 دے، تو سب سے پہلا کام اس کے اندر جھانکنا ہے۔ یہ حصہ آسان ہے۔ مشکل یہ ہے کہ ٹوکن لیک نہ ہو، اور signature چیک کرنے سے پہلے جو کچھ پڑھا ہے اس پر بھروسا نہ کیا جائے۔ لوگ یہیں پھسلتے ہیں۔

JWT کس سے بنا ہوتا ہے

JWT کے تین حصے ہوتے ہیں جو نقطوں سے الگ ہوتے ہیں:

header.payload.signature
  • Header بتاتا ہے کہ ٹوکن پر دستخط کیسے ہوئے، مثلاً {"alg":"HS256","typ":"JWT"}۔
  • Payload میں claims ہوتے ہیں: صارف کون ہے، ٹوکن کب ختم ہوگا، اس کے پاس کون سے رول ہیں۔
  • Signature ثابت کرتا ہے کہ سرور کے دستخط کرنے کے بعد header اور payload میں کوئی تبدیلی نہیں ہوئی۔

Header اور payload encrypted نہیں ہوتے۔ وہ صرف Base64URL میں انکوڈ ہوتے ہیں، جو Base64 کی URL کے لیے محفوظ شکل ہے اور + اور / کی جگہ - اور _ استعمال کرتی ہے، اور = کی بھرتی حذف کر دیتی ہے۔ ٹوکن جس کے پاس بھی ہو وہ انہیں پڑھ سکتا ہے۔ اس لیے JWT کے payload میں کبھی پاس ورڈ، کارڈ نمبر یا کوئی اور راز نہ رکھیں۔

ڈی کوڈ کرنا اور تصدیق کرنا ایک چیز نہیں

ڈی کوڈ کرنے سے پہلے دو حصے دوبارہ JSON بن جاتے ہیں تاکہ آپ انہیں پڑھ سکیں۔ اس سے پتا چلتا ہے کہ ٹوکن دعویٰ کیا کر رہا ہے۔ یہ نہیں پتا چلتا کہ دعویٰ سچا ہے یا نہیں۔ کوئی بھی شخص "role":"admin" لکھ کر payload بنا سکتا اور انکوڈ کر سکتا ہے۔

تصدیق میں صحیح key سے signature دوبارہ نکالا جاتا ہے اور تیسرے حصے سے ملایا جاتا ہے۔ صرف تصدیق شدہ ٹوکن پر بھروسا کیا جا سکتا ہے۔ آپ کے backend کو ہمیشہ تصدیق کرنی چاہیے، کسی اچھی طرح برقرار رکھی جانے والی library سے، اور اجازت یافتہ algorithm کو اپنی config میں طے کرنا چاہیے، ٹوکن کے header سے نہیں لینا چاہیے۔

ٹوکن کہاں پیسٹ کرتے ہیں، یہ اہم ہے

کارآمد access token ایک ایسا پاس ورڈ ہے جس کی میعاد مقرر ہے۔ جس کے پاس بھی ہو وہ میعاد ختم ہونے تک آپ کی API کو اس صارف کے نام سے چلا سکتا ہے۔ اسے کسی ایسی ویب سائٹ میں پیسٹ کرنا جو اسے سرور کو بھیجتی ہے، اسے کسی اور کے logs میں پہنچا دینا ہے۔

Toolsy Hub کا JWT ڈیکوڈر پوری طرح آپ کے براؤزر میں چلتا ہے۔ ٹوکن، secret اور public key آپ کے ڈیوائس سے باہر نہیں جاتے۔ پھر بھی سب سے محفوظ عادت یہ ہے کہ debugging development یا staging کے ٹوکن سے کریں، یا ایسے ٹوکن سے جن کی میعاد پہلے ہی ختم ہو چکی ہو۔

ٹوکن ڈی کوڈ کرنے کا طریقہ، قدم بہ قدم

  1. ٹوکن کاپی کریں۔ براؤزر کے dev tools میں Network ٹیب کھولیں اور request کے Authorization header میں دیکھیں۔
  2. اسے JWT ڈیکوڈر میں پیسٹ کریں۔ شروع کا Bearer ہاتھ سے ہٹانے کی ضرورت نہیں۔
  3. Header میں algorithm دیکھیں، اور payload میں claims۔
  4. وقت کے claims جانچیں۔ ڈیکوڈر exp، nbf اور iat کو اصل تاریخوں میں بدل دیتا ہے اور بتاتا ہے کہ ٹوکن کی میعاد ختم ہو چکی ہے یا وہ ابھی قابل استعمال نہیں۔

وہ claims جو سب سے زیادہ نظر آتے ہیں

RFC 7519 کے registered claims۔ آپ کا provider اپنے claims بھی جوڑ سکتا ہے، جیسے roles یا email۔
Claimناممطلب
issIssuerٹوکن کس نے بنایا، اکثر آپ کے auth server کا URL۔
subSubjectٹوکن کس کے بارے میں ہے، عموماً صارف کی ID۔
audAudienceکون سی API یا ایپ اسے قبول کرے۔ ایک سروس کے لیے بنا ٹوکن دوسری سروس کو رد کر دینا چاہیے۔
expExpiresUnix وقت سیکنڈ میں، جس کے بعد ٹوکن رد ہو جانا چاہیے۔
nbfNot beforeUnix وقت سیکنڈ میں، جس سے پہلے ٹوکن ابھی قابل استعمال نہیں۔
iatIssued atUnix وقت سیکنڈ میں، جب ٹوکن بنا۔
jtiToken IDایک منفرد ID، جس سے کسی ایک ٹوکن کو بلاک کیا جاتا ہے یا اس کا دوبارہ استعمال روکا جاتا ہے۔

Signature کی تصدیق کیسے کریں

کون سی key چاہیے، یہ header میں لکھے algorithm پر منحصر ہے:

  • HS256، HS384، HS512 ایک مشترک secret استعمال کرتے ہیں۔ وہی secret دستخط بھی کرتا ہے اور تصدیق بھی، اس لیے اسے سرور پر ہی رہنا چاہیے۔
  • RS، PS اور ES algorithms keys کا جوڑا استعمال کرتے ہیں۔ سرور private key سے دستخط کرتا ہے، اور کوئی بھی public key سے تصدیق کر سکتا ہے۔ Public key PEM شکل میں پیسٹ کریں، یعنی وہ بلاک جو -----BEGIN PUBLIC KEY----- سے شروع ہوتا ہے۔

key ڈالتے ہی ڈیکوڈر signature چیک کر لیتا ہے اور بتاتا ہے کہ وہ درست ہے یا نہیں۔ یہ 256، 384 اور 512 بٹ hash کے ساتھ HS، RS، PS اور ES خاندانوں کو سپورٹ کرتا ہے۔

آپ کا ٹوکن رد کیوں ہوتا ہے: عام وجوہات

  • میعاد ختم ہو گئی۔ Access token اکثر 5 سے 60 منٹ چلتے ہیں۔ exp دیکھیں۔
  • گھڑی کا فرق۔ اگر سرور کی گھڑی ٹوکن بنانے والی گھڑی سے ایک منٹ پیچھے ہو، تو نیا ٹوکن بھی "ابھی قابل استعمال نہیں" نظر آ سکتا ہے۔ زیادہ تر libraries اس کے لیے تھوڑی گنجائش دیتی ہیں۔
  • غلط audience۔ ایک API کے لیے بنا ٹوکن دوسری API کو بھیج دیا گیا، اور aud میل نہیں کھاتا۔
  • غلط key۔ Staging اور production اکثر الگ secrets یا key pairs استعمال کرتے ہیں۔ اگر identity provider نے keys بدل دی ہوں تو ہو سکتا ہے آپ کی سروس کے پاس اب بھی پرانی public key ہو۔
  • کاپی پیسٹ کی غلطی۔ ایک حرف کم ہو یا ایک فالتو خالی جگہ ہو تو signature ٹوٹ جاتا ہے۔ ٹوکن میں بالکل دو نقطے ہونے چاہییں۔

کمانڈ لائن سے ڈی کوڈ کرنا

اگر آپ ٹرمینل پسند کرتے ہیں، تو یہ variable میں رکھے ٹوکن کا payload پرنٹ کرتا ہے:

echo "$TOKEN" | cut -d. -f2 | tr '_-' '/+' | base64 -d 2>/dev/null; echo

چونکہ Base64URL بھرتی حذف کر دیتا ہے، base64 -d شکایت کر سکتا ہے یا آخری حروف کاٹ سکتا ہے۔ ایک نظر ڈالنے کے لیے یہ ٹھیک ہے، لیکن اس سے کچھ بھی verify نہیں ہوتا۔ ایک جھلک سے زیادہ کے لیے کوئی مناسب library استعمال کریں یا ڈیکوڈر، جو signature بھی چیک کرتا ہے۔