एक JWT डिकोडर असल में क्या करता है
एक JSON वेब टोकन (JWT) यादृच्छिक अक्षरों की एक लंबी, अपारदर्शी स्ट्रिंग जैसा दिखता है, पर यह न तो एन्क्रिप्टेड है और न कोई गुप्त सायफ़र। यह एक सघन, URL-सुरक्षित पात्र है जो दो पक्षों के बीच संरचित डेटा ढोता है। ऊपर वाले डिकोडर में कोई टोकन पेस्ट कीजिए और यह उस स्ट्रिंग को अलग-अलग कर देता है और भीतर की असली JSON दिखा देता है — मेटाडेटा, क्लेम, टोकन किसके लिए है, और वह कब समाप्त होता है। सब कुछ ठीक आपके ब्राउज़र में होता है। टोकन कभी अपलोड, लॉग, या कहीं नहीं भेजा जाता, और यह बात तब बहुत मायने रखती है जब आप जिसकी जाँच कर रहे हैं वह एक सक्रिय सत्र क्रेडेंशियल हो।

तीन हिस्से, दो बिंदु
हर सुगठित JWT बिंदुओं से जुड़ी तीन Base64url-एन्कोडेड स्ट्रिंग होता है: header.payload.signature। वही एक बिंदु अक्षर वह तरीक़ा है जिससे पार्सर जानते हैं कि एक खंड कहाँ ख़त्म होता है और अगला कहाँ शुरू होता है, और यही वजह है कि ग़लत संख्या में बिंदुओं वाले टोकन को कुछ और पढ़े जाने से पहले ही अस्वीकार कर दिया जाता है।
हेडर एक छोटा JSON ऑब्जेक्ट है जो टोकन का स्वयं वर्णन करता है। इसमें लगभग हमेशा typ (प्रकार, आमतौर पर JWT) और alg होता है — हस्ताक्षर एल्गोरिदम, जैसे HS256 (SHA-256 के साथ HMAC) या RS256 (SHA-256 के साथ RSA)। हेडर एक सत्यापनकर्ता को ठीक-ठीक बताता है कि सिग्नेचर कैसे बनाया गया था।
पेलोड वह हिस्सा है जिसकी अधिकांश लोगों को परवाह होती है। यह एक और JSON ऑब्जेक्ट है जो क्लेम रखता है — उपयोगकर्ता और टोकन के बारे में कथन। विनिर्देश क्लेम को पंजीकृत (मानक, आरक्षित नाम), सार्वजनिक, और निजी (आपके अपने ऐप के लिए आपके गढ़े हुए कस्टम नाम) में बाँटता है। पेलोड को डिकोड करना ही उजागर करता है कि कौन लॉग इन है, उसकी क्या भूमिका है, और उसका सत्र कब समाप्त होता है।
सिग्नेचर क्रिप्टोग्राफ़िक मुहर है। इसकी गणना एन्कोडेड हेडर और पेलोड पर, हेडर के एल्गोरिदम तथा एक गुप्त या निजी कुंजी का उपयोग करके की जाती है। चूँकि यह दोनों अन्य खंडों को ढकता है, हेडर या पेलोड में कोई भी बदलाव — एक अकेला अक्षर तक — इसे अमान्य कर देता है।
वे क्लेम जो आप सबसे ज़्यादा देखेंगे
पंजीकृत क्लेम छोटे, तीन-अक्षर वाले नाम हैं जो RFC 7519 द्वारा परिभाषित हैं ताकि अलग-अलग सिस्टम आपस में काम कर सकें। इनमें से कुछ लगभग हर जगह दिखते हैं:
iss— issuer: टोकन किसने जारी किया (आपका ऑथ सर्वर या पहचान प्रदाता)।sub— subject: वह मुख्य इकाई जिसके बारे में टोकन है, आमतौर पर एक स्थिर उपयोगकर्ता ID।aud— audience: वह प्राप्तकर्ता जिसके लिए टोकन अभिप्रेत है। किसी API को उन टोकनों को अस्वीकार करना चाहिए जिनकी ऑडियंस स्वयं वह नहीं है।exp— expiration time: एक यूनिक्स टाइमस्टैम्प जिसके बाद टोकन स्वीकार नहीं किया जाना चाहिए।iat— issued at: वह यूनिक्स टाइमस्टैम्प जब टोकन बनाया गया था।
आप nbf (not before) और jti (एक अद्वितीय टोकन ID) से भी मिल सकते हैं। टाइमस्टैम्प UTC में 1970 से बीते सेकंड होते हैं, और यही वजह है कि उन्हें मानव-पठनीय तारीख़ों के रूप में प्रस्तुत करने वाला कोई डिकोडर आपको यह जाँचने की मानसिक गणित से बचा लेता है कि कोई टोकन पहले ही समाप्त हो चुका है या नहीं।
डिकोड करना सत्यापित करना नहीं है — यही वह हिस्सा है जो लोगों को डँसता है
यह भेद JWT के बारे में समझने वाली सबसे महत्वपूर्ण बात है। डिकोडिंग का अर्थ है सामग्री पढ़ना: इसके लिए किसी कुंजी की ज़रूरत नहीं और जिसके पास टोकन है वह कोई भी इसे कर सकता है, क्योंकि Base64url एक एन्कोडिंग है, एन्क्रिप्शन नहीं। सत्यापन का अर्थ है यह सिद्ध करना कि टोकन प्रामाणिक और अछूता है — सही गुप्त या सार्वजनिक कुंजी से सिग्नेचर की दोबारा गणना करना और इसकी पुष्टि करना कि वह मेल खाता है।
यह टूल डिकोड करता है। यह आपको दिखाता है कि टोकन क्या कहता है, यह नहीं कि टोकन भरोसेमंद है या नहीं। कोई टोकन जाली, समाप्त, या दोबारा भेजा गया हो सकता है और फिर भी एकदम साफ़-सुथरी दिखने वाली JSON में डिकोड हो सकता है। केवल डिकोड किए गए क्लेम के आधार पर कभी कोई प्राधिकरण निर्णय न लें। उत्पादन में आप सिग्नेचर को सर्वर-साइड सत्यापित करते हैं, exp जाँचते हैं, और पुष्टि करते हैं कि iss और aud उससे मेल खाते हैं जिसकी आप अपेक्षा करते हैं — किसी परखी हुई लाइब्रेरी का उपयोग करते हुए, कभी हाथ से बनाई गई स्ट्रिंग तुलना से नहीं।

