मुफ़्त JWT जनरेटर

JWT वास्तव में क्या है

JSON वेब टोकन (JWT), उच्चारित «जॉट», दो पक्षों के बीच स्थानांतरित किए जाने वाले दावों का संक्षिप्त, URL-सुरक्षित प्रतिनिधित्व है। प्रारूप तीन Base64url-कोडित खंडों से बना है, बिंदुओं से अलग किया गया: हेडर.पेलोड.हस्ताक्षर। हेडर टोकन प्रकार (हमेशा JWT) और हस्ताक्षर एल्गोरिथ्म (आमतौर पर HS256, RS256 या ES256) घोषित करता है। पेलोड दावों को ले जाता है, एक JSON ऑब्जेक्ट जिसमें मानक फ़ील्ड जैसे iss (जारीकर्ता), sub (विषय), aud (श्रोता), exp (Unix टाइमस्टैम्प के रूप में समाप्ति समय), nbf (इससे पहले नहीं), iat (जारी होने का समय), jti (JWT ID), साथ ही कोई भी एप्लिकेशन-विशिष्ट दावे जो जारीकर्ता शामिल करना चाहता है। हस्ताक्षर क्रिप्टोग्राफ़िक प्रमाण है कि हेडर और पेलोड के साथ छेड़छाड़ नहीं की गई, हेडर में घोषित एल्गोरिथ्म और कुंजी से संयोजित base64url(हेडर).base64url(पेलोड) स्ट्रिंग पर हस्ताक्षर करके बनाया जाता है। JWT को Michael B. Jones, John Bradley और Nat Sakimura ने मई 2015 में RFC 7519 के रूप में निर्दिष्ट किया, जो JOSE (JSON Object Signing and Encryption, RFCs 7515 से 7520) के पूर्व कार्य पर बना है। यह प्रारूप आधुनिक वेब प्रमाणीकरण में प्रमुख टोकन आकार बन गया है, OAuth 2.0 / OIDC कार्यान्वयन, API गेटवे, एकल-पृष्ठ ऐप सत्र टोकन, सूक्ष्म-सेवा-से-सूक्ष्म-सेवा प्रमाणीकरण, और बड़े पैमाने पर ब्राउज़र कुकी-आधारित सत्र प्रबंधन में उपयोग होता है।

हस्ताक्षर एल्गोरिथ्म का चुनाव, HS256 बनाम RS256 बनाम ES256

JWT JOSE एल्गोरिथ्म रजिस्ट्री (RFC 7518) में पंजीकृत कई हस्ताक्षर एल्गोरिथ्मों का समर्थन करता है। HS256 (HMAC-SHA256) सबसे सरल है: एक सममित एल्गोरिथ्म जहाँ एक ही गुप्तकोड से हस्ताक्षर और सत्यापन दोनों होते हैं। गणना सस्ती, लागू करना आसान, और तब उपयुक्त जब हस्ताक्षरकर्ता और सत्यापनकर्ता एक ही पक्ष हों (उदाहरण के लिए, एक अकेला ऐप जो ख़ुद को सत्र टोकन जारी करता है)। RS256 (RSA-SHA256) असममित है: निजी कुंजी हस्ताक्षर करती है, सार्वजनिक कुंजी सत्यापित करती है। तब उपयोग किया जाता है जब जारीकर्ता और सत्यापनकर्ता अलग पक्ष हों, Auth0, Okta, Google Identity Platform, Microsoft Entra ID, और अधिकांश क्लाउड पहचान प्रदाता RS256-हस्ताक्षरित JWT जारी करते हैं क्योंकि क्लाइंट गुप्तकोड साझा किए बिना प्रकाशित JWKS (JSON Web Key Set) एंडपॉइंट का उपयोग करके हस्ताक्षर सत्यापित कर सकते हैं। ES256 (ECDSA P-256 SHA-256) RS256 का दीर्घवृत्ताकार-वक्र समतुल्य है, वही सार्वजनिक/निजी कुंजी मॉडल, बहुत छोटी कुंजियाँ (RSA के 2048 न्यूनतम के मुक़ाबले 256 बिट), तेज़ सत्यापन। EdDSA (Ed25519) ES256 का आधुनिक उत्तराधिकारी है, थोड़ा तेज़ और स्वच्छ क्रिप्टोग्राफ़िक गुणों के साथ; नई JWT लाइब्रेरियों में समर्थित है पर अभी सार्वभौमिक नहीं। none JWT-स्पेक द्वारा अनुमत «कोई हस्ताक्षर नहीं» मोड है जिसने कई लाइब्रेरियों में सुरक्षा घटनाएँ पैदा की हैं जब कार्यान्वयन alg: none टोकन को अस्वीकार करने में विफल रहे, सबक यह है कि JWT सत्यापनकर्ताओं को स्पष्ट रूप से जाँचना चाहिए कि एल्गोरिथ्म अपेक्षित से मेल खाता है। यह जनरेटर HS256 का उपयोग करता है क्योंकि इसे कुंजी निर्माण के बजाय केवल साझा गुप्तकोड चाहिए; असममित एल्गोरिथ्मों के उत्पादन उपयोग के लिए, सर्वर-साइड लाइब्रेरी सही उपकरण है।

