JWT डिकोडर
किसी भी JSON Web Token को डिकोड करके उसके हेडर, पेलोड और क्लेम को पढ़ने योग्य रूप में जाँचें — और वैकल्पिक रूप से HMAC (HS256/384/512) सिग्नेचर सत्यापित करें। सब कुछ आपके ब्राउज़र में ही रहता है।
JWT डिकोडर का उपयोग कैसे करें
- 1
अपना टोकन पेस्ट करें
एक एन्कोडेड JSON Web Token को इनपुट फ़ील्ड में पेस्ट करें। डिकोडर इसे अपने आप हेडर, पेलोड और सिग्नेचर में विभाजित कर देता है।
- 2
क्लेम पढ़ें
डिकोड किए गए हेडर और पेलोड को फ़ॉर्मेट किए गए JSON के रूप में जाँचें, और समाप्ति व जारी होने के समय जैसे पंजीकृत क्लेम देखें, जो पढ़ने योग्य तारीख़ों के रूप में दिखाए जाते हैं।
- 3
सिग्नेचर सत्यापित करें
HMAC टोकन के लिए, यह पुष्टि करने हेतु कि सिग्नेचर मान्य है और टोकन से छेड़छाड़ नहीं हुई है, साइनिंग सीक्रेट दर्ज करें।
- 4
जो चाहिए उसे कॉपी करें
टेस्ट, दस्तावेज़ीकरण, या डीबगिंग में उपयोग के लिए फ़ॉर्मेट किए गए हेडर या पेलोड JSON को अपने क्लिपबोर्ड पर कॉपी करें।
JSON Web Token को समझना: संरचना, क्लेम और सामान्य ग़लतियाँ
बिंदुओं से अलग किए गए तीन भाग
JSON Web Token एक लंबी स्ट्रिंग होती है जिसमें दो बिंदु होते हैं, जो इसे तीन भागों में बाँट देते हैं: हेडर, पेलोड और सिग्नेचर। पहले दो भागों में से हर एक एक छोटा JSON ऑब्जेक्ट होता है जिसे Base64URL में एन्कोड किया गया है — यह Base64 का एक URL-सुरक्षित रूप है जो कुछ अक्षर बदल देता है और पैडिंग हटा देता है, ताकि टोकन हेडर और क्वेरी स्ट्रिंग में आसानी से सफ़र कर सके। तीसरा भाग सिग्नेचर है, जिसकी गणना पहले दो भागों पर की जाती है।
जब आप कोई टोकन पेस्ट करते हैं, तो डिकोडर उसे बिंदुओं पर तोड़ता है और पहले दो भागों को Base64URL से वापस पढ़ने योग्य JSON में डिकोड कर देता है। आप हेडर और पेलोड ठीक वैसे ही देखते हैं जैसे जारीकर्ता ने उन्हें लिखा था। यह संभव क्यों है, यही आगे की हर बात की जड़ है: वे भाग केवल एन्कोड किए गए हैं, एन्क्रिप्ट नहीं।
हेडर: एल्गोरिदम और प्रकार
हेडर सबसे छोटा भाग है। यह आमतौर पर प्रकार — JWT — घोषित करता है और, इससे भी अहम बात, अपने alg फ़ील्ड में साइनिंग एल्गोरिदम बताता है। आम मान हैं HS256, जो किसी साझा सीक्रेट के साथ HMAC का उपयोग करता है, और RS256 या ES256, जो असममित कुंजी-जोड़ों का उपयोग करते हैं जहाँ एक निजी कुंजी साइन करती है और एक सार्वजनिक कुंजी सत्यापित करती है। एल्गोरिदम सत्यापनकर्ता को बताता है कि सिग्नेचर कैसे बना और इसलिए उसे कैसे जाँचना है।
alg फ़ील्ड सुरक्षा की दृष्टि से भी अहम है। कोई टोकन जो none एल्गोरिदम का दावा करता है, या कोई हमलावर किसी टोकन को असममित एल्गोरिदम से बदलकर सममित बना दे ताकि किसी भोले सत्यापनकर्ता को सार्वजनिक कुंजी को HMAC सीक्रेट की तरह इस्तेमाल करने के लिए धोखा दे — ये क्लासिक हमले हैं। एक सही सत्यापनकर्ता अपेक्षित एल्गोरिदम को पहले से तय रखता है, बजाय इसके कि हेडर जो कहे उस पर आँख मूँदकर भरोसा कर ले।
पेलोड और उसके पंजीकृत क्लेम
पेलोड क्लेम लेकर चलता है — वे कथन जो टोकन दावा करता है। पंजीकृत क्लेम नामों का एक समूह मानकीकृत है, ताकि अलग-अलग सिस्टम उनके अर्थ पर सहमत रहें। जारीकर्ता क्लेम (iss) बताता है कि टोकन किसने बनाया, धारक क्लेम (sub) पहचानता है कि यह किसके या किस बारे में है (अक्सर एक यूज़र ID), और प्राप्तकर्ता क्लेम (aud) इच्छित प्राप्तकर्ता का नाम बताता है। इनके साथ आपको आमतौर पर कस्टम एप्लिकेशन क्लेम भी मिलेंगे, जैसे कोई भूमिका या कोई टेनेंट।
यह डिकोडर पंजीकृत क्लेम को एक लेबल किए हुए, मानव-पठनीय रूप में सामने लाता है, ताकि आपको उन गूढ़ छोटे नामों को याद रखने की ज़रूरत न पड़े। डीबगिंग के दौरान किसी टोकन पर नज़र डालते समय यह पुष्टि करने के लिए कि यह सही सेवा के लिए सही टोकन है, जारीकर्ता, धारक और प्राप्तकर्ता को साफ़-साफ़ लिखा हुआ देख लेना अक्सर इतना ही काफ़ी होता है।
समय वाले क्लेम: exp, iat और nbf
तीन क्लेम किसी टोकन के जीवनकाल को नियंत्रित करते हैं, और ये सभी सेकंडों में मापे गए Unix टाइमस्टैम्प हैं — मिलीसेकंड में नहीं, जो मिलीसेकंड समय के आदी JavaScript डेवलपरों के लिए एक हज़ार-गुना-ग़लत होने वाली आम चूक है। समाप्ति क्लेम (exp) वह क्षण है जिसके बाद टोकन को अस्वीकार किया जाना चाहिए, जारी होने का क्लेम (iat) दर्ज करता है कि यह कब बना, और इससे-पहले-नहीं क्लेम (nbf) उस सबसे शुरुआती क्षण को चिह्नित करता है जब यह मान्य होता है।
डिकोडर इन्हें पढ़ने योग्य तारीख़ों में बदल देता है और आपके डिवाइस की घड़ी के अनुसार बताता है कि टोकन वर्तमान में सक्रिय है, अभी मान्य नहीं है, या समाप्त हो चुका है। यह आख़िरी बात मायने रखती है: अगर आपके कंप्यूटर की घड़ी ग़लत है, तो सक्रिय-या-समाप्त वाला फ़ैसला भ्रामक हो सकता है, और प्रोडक्शन में सर्वरों के बीच घड़ी का अंतर एक आम कारण है कि कोई ताज़ा जारी किया गया टोकन अभी-मान्य-नहीं के रूप में अस्वीकार हो जाता है।
डिकोड करना सत्यापन करना नहीं है
यही वह एक सबसे अहम बात है जिसे आत्मसात कर लेना चाहिए। कोई भी JWT को डिकोड कर सकता है — यह तो बस Base64URL है — इसलिए क्लेम पढ़ना आपको यह बताता है कि टोकन क्या कहता है, यह नहीं कि टोकन असली है या नहीं। भरोसा केवल कुंजी के साथ सिग्नेचर जाँचने से आता है, जो साबित करता है कि टोकन सीक्रेट या निजी कुंजी रखने वाले किसी पक्ष द्वारा जारी किया गया था और तब से बदला नहीं गया है।
HMAC टोकन (HS256, HS384, HS512) के लिए यह टूल हेडर, पेलोड और आपके द्वारा दिए गए सीक्रेट से सिग्नेचर की पुनर्गणना कर सकता है और उसे टोकन के सिग्नेचर से तुलना कर सकता है, जिससे उस सीक्रेट के लिए प्रामाणिकता की पुष्टि होती है। RS256 और ES256 जैसे असममित एल्गोरिदम को जारीकर्ता की सार्वजनिक कुंजी की ज़रूरत होती है और इन्हें यहाँ डिकोड तो किया जाता है पर सत्यापित नहीं। बेहद अहम बात: असली प्राधिकरण के फ़ैसले सर्वर-साइड पर सिग्नेचर ज़रूर सत्यापित करने चाहिए; क्लाइंट कोड में केवल डिकोडिंग के आधार पर किसी टोकन के क्लेम पर कभी भरोसा न करें।
पेलोड गुप्त नहीं होता
चूँकि पेलोड केवल एन्कोड किया गया होता है, उसके अंदर का हर क्लेम उस किसी भी व्यक्ति को साफ़ दिखाई देता है जिसे टोकन मिल जाए — ब्राउज़र, कोई भी प्रॉक्सी, या स्वयं उपयोगकर्ता। JWT ग़ैर-संवेदनशील पहचान और प्राधिकरण डेटा के लिए एक बढ़िया जगह है, और किसी भी गोपनीय चीज़ के लिए बेहद ख़राब जगह। यह सोचकर कभी कोई पासवर्ड, API सीक्रेट, क्रेडिट कार्ड नंबर, या निजी व्यक्तिगत डेटा पेलोड में न डालें कि एन्कोडिंग इसकी रक्षा कर देगी। यह रक्षा नहीं करती।
सिग्नेचर अखंडता की रक्षा करता है, गोपनीयता की नहीं: यह छेड़छाड़ रोकता है, पर सामग्री को छिपाने के लिए कुछ नहीं करता। अगर आपको सचमुच एक एन्क्रिप्टेड टोकन चाहिए जिसका पेलोड पढ़ा न जा सके, तो वह एक अलग, भारी संरचना है (JWE) — एक सामान्य JWT साइन किया जाता है, एन्क्रिप्ट नहीं। सीक्रेट को सर्वर पर रखें और टोकन में उन्हें किसी अपारदर्शी पहचानकर्ता से संदर्भित करें।
टोकन को सुरक्षित रूप से डीबग करना
रोज़मर्रा के काम में डिकोडर ऑथ फ़्लो डीबग करने में चमकता है: पुष्टि करें कि धारक क्लेम में सही उपयोगकर्ता है, जाँचें कि प्राप्तकर्ता उस सेवा से मेल खाता है जो अनुरोध को अस्वीकार कर रही है, सत्यापित करें कि स्कोप या भूमिकाएँ मौजूद हैं, और समाप्ति पढ़कर देखें कि कोई 401 बस एक बासी टोकन तो नहीं है। फ़ॉर्मेट किए हेडर या पेलोड को किसी बग रिपोर्ट या टेस्ट फ़िक्स्चर में कॉपी करना एक-क्लिक का काम है।
सब कुछ आपके ब्राउज़र में स्थानीय रूप से होता है — आपका टोकन और आपका टाइप किया कोई भी सीक्रेट कभी अपलोड, लॉग, या संग्रहीत नहीं किया जाता — इसलिए असली प्रोडक्शन टोकन जाँचना सुरक्षित है। फिर भी, टोकन को उन क्रेडेंशियल की तरह ही समझें जो वे हैं: एक मान्य, बिना समाप्त हुआ टोकन किसी खाते की एक जीवित चाबी है, इसलिए किसी को अविश्वसनीय टूल में पेस्ट करने से बचें, और उदाहरण साझा करते समय समाप्त या टेस्ट टोकन को प्राथमिकता दें।
अक्सर पूछे जाने वाले प्रश्न
JSON Web Token (JWT) क्या है?
क्या JWT डिकोड करने से पासवर्ड या सीक्रेट उजागर होता है?
यहाँ सिग्नेचर सत्यापन कैसे काम करता है?
exp और iat क्लेम का क्या मतलब है?
क्या मेरा टोकन किसी सर्वर पर भेजा जाता है?
संबंधित टूल्स
इन उपयोगी टूल्स के साथ आगे बढ़ें