JWT डिकोडर और सत्यापक

JWT क्या है

एक JSON वेब टोकन (JWT, उच्चारण "जॉट") दो पक्षों के बीच क्लेम ले जाने का एक संक्षिप्त, URL-सुरक्षित तरीका है — अक्सर वह साइन-इन टोकन जो आपके ऐप को किसी उपयोगकर्ता के प्रमाणित होने के बाद मिलता है। इसके तीन भाग होते हैं जो डॉट से अलग होते हैं: header.payload.signature। हेडर और पेलोड JSON ऑब्जेक्ट हैं जो केवल Base64URL-एन्कोडेड होते हैं, इसलिए इन्हें कोई भी पढ़ सकता है — हस्ताक्षर वह है जो साबित करता है कि टोकन बदला नहीं गया और इसे कुंजी रखने वाले किसी व्यक्ति ने जारी किया।

तीन भाग

• हेडर — हस्ताक्षर एल्गोरिथ्म (alg, जैसे HS256 या RS256) और टोकन प्रकार (typ)।
• पेलोड — क्लेम: टोकन किसके बारे में है, किसने जारी किया, कब एक्सपायर होता है, और कोई भी कस्टम डेटा।
• हस्ताक्षर — header.payload का एक कुंजी-आधारित हैश। HMAC के लिए यह एक साझा सीक्रेट का उपयोग करता है; RSA/ECDSA के लिए यह जारीकर्ता की निजी कुंजी का उपयोग करता है और मिलती-जुलती सार्वजनिक कुंजी से जाँचा जाता है।

पंजीकृत क्लेम

हस्ताक्षर सत्यापित करना

सत्यापन पहले दो खंडों पर हस्ताक्षर को फिर से गणना करता है और जाँचता है कि वह तीसरे से मेल खाता है या नहीं। यह टूल HMAC परिवार (HS256, HS384, HS512) को सत्यापित करता है जब आप साझा सीक्रेट देते हैं, ब्राउज़र के नेटिव crypto.subtle का उपयोग करते हुए। असममित टोकन (RS256, ES256, PS256) पूरी तरह डिकोड होते हैं, पर उनके हस्ताक्षर केवल जारीकर्ता की सार्वजनिक कुंजी (उसके JWKS एंडपॉइंट से) से सत्यापित हो सकते हैं, इसलिए यहाँ जाँचे नहीं जाते। डिकोड किया गया टोकन कभी वैधता का प्रमाण नहीं होता — हमेशा exp, nbf, aud और iss की भी पुष्टि करें।

हल किया गया उदाहरण

नीचे दिया गया क्लासिक RFC 7519 नमूना टोकन HS256 का उपयोग सीक्रेट your-256-bit-secret के साथ करता है। इसका हेडर {"alg":"HS256","typ":"JWT"} में डिकोड होता है और इसका पेलोड {"sub":"1234567890","name":"John Doe","iat":1516239022} में — वह iat 23 जनवरी 2018 है। तुरंत डिकोड और सत्यापित करने के लिए ऊपर उदाहरण लोड करें पर क्लिक करें।

JWT कहाँ से आते हैं: JOSE परिवार

JSON वेब टोकन RFC 7519 (मई 2015) द्वारा परिभाषित है, जो संबंधित मानकों के एक समूह में से एक है जिन्हें सामूहिक रूप से JOSE (JavaScript Object Signing and Encryption) कहा जाता है। जिस हस्ताक्षर तंत्र को यह टूल जाँचता है वह JWS (JSON Web Signature, RFC 7515) से आता है; HS256 और RS256 जैसे अनुमत एल्गोरिथ्म की सूची JWA (JSON Web Algorithms, RFC 7518) से आती है; सार्वजनिक कुंजियाँ प्रकाशित करने का प्रारूप JWK (JSON Web Key, RFC 7517) से आता है; और एक अलग मानक, JWE (JSON Web Encryption, RFC 7516), उन टोकनों के लिए है जिनकी सामग्री वास्तव में छिपी होती है। एक साधारण JWT — जिस तरह का आपको लगभग किसी भी आधुनिक वेब ऐप में साइन इन करने पर मिलता है — एक JWS है: हस्ताक्षरित, पर एन्क्रिप्टेड नहीं।

