JWT Token को सुरक्षित तरीके से कैसे decode करें (अंदर क्या है)
एक JWT को decode किया जाता है, decrypt नहीं, क्योंकि इसके तीन हिस्से encrypt नहीं बल्कि Base64URL-encoded होते हैं, यानी token रखने वाला कोई भी बिना किसी secret या key के उसकी सामग्री पढ़ सकता है। एक JSON Web Token बस dots से जुड़ी तीन strings है, header.payload.signature, जहाँ header और payload साधारण JSON है जिसे Base64URL में encode किया गया है। यह guide आपको बिल्कुल दिखाती है कि एक JWT के अंदर क्या है, standard claims कैसे पढ़ें, और एक token को decode करने (जिसमें कुछ नहीं चाहिए) व उसे verify करने (जिसमें signing key चाहिए) के बीच का अहम फ़र्क क्या है।
एक JWT में क्या होता है: header, payload, signature
एक JWT में तीन dot-अलग किए segments होते हैं, हर एक Base64URL-encoded: एक header, एक payload, और एक signature। किसी token को उसके दो dots पर तोड़ें और आपको ठीक ये तीन हिस्से मिलते हैं, और पहले दो सीधे वापस पठनीय JSON में decode हो जाते हैं।
header एक छोटा JSON object है जो token type और signing algorithm बताता है, उदाहरण के लिए `{"alg":"HS256","typ":"JWT"}`। payload वह JSON object है जो claims ले जाता है, यानी user या session के बारे में बातें जैसे उनका ID और token की expiry। signature पहले दो segments और एक secret key का एक cryptographic hash है, और बाकियों के विपरीत यह पठनीय text में decode नहीं होती।
चूँकि पहले दो हिस्से सिर्फ़ Base64URL-encoded हैं, इसलिए किसी JWT को decode करना मामूली है: header और payload पर encoding उलट दें और आपको raw JSON दिख जाता है। यह design के हिसाब से है, JWTs उन systems द्वारा पढ़े जाने के लिए बने हैं जो उन्हें पाती हैं।
Decode बनाम Verify: अहम फ़र्क
किसी JWT को decode करने के लिए कोई secret नहीं चाहिए, पर उसे verify करने के लिए signing key चाहिए, और इन दोनों को गड्डमड्ड करना एक गंभीर security गलती है। Decode करना बस Base64URL को उलटकर claims दिखाता है; verify करना secret key से signature फिर से गणना करके साबित करता है कि token असली और अनछुआ है।
इसका मतलब है कि आप कोई भी JWT पढ़ सकते हैं जो आपको मिले, पर उसे पढ़ना आपको यह नहीं बताता कि उस पर भरोसा करना है या नहीं। एक हमलावर किसी valid token को ले सकता है, उसे decode कर सकता है, payload बदलकर खुद को administrator बता सकता है, और फिर से encode कर सकता है। जाली token बिल्कुल सही decode होता है; बस signature verification में fail हो जाता है, क्योंकि हमलावर के पास मेल खाती signature बनाने के लिए ज़रूरी key नहीं है।
servers के लिए नियम: सिर्फ़ decoded payload के आधार पर कभी भरोसे का फ़ैसला न लें। किसी भी claim पर काम करने से पहले हमेशा अपनी key के विरुद्ध signature verify करें, और expiry जाँचें। Decoding जाँच और debugging के लिए है; verification authorization के लिए है।
JWTs encode क्यों होते हैं, encrypt क्यों नहीं
एक मानक signed JWT encode होता है, encrypt नहीं, इसलिए इसका payload token पाने वाले किसी भी व्यक्ति द्वारा पूरी तरह पठनीय होता है, यही वजह है कि आपको इसके अंदर कभी secrets नहीं रखने चाहिए। signature integrity की गारंटी देती है, कि content से छेड़छाड़ नहीं हुई, पर यह कोई privacy नहीं देती; claims सादे, decode किए जा सकने वाले JSON में बैठे होते हैं।
Developers अक्सर यह गलती करते हैं कि संवेदनशील data, passwords, पूरे personal records, internal identifiers, को JWT payload में डाल देते हैं, यह मानकर कि token अपारदर्शी है। यह नहीं है। कोई भी जो token को intercept कर ले, browser storage से, किसी log file से, या network capture से, payload को कुछ सेकंड में decode कर सकता है।
payloads को गैर-संवेदनशील claims तक सीमित रखें: एक user ID, roles, और timing fields। अगर आपको सचमुच सामग्री छिपानी है, तो वह एक अलग रचना है, एक JWE (JSON Web Encryption), जो असल में payload को encrypt करता है। एक सादा signed JWT ऐसा कभी नहीं करता।
standard JWT claims पढ़ना
JWT मानक, RFC 7519, सात registered claim नाम परिभाषित करता है जो systems के बीच एक-सा अर्थ रखते हैं, और ये सभी वैकल्पिक पर व्यापक रूप से इस्तेमाल होते हैं। इन्हें पहचानने से आप किसी भी token का payload एक नज़र में पढ़ सकते हैं, चाहे उसे किसी ने भी जारी किया हो।
इनमें से तीन claims timestamps हैं, exp, iat, और nbf, और ये Unix time के रूप में store होते हैं: 1 जनवरी 1970 UTC से बीते सेकंडों की संख्या। 1767225600 जैसी value कोई random संख्या नहीं है; यह एक तारीख़ है, और इसे बदलने से ठीक-ठीक पता चलता है कि token कब जारी हुआ या कब expire होगा। किसी token की उम्र जानने के लिए, exp में से iat घटाएँ।
नीचे दी table सभी सात registered claims और हर एक का अर्थ बताती है।
| Claim | नाम | अर्थ |
|---|---|---|
| exp | Expiration Time | Unix timestamp जिसके बाद token को अस्वीकार किया जाना चाहिए |
| iat | Issued At | token कब बना, उसका Unix timestamp |
| nbf | Not Before | Unix timestamp जिससे पहले token स्वीकार नहीं होना चाहिए |
| iss | Issuer | token किसने जारी किया, अक्सर एक URL या service नाम |
| sub | Subject | token किसके बारे में है, आमतौर पर एक user ID |
| aud | Audience | इच्छित recipient; आपके API को check करना चाहिए कि वह list में है |
| jti | JWT ID | इस token का एक unique identifier |
क्या मैं किसी JWT को server भेजे बिना decode कर सकता हूँ?
हाँ, एक client-side JWT decoder token को पूरी तरह आपके browser में split और Base64URL-decode करता है, इसलिए token कभी किसी server पर transmit नहीं होता। Decoding शुद्ध string हेरफेर है जो आपके अपने device पर चलती है, header और payload दिखाने के लिए किसी network request की ज़रूरत नहीं।
यह सिर्फ़ सुविधाजनक नहीं, एक असली security control है। एक JWT एक bearer credential है: जो भी इसे रखता है, वह token के expire होने तक user की तरह काम कर सकता है। किसी production token को किसी random online decoder में paste करना उस live credential को किसी अनजान third party को भेज देता है, जो उसे capture और replay कर सकता है। एक tool जो local रूप से decode करता है, इस exposure को पूरी तरह मिटा देता है, जिससे आप असली tokens को बिना किसी और के server को सौंपे जाँच सकते हैं।
अक्सर पूछे जाने वाले सवाल
क्या मैं बिना secret key के JWT decode कर सकता हूँ?
हाँ। header और payload सिर्फ़ Base64URL-encoded होते हैं, इसलिए कोई भी उन्हें बिना किसी key के decode करके पढ़ सकता है। secret सिर्फ़ signature verify या बनाने के लिए ज़रूरी है, claims पढ़ने के लिए नहीं।
क्या JWT encrypted होता है?
एक मानक signed JWT encrypted नहीं होता, सिर्फ़ encoded और signed। payload token रखने वाले किसी भी व्यक्ति द्वारा पठनीय होता है। अगर आपको सचमुच सामग्री encrypted चाहिए तो JWE इस्तेमाल करें।
JWT को decode और verify करने में क्या फ़र्क है?
Decoding claims दिखाती है और किसी secret की ज़रूरत नहीं। Verifying, signing key से signature फिर से गणना करके पुष्टि करती है कि token असली और अनछुआ है। सिर्फ़ verify किए tokens पर ही भरोसा करना चाहिए।
JWT में exp और iat का क्या मतलब है?
ये expiration और issued-at समय हैं, Unix timestamps (1970 से सेकंड) के रूप में store। token की उम्र पाने के लिए exp में से iat घटाएँ; वर्तमान समय के exp पार करते ही token expire हो जाता है।
क्या किसी JWT को online decoder में paste करना सुरक्षित है?
सिर्फ़ तभी जब decoder पूरी तरह आपके browser में चले। एक JWT एक live bearer credential है, और किसी production token को server-side decoder में paste करना उसे किसी third party को भेज देता है जो उसे replay कर सकता है। एक client-side tool इस्तेमाल करें।