जब आपको हाथ से JWT बनाने की ज़रूरत होती है

• API एंडपॉइंट का परीक्षण। कोई API Authorization हेडर में JWT की माँग करती है, इसे curl, Postman या HTTPie से हाथ से परीक्षण करने के लिए, आपको एक टोकन चाहिए। सही आकार का परीक्षण JWT बनाएँ, उसे API के साझा गुप्तकोड से (विकास परिवेशों में) हस्ताक्षर करें, और परिणाम का उपयोग करें।
• टोकन-संबंधित बग पुनःनिर्मिति। कोई उपयोगकर्ता प्रमाणीकरण समस्या रिपोर्ट करता है। उन्हें मिले उनके दावों वाले टोकन को फिर से बनाएँ, हस्ताक्षर की जाँच करें, अपनी सेवा के सत्यापन तर्क को ज्ञात-अच्छे और ज्ञात-बुरे टोकन के विरुद्ध सत्यापित करें।
• बिना auth प्रदाता के स्थानीय विकास। आप ऐसे API के विरुद्ध फ्रंटएंड बना रहे हैं जो JWT प्रमाणीकरण की उम्मीद करता है, पर अभी आपके पास उत्पादन पहचान प्रदाता तक पहुँच नहीं है। विकास के लिए वास्तविक दावों के साथ परीक्षण JWT बनाएँ।
• JWT प्रारूप सीखना। JWT डिकोड करें, एक दावा बदलें, उसे फिर से हस्ताक्षर करें, देखें कि आपका ऐप क्या करता है। हाथ-पर-हाथ डिबगिंग-छेड़छाड़ का लूप वह तरीक़ा है जिससे अधिकांश डेवलपर अंततः JWT संरचना को समझते हैं।
• आंतरिक सेवा-से-सेवा टोकन। दो आंतरिक सूक्ष्म-सेवाएँ एक गुप्तकोड साझा करती हैं और अनुरोधों को प्रमाणित करने के लिए JWT का उपयोग करती हैं। साझा-गुप्तकोड HS256 मॉडल यहाँ उपयुक्त है; यह उपकरण परीक्षण के लिए टोकन को हाथ से बना सकता है।

सुरक्षा गड़बड़ियाँ, जहाँ JWT ग़लत होते हैं

JWT में कार्यान्वयन त्रुटियों का लंबा इतिहास है जिन्होंने वास्तविक सुरक्षा घटनाएँ पैदा की हैं। «alg: none» हमला: शुरुआती JWT लाइब्रेरियाँ एल्गोरिथ्म फ़ील्ड को «none» (कोई हस्ताक्षर नहीं) पर सेट किए गए टोकन स्वीकार करती थीं, जिससे हमलावर कोई भी टोकन गढ़ सकता था। सत्यापनकर्ताओं को अपेक्षित एल्गोरिथ्म स्पष्ट रूप से लागू करना चाहिए। एल्गोरिथ्म भ्रम: RS256 और HS256 दोनों स्वीकार करने वाले सत्यापनकर्ता को सार्वजनिक RSA कुंजी को HMAC गुप्तकोड के रूप में उपयोग करके धोखा दिया जा सकता है, हमलावर सार्वजनिक कुंजी से HS256 में हस्ताक्षर करता है, सत्यापनकर्ता उसी सार्वजनिक कुंजी से HMAC में (ग़लत-)सत्यापित करता है। सत्यापनकर्ताओं को अपेक्षित एल्गोरिथ्म पिन करना चाहिए। पेलोड में संवेदनशील डेटा: JWT दावे Base64-कोडित हैं पर एन्क्रिप्टेड नहीं। टोकन वाला कोई भी हर दावा पढ़ सकता है। पेलोड में पासवर्ड, पूर्ण क्रेडिट-कार्ड नंबर या अन्य गुप्त चीज़ें कभी न रखें। कोई समाप्ति नहीं: exp दावे के बिना JWT हमेशा के लिए वैध होते हैं। हमेशा एक उचित समाप्ति निर्धारित करें (एक्सेस टोकन के लिए मिनट, रिफ्रेश टोकन के लिए दिन)। कोई निरस्तीकरण नहीं: JWT आत्म-निहित हैं, एक बार जारी होने पर, exp तक वैध रहते हैं, चाहे उपयोगकर्ता लॉग आउट कर ले, पासवर्ड बदल ले या उसका खाता निलंबित हो जाए। यह सीमा स्वीकार करें, या निरस्तीकरण सूची बनाए रखें (जो स्थितिहीन-टोकन के मक़सद को आंशिक रूप से समाप्त कर देती है), या रिफ्रेश-टोकन रोटेशन के साथ अल्पकालिक एक्सेस टोकन का उपयोग करें। localStorage बनाम कुकीज़ में संग्रहण: localStorage में JWT पृष्ठ पर चलने वाली किसी भी JavaScript के लिए सुलभ है (XSS जोखिम); HttpOnly कुकीज़ में JWT नहीं है (पर क्रॉस-ओरिजिन अनुरोधों के साथ स्वतः भेजा जाता है, CSRF जोखिम)। दोनों के समझौते हैं; आधुनिक सर्वोत्तम पद्धति SameSite प्रतिबंधों वाली HttpOnly कुकीज़ और CSRF टोकन की ओर झुकती है।