हस्ताक्षरित, गुप्त नहीं

किसी मानक JWT के बारे में समझने वाली सबसे महत्वपूर्ण बात यह है कि यह हस्ताक्षरित है, एन्क्रिप्टेड नहीं। हेडर और पेलोड केवल Base64URL-एन्कोडेड होते हैं — एक एन्कोडिंग, एन्क्रिप्शन नहीं — इसलिए टोकन रखने वाला कोई भी उसके भीतर हर क्लेम को डिकोड करके पढ़ सकता है, ठीक जैसे यह टूल करता है, बिना किसी कुंजी के। हस्ताक्षर सामग्री को छिपाता नहीं; यह केवल दो बातें साबित करता है: कि जारी होने के बाद से टोकन बदला नहीं गया, और कि जिसने इसे जारी किया उसके पास हस्ताक्षर कुंजी थी। इससे जो नियम निकलता है वह पूर्ण है: JWT पेलोड में कभी कुछ ऐसा न डालें जिसे धारक को देखने की अनुमति नहीं होनी चाहिए — कोई पासवर्ड नहीं, कोई API कुंजी नहीं, कोई संवेदनशील व्यक्तिगत डेटा नहीं। यदि सामग्री वास्तव में गोपनीय होनी चाहिए, तो आपको JWE (एन्क्रिप्शन) चाहिए, न कि एक साधारण हस्ताक्षरित JWT।

HMAC बनाम RSA/ECDSA: हस्ताक्षर करने के दो तरीके

JWS हस्ताक्षर दो परिवारों में आते हैं। HMAC एल्गोरिथ्म (HS256, HS384, HS512) सममित होते हैं: एक ही साझा सीक्रेट हस्ताक्षर बनाता भी है और सत्यापित भी करता है। ये सरल और तेज़ हैं और तब आदर्श हैं जब एक ही पक्ष टोकन जारी और जाँचता है। यह टूल HMAC टोकन सीधे सत्यापित कर सकता है, क्योंकि यदि आपके पास सीक्रेट है तो आपके ब्राउज़र में हस्ताक्षर फिर से गणना करने के लिए ज़रूरी सब कुछ आपके पास है।

RSA (RS256/384/512, PS256/…) और ECDSA (ES256/…) एल्गोरिथ्म असममित होते हैं: जारीकर्ता एक निजी कुंजी से हस्ताक्षर करता है जिसे वह कभी साझा नहीं करता, और कोई भी मिलती-जुलती सार्वजनिक कुंजी से सत्यापित कर सकता है। यही बड़े पहचान प्रदाता उपयोग करते हैं, क्योंकि हज़ारों स्वतंत्र सेवाएँ किसी टोकन को टोकन बनाने की शक्ति सौंपे बिना मान्य कर सकती हैं। सार्वजनिक कुंजियाँ एक well-known JWKS (JSON Web Key Set) एंडपॉइंट पर प्रकाशित होती हैं। यह टूल असममित टोकन पूरी तरह डिकोड करता है पर दूरस्थ कुंजियाँ नहीं लाता, इसलिए उनके हस्ताक्षर सत्यापित नहीं करता — वह जाँच आपके सर्वर पर, जारीकर्ता के JWKS के विरुद्ध होनी चाहिए।

JWT का उपयोग ही क्यों करें? स्टेटलेस प्रमाणीकरण

