कोई अपलोड नहीं, 100% स्थानीय, कोई खाता नहीं

JWT डिकोडर

अपना JWT पेस्ट करें और हेडर, पेलोड और एक्सपायरी देखें। कोई टोकन कहीं नहीं भेजा जाता। सिग्नेचर वेरिफ़ाई नहीं होता, केवल निरीक्षण के लिए उपयोग करें।

JWT डिकोडर कैसे काम करता है

JWT Decoder किसी JSON Web Token को उसके तीन हिस्सों में बाँटता है: हेडर, पेलोड और सिग्नेचर, और हेडर व पेलोड को फ़ॉर्मेट किए गए JSON के रूप में दिखाता है। डिकोडिंग ब्राउज़र में हर हिस्से को base64url-डिकोड करके स्थानीय रूप से होती है: आपका टोकन कभी किसी सर्वर को नहीं भेजा जाता। टूल सिग्नेचर की पुष्टि नहीं करता; यह सिर्फ़ आपको दिखाता है कि टोकन के दावों (claims) के अंदर क्या है।

सुरक्षा के लिहाज़ से यह फ़र्क अहम है: डिकोड किया गया JWT देखने से आपको पता चलता है कि उसमें कौन-से claims हैं (यूज़र ID, एक्सपायरी, रोल, स्कोप) लेकिन इससे यह पुष्टि नहीं होती कि टोकन किसी असली प्राधिकरण ने जारी किया था या उसके साथ छेड़छाड़ नहीं हुई। सिग्नेचर की पुष्टि के लिए जारीकर्ता की पब्लिक की या शेयर्ड सीक्रेट चाहिए होती है, जिसे आपको कभी किसी सार्वजनिक टूल में पेस्ट नहीं करना चाहिए। इस डिकोडर का उपयोग सिर्फ़ निरीक्षण और डीबगिंग के लिए करें।

JWT डिकोडर: चरण दर चरण उपयोग विधि

  1. पूरी JWT string (तीन dot-separated base64url segments) input field में पेस्ट करें।
  2. Header और payload sections तुरंत formatted JSON के रूप में दिखाई देते हैं।
  3. Expiry timestamp (Unix epoch seconds) देखने के लिए payload में 'exp' field जांचें।
  4. Signature segment जैसा है वैसा प्रदर्शित होता है; यह टूल उसे verify नहीं करता।

सामान्य उपयोग के मामले

  • ऑथेंटिकेशन की समस्या ठीक करने वाला कोई डेवलपर JWT के अंदर के claims पढ़ना चाहता है ताकि पुष्टि हो सके कि सही scope और role मौजूद हैं।
  • एक QA इंजीनियर access token का 'exp' field जांचता है ताकि सत्यापित हो कि expiry अपेक्षित अवधि पर सेट है।
  • एक सिक्योरिटी रिव्यूअर किसी थर्ड-पार्टी सर्विस के JWT का निरीक्षण करता है ताकि स्वीकार करने से पहले यह समझ सके कि उसमें कौन-सा यूज़र डेटा एनकोड है।
  • एक बैकएंड इंजीनियर यह जाँचकर 401 एरर की जड़ ढूँढता है कि टोकन का 'aud' (audience) claim अपेक्षित API आइडेंटिफ़ायर से मेल खाता है या नहीं।

अक्सर पूछे जाने वाले प्रश्न

क्या यह टूल JWT सिग्नेचर की पुष्टि करता है?

नहीं। टूल सिर्फ़ हेडर और पेलोड हिस्सों को base64url-डिकोड करके उनकी सामग्री JSON के रूप में दिखाता है। सिग्नेचर की पुष्टि के लिए जारीकर्ता की सीक्रेट की या पब्लिक की चाहिए होती है, जिसे यहाँ पेस्ट नहीं करना चाहिए। सही दिखने वाला डिकोड किया गया पेलोड फिर भी ग़लत सिग्नेचर वाला हो सकता है; किसी भरोसेमंद JWT लाइब्रेरी से सर्वर-साइड सिग्नेचर की पुष्टि करें।

क्या यहाँ पेस्ट करने पर मेरा JWT टोकन किसी सर्वर को भेजा जाता है?

नहीं। डिकोडिंग तीन atob कॉल (या कच्चे बाइट पर TextDecoder) से होती है, जो पूरी तरह ब्राउज़र के JavaScript इंजन में चलती है। यहाँ पेस्ट किया गया कुछ भी आपके ब्राउज़र टैब से बाहर नहीं जाता। निजी यूज़र claims वाले JWT का निरीक्षण करने का यही एकमात्र सुरक्षित तरीक़ा है: पूरी तरह लोकल, कोई नेटवर्क रिक्वेस्ट नहीं।

Header, payload और signature segments में क्या अंतर है?

JWT में डॉट से अलग किए गए तीन base64url-एनकोडेड हिस्से होते हैं। हेडर उस एल्गोरिदम की पहचान बताता है जिससे टोकन पर हस्ताक्षर किए गए (जैसे HS256 या RS256)। पेलोड में claims होते हैं: सब्जेक्ट और अतिरिक्त मेटाडेटा के बारे में तथ्य (एक्सपायरी, इशूअर, ऑडियंस, कस्टम claims)। सिग्नेचर, इशूअर की की का उपयोग करके हेडर और पेलोड से निकाला गया एक क्रिप्टोग्राफ़िक मान है; यही प्राप्तकर्ता को यह पुष्टि करने देता है कि टोकन में कोई बदलाव नहीं हुआ।

Payload में 'exp' का क्या अर्थ है?

'exp' claim टोकन के समाप्त होने का समय है, जिसे यूनिक्स टाइमस्टैंप (1 जनवरी 1970 UTC से पूर्णांक सेकंड) के रूप में दर्शाया जाता है। अगर मौजूदा समय 'exp' से ज़्यादा है, तो टोकन की मियाद ख़त्म हो चुकी है और इसकी जाँच करने वाले किसी भी सर्वर को इसे अस्वीकार कर देना चाहिए। यह टूल कच्चा संख्यात्मक मान दिखाता है; आप इसे इस साइट के टाइमस्टैंप टूल से बदल सकते हैं। Expired या valid बैज उस संख्या की तुलना आपके अपने डिवाइस की घड़ी से करता है, इसलिए ग़लत समय वाली मशीन टोकन को भी ग़लत आंकेगी। यह सिर्फ़ एक संकेत है, कभी उस सर्वर का विकल्प नहीं जो वास्तव में सिग्नेचर की जांच करता है।

क्या मैं इस टूल से ओपेक या रेफ़रेंस टोकन डिकोड कर सकता हूँ?

नहीं। Opaque tokens (कभी-कभी reference tokens कहे जाते हैं) random strings हैं जो स्वयं कोई user data नहीं रखते; संबंधित claims प्राप्त करने के लिए उन्हें issuer के introspection endpoint पर भेजा जाना चाहिए। यह टूल केवल standard three-part format में self-contained JWTs के साथ काम करता है।