JWT बनाम सत्र कुकीज़ बनाम PASETO

JWT एकमात्र विकल्प नहीं है। पारंपरिक सत्र कुकीज़ एक अपारदर्शी सत्र ID संग्रहीत करती हैं; सर्वर वास्तविक सत्र स्थिति को डेटाबेस या कैश में रखता है। फ़ायदे: मामूली निरस्तीकरण (सर्वर-साइड रिकॉर्ड हटाएँ), दावा डेटा रिसाव का कोई जोखिम नहीं, हस्ताक्षर की जटिलता नहीं। नुक़सान: हर अनुरोध पर सत्र स्टोर लुकअप चाहिए (विलंबता), सेवाओं के बीच स्केल करना कठिन। PASETO (Platform-Agnostic Security Tokens, Scott Arciszewski 2018) JWT का प्रतिस्थापन है जो एल्गोरिथ्म-भ्रम और «none» की गड़बड़ियों से बचने के लिए डिज़ाइन किया गया, संस्करण-अंकित प्रारूप, कोई एल्गोरिथ्म वार्ता नहीं, अनिवार्य हस्ताक्षर, सीमित सिफर विकल्प। PASETO ने सुरक्षा-संवेदनशील संदर्भों में प्रगति की है पर व्यापक पारिस्थितिकी तंत्र में JWT को विस्थापित नहीं किया है। Macaroons (Google, 2014) श्रृंखलाबद्ध क्षमता प्रतिबंधों के साथ अधिक लचीला टोकन प्रारूप है पर 2026 में अनिवार्य रूप से शोध-केवल है। OAuth 2.1 OAuth 2.0 की सर्वोत्तम पद्धतियों को समेकित करता है, JWT अभी भी विशिष्ट एक्सेस-टोकन प्रारूप है। 2026 में व्यावहारिक चुनाव स्थितिहीन सूक्ष्म-सेवाओं और API टोकन के लिए JWT, पारंपरिक सर्वर-रेंडर्ड वेब ऐप्स के लिए अपारदर्शी सत्र कुकीज़, और मज़बूत डिफ़ॉल्ट चाहने वाले नए ग्रीनफ़ील्ड प्रोजेक्ट के लिए आधुनिक विकल्प के रूप में PASETO बना हुआ है।

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

क्या मैं गुप्त कुंजी के बिना JWT डिकोड कर सकता हूं?

हां। JWT के हेडर और पेलोड अनुभाग केवल Base64url-एन्कोडेड होते हैं, एन्क्रिप्टेड नहीं। आप गुप्त कुंजी के बिना सभी क्लेम पढ़ सकते हैं। गुप्त कुंजी केवल यह सत्यापित करने के लिए आवश्यक है कि हस्ताक्षर वैध है (यानी, टोकन के साथ छेड़छाड़ नहीं की गई थी)।

क्या यहां प्रोडक्शन JWT पेस्ट करना सुरक्षित है?

हां। यह टूल पूरी तरह से आपके ब्राउज़र में चलता है, किसी भी सर्वर पर कोई डेटा नहीं भेजा जाता। आपके टोकन और गुप्त कुंजियां केवल आपके स्थानीय JavaScript वातावरण में संसाधित होती हैं और कभी लॉग या प्रसारित नहीं होतीं।

HS256, RS256 और ES256 में क्या अंतर है?

HS256 एक साझा HMAC गुप्त कुंजी (सिमेट्रिक) का उपयोग करता है। RS256 और ES256 सार्वजनिक/निजी कुंजी जोड़े (असिमेट्रिक) का उपयोग करते हैं, निजी कुंजी टोकन पर हस्ताक्षर करती है और सार्वजनिक कुंजी इसे सत्यापित करती है। यह टूल HMAC एल्गोरिथम का समर्थन करता है; RS256/ES256 सत्यापन के लिए सर्वर-साइड लाइब्रेरी का उपयोग करें।