एक पारंपरिक वेब सेशन एक यादृच्छिक सेशन ID को कुकी में रखता है और असली सेशन डेटा सर्वर मेमोरी या डेटाबेस में रखता है, इसलिए हर अनुरोध के लिए एक लुकअप ज़रूरी होता है। एक JWT इसे उलट देता है: उपयोगकर्ता की पहचान और अनुमतियाँ हस्ताक्षरित टोकन के भीतर ही लिखी जाती हैं। जब कोई अनुरोध आता है, तो सर्वर को बस हस्ताक्षर सत्यापित करना और क्लेम पढ़ना होता है — कोई डेटाबेस राउंड-ट्रिप नहीं, कोई साझा सेशन स्टोर नहीं। यही स्टेटलेसनेस JWT को APIs, माइक्रोसर्विसेज़ और क्षैतिज-रूप से स्केल किए गए सिस्टम के लिए लोकप्रिय बनाती है, जहाँ किसी फ़्लीट का कोई भी सर्वर स्वयं एक टोकन मान्य कर सकता है। टोकन आमतौर पर हर अनुरोध पर एक HTTP हेडर में Authorization: Bearer <token> के रूप में भेजा जाता है।

स्टेटलेसनेस का दूसरा पहलू रद्दीकरण समस्या (revocation problem) है: क्योंकि सर्वर जारी किए गए टोकनों का कोई रिकॉर्ड नहीं रखता, वह किसी टोकन के एक्सपायर होने से पहले आसानी से किसी को "लॉग आउट" नहीं कर सकता। मानक उपाय हैं छोटे एक्सपायरी समय, रद्द किए गए टोकन IDs की एक सर्वर-साइड डिनायलिस्ट (jti क्लेम), या हस्ताक्षर कुंजी घुमाना — इनमें से हर एक नियंत्रण के बदले थोड़ी स्थिति (state) फिर से जोड़ देता है।

"alg: none" भेद्यता

प्रारंभिक JWT लाइब्रेरियाँ none के विशेष एल्गोरिथ्म मान का सम्मान करती थीं, जिसका अर्थ है कि टोकन अहस्ताक्षरित है। कोई हमलावर एक मान्य टोकन ले सकता है, पेलोड बदल सकता है (उदाहरण के लिए "role":"user" को "role":"admin" में पलट देना), हेडर एल्गोरिथ्म को none पर सेट कर सकता है, हस्ताक्षर हटा सकता है, और एक भोला सर्वर उसे स्वीकार कर लेगा। बचाव यह है कि प्रोडक्शन में कभी none स्वीकार न करें और एल्गोरिथ्म को टोकन के अपने हेडर के मान पर भरोसा करने के बजाय एक स्पष्ट अनुमति-सूची के विरुद्ध मान्य करें। यह टूल किसी भी ऐसे टोकन को अहस्ताक्षरित और जाली बनाने योग्य के रूप में चिह्नित करता है जिसका हेडर alg: none घोषित करता है।

RS256-से-HS256 कन्फ़्यूज़न अटैक

एक अधिक सूक्ष्म और प्रसिद्ध खामी है एल्गोरिथ्म-कन्फ़्यूज़न (या कुंजी-कन्फ़्यूज़न) अटैक। एक सर्वर RS256 (असममित) की अपेक्षा करता है और टोकनों को जारीकर्ता की सार्वजनिक कुंजी से सत्यापित करता है — जो, परिभाषा के अनुसार, सार्वजनिक है। यदि सत्यापन कोड टोकन में नामित एल्गोरिथ्म पर भरोसा करता है, तो कोई हमलावर हेडर को HS256 में बदल सकता है और उस सार्वजनिक कुंजी को मानो वह एक HMAC सीक्रेट हो, इस्तेमाल करके एक जाली टोकन हस्ताक्षरित कर सकता है। एक लाइब्रेरी जो आँख मूँदकर HMAC पर स्विच कर जाती है, वह फिर उसी कुंजी के विरुद्ध जालसाज़ी को "सत्यापित" कर लेगी जिसका हमलावर ने उपयोग किया। बचाव वही है जो alg: none के लिए: सर्वर को अपेक्षित एल्गोरिथ्म पिन करना चाहिए और टोकन को यह कभी तय नहीं करने देना चाहिए कि इसे कैसे जाँचा जाए।

हस्ताक्षर से आगे भी सत्यापित करें

