JWT डिकोडर
JSON Web Token पेस्ट करें और उसका हेडर व पेलोड पढ़ें, देखें कि वह कब एक्सपायर होगा, और हर क्लेम को समझें। आपका टोकन कभी आपके ब्राउज़र से बाहर नहीं जाता।
आपके ब्राउज़र में चलता हैसाइन-अप ज़रूरी नहींकुछ भी अपलोड नहीं होता
डिकोड करना वेरिफ़िकेशन नहीं है। कोई भी JWT का हेडर और पेलोड पढ़ सकता है, क्योंकि वे सिर्फ़ base64url-एनकोडेड होते हैं। यह टूल दिखाता है कि टोकन क्या दावा करता है; यह साबित नहीं करता कि टोकन असली है। सिग्नेचर हमेशा अपने सर्वर पर वेरिफ़ाई करें।
हेडर
पेलोड
क्लेम्स की व्याख्या
सिग्नेचर वेरिफ़ाई करें (वैकल्पिक, HS256/HS384/HS512)
आपके ब्राउज़र के Web Crypto API से, आपके दर्ज किए गए सीक्रेट के साथ HMAC सिग्नेचर जाँचता है। सीक्रेट कभी इस पेज से बाहर नहीं जाता। RSA/ECDSA टोकन के लिए issuer की पब्लिक की चाहिए, इसलिए उन्हें यहाँ वेरिफ़ाई नहीं किया जाता।
JWT डिकोडर का उपयोग कैसे करें
- टोकन को एनकोडेड टोकन बॉक्स में पेस्ट करें। Authorization हेडर से आया शुरुआती
Bearerअनदेखा किया जाता है। - हेडर और पेलोड तुरंत डिकोड होकर फ़ॉर्मैट किए गए JSON के रूप में दिखते हैं।
- क्लेम्स की व्याख्या टेबल पढ़ें:
exp,iatऔरnbfको “कितनी देर में एक्सपायर” / “कितनी देर पहले एक्सपायर” समय के साथ तारीखों में बदला जाता है। - एक्सपायरी की समस्याओं के लिए स्टेटस बार देखें, और
alg: noneजैसी जोखिम भरी सेटिंग्स के लिए चेतावनियाँ देखें। - चाहें तो HS256, HS384 या HS512 सिग्नेचर को लोकली वेरिफ़ाई करने के लिए शेयर्ड सीक्रेट दर्ज करें।
JWT के अंदर क्या होता है?
JSON Web Token (RFC 7519) डॉट से जुड़ी तीन base64url स्ट्रिंग होता है: header.payload.signature। हेडर साइनिंग एल्गोरिदम (alg) और टोकन का प्रकार बताता है। पेलोड में क्लेम होते हैं, जैसे यूज़र कौन है और टोकन कब एक्सपायर होगा। सिग्नेचर पहले दो हिस्सों पर किसी सीक्रेट या प्राइवेट की से गणना किया जाता है।
डिकोड करना वेरिफ़ाई करना नहीं है
हेडर और पेलोड सिर्फ़ एनकोड होते हैं, एन्क्रिप्ट नहीं, इसलिए टोकन रखने वाला कोई भी उन्हें पढ़ सकता है। इसीलिए JWT पेलोड में कभी पासवर्ड या सीक्रेट नहीं रखने चाहिए। डिकोड करने से पता चलता है कि टोकन क्या कहता है। सिग्नेचर वेरिफ़ाई करना, आमतौर पर आपके API सर्वर पर jose या PyJWT जैसी लाइब्रेरी से, साबित करता है कि इसे किसने जारी किया और इसमें बदलाव नहीं हुआ। सर्वर को exp, nbf, iss और aud भी जाँचने चाहिए और अनपेक्षित एल्गोरिदम को अस्वीकार करना चाहिए।
रजिस्टर्ड क्लेम्स चीट शीट
| क्लेम | अर्थ |
|---|---|
iss | Issuer: जिसने टोकन बनाया और साइन किया |
sub | Subject: आमतौर पर यूज़र ID |
aud | Audience: टोकन किस API के लिए है |
exp | एक्सपायरी का समय, Unix epoch से सेकंड में |
nbf | इस समय से पहले मान्य नहीं |
iat | जारी होने का समय |
jti | यूनिक टोकन ID, रिवोकेशन लिस्ट के लिए उपयोगी |
“token expired” एरर डिबग करना
अगर कोई API ऐसा टोकन अस्वीकार करता है जो नया दिखता है, तो exp और nbf की तुलना सर्वर की घड़ी से करें। मशीनों के बीच घड़ी में थोड़ा अंतर (clock skew) आम है, इसलिए ज़्यादातर लाइब्रेरी 30-60 सेकंड की छूट देती हैं। यह भी जाँचें कि exp सेकंड में है: मिलीसेकंड वैल्यू एक आम बग है और एक्सपायरी को हज़ारों साल आगे कर देती है।
अक्सर पूछे जाने वाले सवाल
क्या यहाँ प्रोडक्शन JWT पेस्ट करना सुरक्षित है?
क्या यह टूल JWT सिग्नेचर वेरिफ़ाई करता है?
मेरा टोकन एक्सपायर्ड क्यों दिख रहा है?
exp क्लेम आपके कंप्यूटर की घड़ी के हिसाब से बीते समय में है। नया टोकन माँगें, या अपने refresh token से इसे रिफ़्रेश करें। अगर समय गलत लगें, तो clock skew या मिलीसेकंड में लिखी exp वैल्यू जाँचें।JWT, JWS और JWE में क्या अंतर है?
alg “none” खतरनाक क्यों है?
alg: none अस्वीकार करना चाहिए और सिर्फ़ वही खास एल्गोरिदम स्वीकार करना चाहिए जिसकी उसे उम्मीद है।