एक JSON Web Token, RFC 7519, दावों के एक सेट को एक पक्ष से दूसरे पक्ष तक ले जाने का एक संक्षिप्त तरीका है ताकि प्राप्तकर्ता पक्ष भरोसा कर सके कि उन्हें किसने भेजा, या कम से कम जाँच सके कि ट्रांज़िट में कुछ भी नहीं बदला। हर JWT जो आप किसी Authorization: Bearer हेडर में देखेंगे वही तीन टुकड़े डॉट्स से जुड़े हुए हैं: header.payload.signature।
तीन हिस्से
हेडर और पेलोड प्रत्येक एक JSON ऑब्जेक्ट हैं, base64url एन्कोडेड। हेडर साइनिंग एल्गोरिदम और टोकन प्रकार का नाम देता है, आमतौर पर कुछ इतना छोटा {"alg":"HS256","typ":"JWT"}। पेलोड दावों को रखता है: वह डेटा जो टोकन वास्तव में ले जा रहा है, साथ ही परिभाषित अर्थों वाले कुछ पंजीकृत नाम, iss (जारीकर्ता), sub (विषय), aud (दर्शक), iat (जारी किया गया), nbf (पहले नहीं) और exp (समाप्ति) और jti (एक टोकन आईडी)। विनिर्देश द्वारा इनमें से कुछ भी आवश्यक नहीं है जारीकर्ता के शामिल करने के अलावा, इसलिए दो अलग-अलग सेवाओं से दो JWT पूरी तरह से अलग दावे ले जा सकते हैं।
सिग्नेचर बिल्कुल भी JSON नहीं है। यह हेडर और पेलोड को, अभी भी उनके एन्कोडेड रूप में, हेडर में नामित एल्गोरिदम से चलाने का आउटपुट है, HS256 (HMAC एक साझा गुप्त के साथ) और RS256/ES256 (RSA या ECDSA एक निजी कुंजी के साथ) आपको सबसे अधिक मिलेंगे। Base64url डीकोडिंग सिग्नेचर आपको कच्चे बाइट्स देती है जिनमें पढ़ने के लिए कोई अतिरिक्त संरचना नहीं है।
एन्कोडेड का मतलब एन्क्रिप्टेड नहीं है
Base64url एक एन्कोडिंग है, एक सिफर नहीं। कोई भी व्यक्ति जिसके पास JWT है वह हेडर और पेलोड को केवल एक टेक्स्ट एडिटर से डीकोड कर सकता है, जो ठीक JWT Decoder करता है। इसका मतलब है कि JWT कभी भी उस चीज़ के लिए सही जगह नहीं है जिसे आप URL में नहीं डालेंगे: एक पासवर्ड, एक क्रेडिट कार्ड नंबर, किसी का पूरा नाम जिसे उजागर करने के लिए सहमति नहीं दी गई है। यदि पेलोड को केवल छेड़छाड़ प्रतिरोधी होने के बजाय गोपनीय रहने की आवश्यकता है, तो उसके लिए एक JSON Web Encryption टोकन की आवश्यकता है, एक अलग और कम सामान्य प्रारूप, न कि एक मजबूत एल्गोरिदम वाला साइन किया गया JWT।
डीकोडिंग भरोसे के बारे में कुछ नहीं बताती
यह वह हिस्सा है जिसके लिए डीकोडर्स को सबसे अधिक दोष दिया जाता है, इसलिए इसे स्पष्ट रूप से कहना महत्वपूर्ण है: JWT से दावों को पढ़ना यह साबित नहीं करता कि टोकन असली है। सिग्नेचर को सत्यापित करने का मतलब है इसे वास्तविक गुप्त या सार्वजनिक कुंजी के साथ फिर से गणना करना जिसके साथ टोकन साइन किया गया था और जाँचना कि यह बाइट दर बाइट मेल खाता है। एक डीकोडर जो केवल टोकन को उसके डॉट्स पर विभाजित करता है और तीन में से दो हिस्सों को base64url डीकोड करता है, जो हर शुद्ध क्लाइंट साइड डीकोडर करता है, उस कुंजी तक पहुँच नहीं है और वह जाँच नहीं कर सकता। यह आपको बता सकता है कि टोकन क्या दावा करता है। यह आपको नहीं बता सकता कि उस पर विश्वास करना है या नहीं।
एक अच्छी तरह से बना, साफ डीकोडिंग टोकन अभी भी नकली, समाप्त, या ऐसी कुंजी के साथ साइन किया जा सकता है जिसे कभी जारी करने का इरादा नहीं था। exp और nbf हर डीकोडिंग पर जाँचने के लिए मूल्यवान हैं ठीक इसी कारण से: समाप्ति के बाद का टोकन, या अभी तक वैध नहीं, अमान्य है चाहे उसका सिग्नेचर सही हो या न हो, और उन दोनों फ़ील्ड्स को कच्ची संख्याओं के बजाए उन समय चिन्हों के रूप में पढ़ना जिनका वे प्रतिनिधित्व करते हैं उन्हें एक नज़र में पकड़ने का सबसे तेज़ तरीका है।
यह किस काम आता है
उस सीमा के बावजूद, सत्यापित किए बिना डीकोडिंग के वास्तविक, दैनिक उपयोग हैं: API एकीकरण को डीबग करते समय यह पढ़ना कि एक एक्सेस टोकन किन स्कोप के साथ जारी किया गया था, यह जाँचना कि आपकी ऐप को जो टोकन मिला वह वास्तव में समाप्त हो गया (एक अस्पष्ट 401 से अनुमान लगाने के बजाय), या यह तय करने से पहले किसी तीसरे पक्ष के टोकन में क्या है इसका निरीक्षण करना कि आपकी सेवा को इस पर भरोसा करने की आवश्यकता है या नहीं। इनमें से किसी के लिए भी साइनिंग कुंजी की आवश्यकता नहीं है, केवल टोकन स्वयं की।
JWT Decoder में एक पेस्ट करें और यह हेडर, पंजीकृत दावों और शेष पेलोड को उनकी अपनी पंक्तियों में अलग कर देता है, एक समाप्त या अभी तक वैध न होने वाले टोकन को तुरंत फ़्लैग करता है, और कच्चे सिग्नेचर बाइट्स दिखाता है बिना यह दिखावा किए कि उन्हें किसी से जाँचा गया है।