एक मान्य हस्ताक्षर केवल यह साबित करता है कि टोकन प्रामाणिक और अपरिवर्तित है — यह साबित नहीं करता कि टोकन अभी स्वीकार किया जाना चाहिए। एक सही सत्यापक पंजीकृत क्लेम भी जाँचता है: exp (क्या यह एक्सपायर्ड है?), nbf (क्या इसे बहुत जल्दी इस्तेमाल किया जा रहा है?), aud (क्या यह सेवा अभिप्रेत ऑडियंस है?) और iss (क्या किसी भरोसेमंद जारीकर्ता ने इसे बनाया?)। एक टोकन जो पूरी तरह हस्ताक्षरित है पर एक्सपायर्ड है, या किसी अलग ऑडियंस के लिए है, अस्वीकार किया जाना चाहिए। यही ठीक वजह है कि कोई सर्वर वैध रूप से ऐसे टोकन को अस्वीकार कर सकता है जिसे यह टूल एक मान्य HMAC हस्ताक्षर वाला दिखाता है।

पंजीकृत, सार्वजनिक और निजी क्लेम

RFC 7519 क्लेम को तीन समूहों में बाँटता है। पंजीकृत क्लेम (Registered claims) ऊपर की तालिका में दिए संक्षिप्त, मानक नाम हैं (iss, sub, aud, exp, nbf, iat, jti) — इनमें से कोई अनिवार्य नहीं है, पर इन्हें लगातार उपयोग करने से टोकन इंटरऑपरेबल बने रहते हैं। सार्वजनिक क्लेम (Public claims) वे नाम हैं जो IANA JSON Web Token रजिस्ट्री में पंजीकृत हैं या किसी टकराव-प्रतिरोधी URI से नेमस्पेस किए गए हैं। निजी क्लेम (Private claims) वे कस्टम फ़ील्ड हैं जिन पर आपका अपना ऐप्लिकेशन सहमत होता है — एक role, scopeों की एक सूची, एक टेनेंट ID। पेलोड छोटे रखना मायने रखता है: टोकन हर अनुरोध पर यात्रा करता है, इसलिए एक फूला हुआ JWT हर कॉल पर एक वास्तविक बैंडविड्थ और हेडर-आकार लागत बन जाता है।

एक्सेस टोकन, रिफ़्रेश टोकन और उन्हें कहाँ रखें

चूँकि चुराया गया एक्सेस टोकन एक्सपायर होने तक पहुँच देता है, अच्छे सिस्टम उन्हें अल्पकालिक रखते हैं — अक्सर 5 से 15 मिनट — और उन्हें एक लंबे-जीवन वाले रिफ़्रेश टोकन के साथ जोड़ते हैं जिसका उपयोग केवल नए एक्सेस टोकन प्राप्त करने के लिए होता है और जिसे केंद्रीय रूप से रद्द किया जा सकता है। किसी ब्राउज़र में आप टोकन कहाँ रखते हैं यह स्वयं एक सुरक्षा निर्णय है। इसे localStorage में रखना सुविधाजनक है पर इसे पेज पर किसी भी क्रॉस-साइट-स्क्रिप्टिंग (XSS) बग के सामने उजागर कर देता है, जो इसे पढ़ सकता है। इसे एक HttpOnly कुकी में रखना इसे JavaScript से छिपाता है (XSS को कम करता है) पर अनुरोध को क्रॉस-साइट रिक्वेस्ट फ़ोर्जरी (CSRF) के प्रति संवेदनशील बना देता है जब तक कि आप SameSite विशेषता या एक एंटी-CSRF टोकन न जोड़ें। कोई एक सही उत्तर नहीं है — केवल आपके ख़तरे-मॉडल के लिए एक सूचित समझौता।

एक JWT सुरक्षा चेकलिस्ट

