اپنے auth provider سے ٹوکن کا معائنہ
Auth0، Firebase، Keycloak، AWS Cognito سب لاگ ان کے بعد JWTs واپس کرتے ہیں۔ access_token پیسٹ کریں اور دیکھیں کہ آپ کی ایپ اصل میں کون سے claims وصول کر رہی ہے — صارف ID کیا ہے، کیا scopes ہیں، یہ کب ختم ہو گا؟
کسی بھی JSON Web Token کو ڈی کوڈ کریں اور اس کا header، payload، اور signature دیکھیں — یا HS256/384/512 کے ساتھ نیا ٹوکن سائن کریں۔ HMAC سگنیچرز مقامی طور پر تصدیق کرتا ہے۔ 100% آپ کے براؤزر میں۔
کسی بھی JSON Web Token کو ڈی کوڈ کریں اور اس کا header، payload، اور signature دیکھیں — یا HS256/384/512 کے ساتھ نیا ٹوکن سائن کریں۔ HMAC سگنیچرز مقامی طور پر تصدیق کرتا ہے۔ 100% آپ کے براؤزر میں۔
نہیں۔ پورا ٹول اس صفحے کے اندر JavaScript ہے۔ ٹوکن پیسٹ کریں، ڈی کوڈنگ آپ کے براؤزر میں ہوتی ہے، بائٹس کبھی ٹیب سے باہر نہیں جاتیں۔ DevTools → Network کھول کر دیکھیں — ڈی کوڈ یا verify کے دوران کوئی request نہیں بھیجی جاتی۔ یہ حقیقی کسٹمر یا پروڈکشن ٹوکنز پیسٹ کرنا محفوظ بناتا ہے۔
یہ ثابت کرتا ہے کہ ٹوکن کسی ایسے شخص نے سائن کیا جس کے پاس secret (HMAC) یا private key (RSA/ECDSA) ہے۔ یہ payload کو encrypt نہیں کرتا — header اور payload صرف base64url-encoded JSON ہیں، ٹوکن رکھنے والا کوئی بھی شخص انہیں پڑھ سکتا ہے۔ signature صرف چھیڑ چھاڑ روکتا ہے: اگر آپ payload کا ایک بائٹ بھی بدلیں تو signature میل نہیں کھاتا۔
JWT اکثر صارف ID، ای میل، scopes، اور کبھی کبھی session cookies کے مساوی لے جاتا ہے — بالکل وہ ڈیٹا جو آپ کو کسی اجنبی کے سرور میں پیسٹ نہیں کرنا چاہیے۔ iKit کا ڈی کوڈر JavaScript کے طور پر چلتا ہے جو پہلے سے آپ کے براؤزر ٹیب میں لوڈ ہے۔ DevTools → Network میں قابل تصدیق: ڈی کوڈ یا verify کے دوران کوئی fetch، کوئی XHR، کوئی beacon نہیں۔
HS256/384/512 ٹوکنز کے لیے، signing secret ٹائپ کریں تاکہ سگنیچر کی مقامی طور پر تصدیق ہو۔ RS256/ES256 (RSA/ECDSA) کے لیے سرور سائیڈ لائبریری استعمال کریں — public-key تصدیق کے لیے PEM فائل درکار ہوتی ہے جسے ہم یہاں قبول نہیں کرتے۔
HS256 کو حقیقی کرپٹوگرافک طاقت کے لیے کم از کم 32 بائٹس (256 bits) درکار ہیں۔ ٹیسٹنگ کے لیے کچھ بھی چل جاتا ہے، لیکن پروڈکشن میں طویل random secret استعمال کرنا چاہیے۔
JWT ڈیبگ کرنے کا تیز ترین طریقہ — کوئی اپ لوڈ نہیں، کوئی سائن اپ نہیں، آپ اور آپ کے ٹوکن کے درمیان کوئی تیسرا فریق نہیں۔
JWT پیسٹ کریں، ڈی کوڈ شدہ header، payload، اور signature کو ساتھ ساتھ دیکھیں۔ معیاری claims (iss، sub، aud، exp، iat) ٹائم سٹیمپ اور لیبل کے ساتھ ظاہر ہوتے ہیں۔
HS256/384/512 ٹوکنز کے لیے، secret ٹائپ کریں تاکہ براؤزر کے Web Crypto API کے ذریعے سگنیچر کی تصدیق ہو۔ secret کبھی آپ کے ٹیب سے باہر نہیں جاتا۔
Encode موڈ پر سوئچ کریں، header اور payload کو JSON کے طور پر ایڈٹ کریں، algorithm منتخب کریں، secret ٹائپ کریں، اور فوراً سائن شدہ ٹوکن حاصل کریں۔
JWT payloads میں صارف IDs، ای میلز، کبھی کبھی scopes ہوتے ہیں — انہیں کبھی سرور ٹول میں پیسٹ نہ کریں۔ iKit کا ڈی کوڈر آپ کے براؤزر میں JavaScript کے طور پر چلتا ہے۔ DevTools → Network میں قابل تصدیق ہے۔
exp، nbf، iat جیسے معیاری claims کو پڑھنے کے قابل تاریخوں اور واضح EXPIRED / valid بیج کے ساتھ نمایاں کیا جاتا ہے تاکہ آپ ایک نظر میں جان سکیں کہ ٹوکن ابھی بھی درست ہے یا نہیں۔
براؤزر کے native Web Crypto API اور JSON parser پر بنایا گیا — وہی algorithms جیسے OpenSSL، libjwt، jose۔ یہ رویہ ہر جدید JWT لائبریری سے میل کھاتا ہے۔
JWT تین base64url-encoded JSON حصے ہیں جو نقطوں سے الگ ہوتے ہیں — بس اتنا ہی ہے۔
JWT اس طرح نظر آتا ہے aaa.bbb.ccc۔ ہم دو لفظی نقطوں پر تقسیم کرتے ہیں، جو encoded header، payload، اور signature دیتا ہے۔ اگر ہمیں بالکل تین حصے نہیں ملتے تو ٹوکن خراب ہے۔
Header اور payload base64url-encoded UTF-8 JSON ہیں۔ Base64URL = Base64 جس میں +//= کے بجائے -/_ ہے اور کوئی padding نہیں۔ ہم حروف واپس بدلنے کے بعد atob کرتے ہیں، پھر نتیجے میں آنے والی string کو JSON.parse کرتے ہیں۔
Header ہمیں algorithm (alg: HS256، RS256، وغیرہ) اور type بتاتا ہے۔ Payload میں claims ہوتے ہیں — معیاری (iss، sub، aud، exp، iat، nbf، jti) اور کوئی بھی custom فیلڈز۔ ہم ہر ایک کو لیبل والے سیکشن میں ظاہر کرتے ہیں۔
HS256/384/512 کے لیے، ہم آپ کے ٹائپ کیے گئے secret کا استعمال کرتے ہوئے header.payload کا HMAC دوبارہ حساب کرتے ہیں اور تیسرے segment میں signature سے موازنہ کرتے ہیں۔ یہی HMAC(SHA-256, secret, signing_input) base64url-encoded ہے۔ میل = signature درست۔
حقیقی صورتحال جہاں آپ JWT ڈی کوڈر کا استعمال کریں گے۔
Auth0، Firebase، Keycloak، AWS Cognito سب لاگ ان کے بعد JWTs واپس کرتے ہیں۔ access_token پیسٹ کریں اور دیکھیں کہ آپ کی ایپ اصل میں کون سے claims وصول کر رہی ہے — صارف ID کیا ہے، کیا scopes ہیں، یہ کب ختم ہو گا؟
API آپ کی request مسترد کر رہا ہے؟ ٹوکن کو ڈی کوڈ کر کے چیک کریں: کیا یہ ختم ہو چکا ہے (exp ماضی میں)؟ کیا audience claim (aud) وہی ہے جو API کو متوقع ہے؟ کیا issuer (iss) صحیح tenant ہے؟
Stripe، GitHub Apps، Slack webhook payloads JWTs کے طور پر سائن کر کے بھیجتے ہیں۔ ایک وصول کرنے کے بعد، اسے Decode موڈ میں مشترکہ secret کے ساتھ پیسٹ کریں تاکہ تصدیق کریں کہ request واقعی ان سے آئی ہے۔
انٹیگریشن ٹیسٹ کے لیے تازہ سائن شدہ JWT چاہیے؟ Encode موڈ پر سوئچ کریں، payload ایڈٹ کریں (custom صارف ID، custom expiry)، HS256 + اپنا ٹیسٹ secret منتخب کریں، ملی سیکنڈز میں ٹوکن حاصل کریں۔ کوئی backend round-trip نہیں۔
JWT اکثر صارف ID، ای میل، scopes، اور کبھی کبھی session cookies کے مساوی لے جاتا ہے — بالکل وہ ڈیٹا جو آپ کو کسی اجنبی کے سرور میں پیسٹ نہیں کرنا چاہیے۔ iKit کا ڈی کوڈر JavaScript کے طور پر چلتا ہے جو پہلے سے آپ کے براؤزر ٹیب میں لوڈ ہے۔ DevTools → Network میں قابل تصدیق: ڈی کوڈ یا verify کے دوران کوئی fetch، کوئی XHR، کوئی beacon نہیں۔
iKit بلاگ سے تفصیلی ٹیوٹوریلز اور ٹولز کا موازنہ۔
JWT segments are base64url-encoded JSON — understand the encoding before you debug a token.
JWT signatures are HMAC-SHA hashes — the same family of cryptographic hashes used to verify file integrity.
نہیں۔ پورا ٹول اس صفحے کے اندر JavaScript ہے۔ ٹوکن پیسٹ کریں، ڈی کوڈنگ آپ کے براؤزر میں ہوتی ہے، بائٹس کبھی ٹیب سے باہر نہیں جاتیں۔ DevTools → Network کھول کر دیکھیں — ڈی کوڈ یا verify کے دوران کوئی request نہیں بھیجی جاتی۔ یہ حقیقی کسٹمر یا پروڈکشن ٹوکنز پیسٹ کرنا محفوظ بناتا ہے۔
یہ ثابت کرتا ہے کہ ٹوکن کسی ایسے شخص نے سائن کیا جس کے پاس secret (HMAC) یا private key (RSA/ECDSA) ہے۔ یہ payload کو encrypt نہیں کرتا — header اور payload صرف base64url-encoded JSON ہیں، ٹوکن رکھنے والا کوئی بھی شخص انہیں پڑھ سکتا ہے۔ signature صرف چھیڑ چھاڑ روکتا ہے: اگر آپ payload کا ایک بائٹ بھی بدلیں تو signature میل نہیں کھاتا۔
تین عام وجوہات: (1) غلط secret — JWT secrets case-sensitive ہوتے ہیں اور کوئی بھی whitespace کا فرق verification توڑ دیتا ہے۔ (2) Algorithm mismatch — header کہتا ہے HS256 لیکن secret اصل میں HS512 کے ساتھ استعمال ہوا تھا۔ (3) سائن کرنے کے بعد ٹوکن میں ترمیم کی گئی — ایک بائٹ بھی signature توڑ دیتا ہے۔ چیک کریں کہ header.alg وہی ہے جو آپ کو متوقع ہے۔
iKit فی الحال صرف HMAC verification (HS256/384/512) کو سپورٹ کرتا ہے۔ RS256 اور ES256 public-key cryptography استعمال کرتے ہیں — verification کے لیے issuer کی public key PEM فارمیٹ میں درکار ہے، جو زیادہ پیچیدہ UI ہے۔ فی الحال، ڈی کوڈنگ کام کرتی ہے (header/payload/signature حصے درست ظاہر ہوتے ہیں)، لیکن Verify بٹن آپ کو بتائے گا کہ یہ غیر معاون ہے۔ RSA/ECDSA verification منصوبہ بندی میں ہے۔
وہی خیال، مختلف defaults۔ iKit کا ڈی کوڈر مکمل طور پر آپ کے براؤزر میں چلتا ہے (jwt.io بھی ایسا کرتا ہے، لیکن iKit کا کوڈ view-source کے ذریعے دیکھا جا سکتا ہے اور ہمارے ڈومین پر کوئی تیسرے فریق کے trackers نہیں)۔ ہم exp claim کے لیے واضح EXPIRED / valid بیج، ساختی claim نوٹس (iat / nbf / iss / sub / aud / jti قابل پڑھ rows کے طور پر)، اور copy-everything-decoded بٹن شامل کرتے ہیں جو آپ کو bug رپورٹ میں پیسٹ کرنے کے لیے مکمل ساختی آؤٹ پٹ دیتا ہے۔