एक पेलोड कोई तिजोरी नहीं है
चूँकि पेलोड केवल Base64url-एन्कोडेड है, इसे कोई भी पढ़ सकता है जो टोकन को बीच में रोक ले। इसमें मौजूद हर चीज़ को सार्वजनिक मानिए। JWT क्लेम में पासवर्ड, पूरे क्रेडिट कार्ड नंबर, गुप्त कुंजियाँ, या कोई संवेदनशील व्यक्तिगत डेटा न रखें — यदि आप इसे यहाँ एक क्लिक में डिकोड कर सकते हैं, तो कोई और भी कर सकता है जिसे इसकी एक प्रति मिल जाए। सिग्नेचर संशोधन से रक्षा करता है, पढ़े जाने से कभी नहीं। यदि आपको वाक़ई पेलोड की सामग्री छिपानी है, तो यह काम JWE (एन्क्रिप्टेड टोकन) का है, जो पूरी तरह एक अलग विनिर्देश है।
गोपनीयता और संबंधित टूल
किसी टोकन की जाँच करना एक संवेदनशील क्रिया है, इसलिए यह डिकोडर पूरी तरह क्लाइंट-साइड चलता है — पार्सिंग आपके टैब में सादा JavaScript है और कुछ भी आपकी मशीन से बाहर नहीं जाता। किसी सर्वर-समर्थित टूल में सत्र टोकन पेस्ट करने का अर्थ है किसी तीसरे पक्ष को एक सक्रिय क्रेडेंशियल थमा देना, और ठीक यही आपको टालना चाहिए। इन सबके नीचे की एन्कोडिंग के लिए, हमारा Base64 टूल देखें, और ज़्यादा ऑन-डिवाइस उपयोगिताओं के लिए हमारे बाक़ी डेवलपर टूल देखें।
अक्सर पूछे जाने वाले सवाल
क्या एक JWT एन्क्रिप्टेड होता है?
नहीं। एक मानक JWT Base64url-एन्कोडेड होता है, एन्क्रिप्टेड नहीं। जिसके पास टोकन है वह कोई भी हेडर और पेलोड पढ़ सकता है। यदि आपको सामग्री छिपानी है तो JWE इस्तेमाल करें।
क्या यह टूल सिग्नेचर सत्यापित करता है?
नहीं। यह केवल हेडर और पेलोड को डिकोड करके दिखाता है। सिग्नेचर सत्यापित करने के लिए इश्यूअर के गुप्त या सार्वजनिक कुंजी की ज़रूरत होती है और यह आपके सर्वर पर किया जाना चाहिए।
क्या यहाँ मेरा टोकन पेस्ट करना सुरक्षित है?
हाँ। डिकोडिंग पूरी तरह आपके ब्राउज़र में स्थानीय JavaScript का उपयोग करके चलती है। टोकन कभी अपलोड, संग्रहीत, या किसी सर्वर पर नहीं भेजा जाता।
iss, sub, aud, exp और iat का क्या मतलब है?
ये पंजीकृत क्लेम हैं: इश्यूअर, सब्जेक्ट, ऑडियंस, समाप्ति समय और जारी-किए-जाने का समय। समय से संबंधित तीनों यूनिक्स टाइमस्टैम्प को सेकंड में इस्तेमाल करते हैं।
क्या मैं डिकोड करने के बाद दिखाए गए क्लेम पर भरोसा कर सकता हूँ?
अपने आप में नहीं। डिकोड किए गए क्लेम किसी जाली या समाप्त टोकन से आ सकते हैं। उन पर भरोसा करने से पहले हमेशा सिग्नेचर सत्यापित करें और समाप्ति को सर्वर-साइड जाँचें।
मेरे टोकन में बिंदुओं से अलग किए गए तीन हिस्से क्यों हैं?
वे हेडर, पेलोड और सिग्नेचर हैं, हर एक Base64url-एन्कोडेड और बिंदुओं से जुड़ा हुआ। बिंदु पार्सर को बताते हैं कि हर खंड कहाँ शुरू और कहाँ ख़त्म होता है।