• एल्गोरिथ्म पिन करें। अपने कोड में HS256 या RS256 तय करें और बाक़ी सब कुछ, none सहित, अस्वीकार करें।
• मज़बूत HMAC सीक्रेट का उपयोग करें। HS256 के लिए सीक्रेट कम से कम 256 बिट (32 यादृच्छिक बाइट) वास्तविक एन्ट्रॉपी का होना चाहिए — एक शब्दकोश-शब्द एक हमलावर के पास टोकन आते ही ऑफ़लाइन कुछ ही पलों में ब्रूट-फ़ोर्स हो जाता है, क्योंकि सत्यापन स्थानीय और असीमित होता है।
• पेलोड को ग़ैर-गुप्त रखें। हस्ताक्षरित JWT में हर चीज़ को धारक द्वारा पठनीय मानें।
• exp सेट और जाँचें। छोटे जीवनकाल लीक हुए टोकन के नुक़सान को सीमित करते हैं।
• aud और iss मान्य करें ताकि किसी अन्य सेवा के लिए या किसी अन्य जारीकर्ता से बना टोकन आपके विरुद्ध रीप्ले न किया जा सके।
• असममित टोकनों को जारीकर्ता के JWKS सार्वजनिक कुंजी (कैश और रिफ़्रेश किए हुए) के विरुद्ध सत्यापित करें — कभी टोकन में एम्बेडेड कुंजी के विरुद्ध नहीं।
• एक रद्दीकरण योजना रखें — एक jti डिनायलिस्ट या कुंजी घुमाव — उन मामलों के लिए जिन्हें छोटी एक्सपायरी कवर नहीं कर सकती।

इस तरह उपयोग किए जाने पर, JWT एक मज़बूत, अच्छी तरह समझा गया बिल्डिंग ब्लॉक हैं। जंगल में अधिकांश JWT घटनाएँ क्रिप्टोग्राफ़ी से नहीं बल्कि छोड़ी गई जाँचों से आती हैं — none स्वीकार करना, हेडर के एल्गोरिथ्म पर भरोसा करना, या एक अनुमान-योग्य HMAC सीक्रेट का उपयोग करना — जिनमें से हर एक रोका जा सकता है।

Base64URL एन्कोडिंग क्या है

किसी JWT के डॉट तीन Base64URL-एन्कोडेड खंडों को अलग करते हैं। Base64URL सामान्य Base64 का एक क़रीबी चचेरा भाई है जो किसी URL में डालने के लिए सुरक्षित है: यह + और / वर्णों को - और _ से बदल देता है, और आमतौर पर = पैडिंग छोड़ देता है। हेडर और पेलोड पर लागू यही एकमात्र "रूपांतरण" है — कोई कम्प्रेशन नहीं और कोई एन्क्रिप्शन नहीं, यही वजह है कि यह टूल (और कोई भी और) इन्हें केवल टोकन के साथ पढ़ सकता है। हस्ताक्षर खंड कच्चे हस्ताक्षर बाइट की Base64URL एन्कोडिंग है, टेक्स्ट की नहीं, यही वजह है कि यह पठनीय JSON के बजाय यादृच्छिक वर्णों जैसा दिखता है।

JWT बनाम ओपेक सेशन टोकन

JWT ही एकमात्र प्रकार का टोकन नहीं है। क्लासिक विकल्प एक ओपेक टोकन (opaque token) है — एक लंबी यादृच्छिक स्ट्रिंग जो अपने आप में कुछ अर्थ नहीं रखती और बस सेशन डेटा के एक सर्वर-साइड स्टोर में एक लुकअप कुंजी होती है। समझौता JWT के बिल्कुल उलट है: एक ओपेक टोकन इंटरसेप्ट होने पर कुछ प्रकट नहीं करता और इसे तुरंत रद्द किया जा सकता है (बस सर्वर रिकॉर्ड मिटा दें), पर हर अनुरोध के लिए वह लुकअप ज़रूरी होता है, इसलिए यह स्टेटलेस नहीं है। एक JWT को किसी लुकअप की ज़रूरत नहीं होती और यह सर्वरों के पार आसानी से स्केल करता है, पर यह पठनीय, बड़ा, और एक्सपायरी से पहले रद्द करने में असुविधाजनक होता है। कई सिस्टम दोनों का उपयोग करते हैं — तेज़ API प्राधिकरण के लिए अल्पकालिक JWT, जिन्हें नवीनीकृत करने के लिए एक ओपेक, रद्द-करने-योग्य रिफ़्रेश टोकन समर्थन देता है — हर एक की ताक़तें लेते हुए।

