JWT डिकोडर

एक JSON Web Token देखने में अक्षरों का कोई अपठनीय गुच्छा लगता है, लेकिन असल में यह सिर्फ डॉट से जुड़े तीन Base64URL-एनकोडेड हिस्से होते हैं: एक हेडर, एक पेलोड, और एक सिग्नेचर। हेडर और पेलोड को डिकोड करना एन्क्रिप्शन बिल्कुल नहीं है — टोकन रखने वाला कोई भी व्यक्ति इसके अंदर के क्लेम्स पढ़ सकता है, और यही वजह है कि संवेदनशील डेटा को कभी भी JWT पेलोड में नहीं ठूंसना चाहिए। दिक्कत यह है कि जिन टोकन को लोगों को जांचने की ज़रूरत पड़ती है, वे शायद ही कभी डिस्पोज़ेबल टेस्ट डेटा होते हैं। ये अक्सर किसी प्रोडक्शन ऐप का लाइव सेशन टोकन, कोई API एक्सेस टोकन, या डिबग करते वक्त ब्राउज़र के dev tools से सीधा निकाला गया लॉगिन कुकी होता है — एक असली क्रेडेंशियल, जो गलत हाथों में पड़ने पर असली एक्सेस दे देता है। इसे किसी अनजान वेबसाइट में पेस्ट करना आपके सेशन को उस सर्वर के हवाले कर देना है जिसके बारे में आप कुछ भी नहीं जानते।

यह टूल ऐसा कभी नहीं करता। जैसे ही आप कोई टोकन पेस्ट करते हैं, हेडर और पेलोड को आपके ब्राउज़र में चल रही सादी JavaScript से डिकोड किया जाता है — डॉट्स पर स्प्लिट करके, Base64URL-डिकोड करके, JSON के तौर पर पार्स करके — और इसमें से कुछ भी कहीं ट्रांसमिट नहीं होता। सिग्नेचर वेरिफिकेशन भी उसी तरह काम करता है, हर आधुनिक ब्राउज़र में पहले से मौजूद Web Crypto API (`SubtleCrypto`) का इस्तेमाल करके: HMAC एल्गोरिदम (HS256, HS384, HS512) को आपके टाइप किए गए सीक्रेट के खिलाफ वेरिफाई किया जाता है, और RSA एल्गोरिदम (RS256, RS384, RS512) को आपके PEM फॉर्मेट में पेस्ट किए गए पब्लिक की के खिलाफ। क्रिप्टोग्राफिक सीक्रेट और खुद वेरिफिकेशन, दोनों सिर्फ उस टैब तक सीमित रहते हैं; पेज रीफ्रेश करते ही सब कुछ — टोकन, सीक्रेट, की — गायब हो जाता है।

कोई टोकन पेस्ट करके उसका हेडर और पेलोड प्रिटी-प्रिंटेड फॉर्म में देखें, साथ ही स्टैंडर्ड `exp`, `iat`, और `nbf` क्लेम्स को इंसानों के पढ़ने लायक डेट में बदलकर दिखाया जाता है, और अगर टोकन का `exp` पहले ही बीत चुका है तो एक साफ "Expired" बैज दिखता है — यह इस बात की पुष्टि करने में काम आता है कि "मैं लॉग आउट हो गया" वाली बग रिपोर्ट असल में सिर्फ एक एक्सपायर्ड टोकन है। अगर एल्गोरिदम HS256/384/512 या RS256/384/512 है, तो मैचिंग सीक्रेट या पब्लिक की डालकर चेक करें कि सिग्नेचर असली है या उससे छेड़छाड़ की गई है। इस सेट से बाहर के एल्गोरिदम (जैसे ES256 या बिना साइन किया हुआ `none`) फिर भी ठीक से डिकोड होते हैं, लेकिन नकली रिज़ल्ट दिखाने के बजाय उनके लिए वेरिफिकेशन का विकल्प नहीं दिया जाता। लोकल डेवलपमेंट के लिए, एडिट करने योग्य हेडर/पेलोड बॉक्स आपको कोई क्लेम बदलने देते हैं — जैसे किसी यूज़र ID या रोल को बदलना — और फिर टोकन को उसी HS256 सीक्रेट से दोबारा साइन करने देते हैं जो आपका टेस्ट सर्वर इस्तेमाल करता है, जो पूरा लॉगिन फ्लो चलाए बिना ऑथराइज़ेशन लॉजिक टेस्ट करने का एक आम तरीका है।

चूंकि डिकोड होने के बाद JWT का पेलोड सादा, पढ़ने लायक JSON बन जाता है, इसलिए अगर आपको किसी गहरे नेस्टेड क्लेम को और बारीकी से जांचना हो तो यह JSON Formatter & Validator टूल के साथ स्वाभाविक रूप से फिट बैठता है। एक सुरक्षा रिमाइंडर दोहराने लायक है: चूंकि डिकोडिंग के लिए किसी सीक्रेट की ज़रूरत ही नहीं पड़ती, इसलिए जांच पूरी करते ही किसी भी टोकन को संवेदनशील मानें, और अगर आपको यकीन नहीं है कि यहां पेस्ट करने से पहले वे और कहां-कहां पेस्ट किए जा चुके हैं, तो उन क्रेडेंशियल्स को रोटेट कर दें जो शुरू से ही सिर्फ थोड़े समय के लिए बनाए गए थे।