अक्सर पूछे जाने वाले सवाल

क्या मेरा टोकन कहीं अपलोड होता है?

नहीं। डिकोडिंग और हस्ताक्षर सत्यापन पूरी तरह आपके ब्राउज़र में बिल्ट-इन Web Crypto API का उपयोग करके होते हैं। टोकन और सीक्रेट कभी आपके डिवाइस से बाहर नहीं जाते और न कभी लॉग या ट्रांसमिट होते हैं — इसलिए ऐसे टोकन जाँचना सुरक्षित है जिन्हें किसी सर्वर-साइड टूल में पेस्ट करना जोखिमभरा हो। पेज लोड होने के बाद यह ऑफ़लाइन भी काम करता है।

क्या डिकोड किया गया JWT गुप्त या एन्क्रिप्टेड होता है?

नहीं। एक मानक JWT हस्ताक्षरित होता है, एन्क्रिप्टेड नहीं — हेडर और पेलोड केवल Base64URL में एन्कोड होते हैं, इसलिए टोकन रखने वाला कोई भी उन्हें पढ़ सकता है। हस्ताक्षर सामग्री को छिपाता नहीं; यह केवल यह साबित करता है कि टोकन से छेड़छाड़ नहीं हुई और इसे कुंजी जानने वाले किसी व्यक्ति ने जारी किया। कभी भी ऐसे रहस्य JWT पेलोड में न डालें जिन्हें आप क्लाइंट को दिखाना नहीं चाहते।

यह टूल कौन-से हस्ताक्षर सत्यापित कर सकता है?

यह HMAC हस्ताक्षर सत्यापित करता है — HS256, HS384 और HS512 — जब आप साझा सीक्रेट देते हैं, नेटिव Web Crypto API का उपयोग करते हुए। असममित एल्गोरिथ्म (RS256, ES256, PS256, EdDSA) पूरी तरह डिकोड तो होते हैं, पर उनके हस्ताक्षर जारीकर्ता की सार्वजनिक कुंजी से सत्यापित होते हैं, जो केवल जारीकर्ता के well-known एंडपॉइंट के पास होती है, इसलिए यह टूल उन्हें सत्यापित नहीं करता।

यहाँ "एक्सपायर्ड" का क्या मतलब है?

यदि पेलोड में exp (एक्सपायरी) क्लेम है और वह क्षण आपके डिवाइस की घड़ी की तुलना में बीत चुका है, तो टोकन एक्सपायर्ड दिखाया जाता है। इसी तरह भविष्य में nbf (not-before) क्लेम "अभी मान्य नहीं" दिखाया जाता है। ये सीधे डिकोड किए गए क्लेम से पढ़े जाते हैं; एक्सपायरी जाँच आमतौर पर उस सर्वर द्वारा की जाती है जो टोकन प्राप्त करता है।

हस्ताक्षर "मान्य" होने पर भी सर्वर मेरा टोकन क्यों अस्वीकार करता है?

मान्य हस्ताक्षर केवल यह बताता है कि टोकन बदला नहीं गया और कुंजी मेल खाती है। सर्वर फिर भी इसे अस्वीकार कर सकता है क्योंकि यह एक्सपायर्ड (exp) है, बहुत जल्दी इस्तेमाल हुआ (nbf), गलत ऑडियंस (aud) या जारीकर्ता (iss) है, या रद्द कर दिया गया। डिकोड किए गए पेलोड में इन क्लेम्स को भी जाँचें।

संबंधित टूल

• Base64 एन्कोडर / डिकोडर
• JSON फ़ॉर्मैटर और वैलिडेटर
• SHA हैश जनरेटर
• यूनिक्स टाइमस्टैम्प कन्वर्टर
• UUID जनरेटर

सभी ब्राउज़र टूल देखें → · सभी डेवलपर और डेटा रूपांतरण →