इस लेख में
JWT क्या होता है?
JWT (JSON Web Token) एक सघन, URL-सुरक्षित टोकन स्वरूप है जिसका उपयोग पक्षों के बीच जानकारी को एक JSON ऑब्जेक्ट के रूप में सुरक्षित तरीके से भेजने के लिए किया जाता है। RFC 7519 द्वारा परिभाषित JWT आधुनिक वेब एप्लिकेशन और API में प्रमाणीकरण तथा प्राधिकरण के वास्तविक मानक हैं।
JWT स्वयं-निहित होते हैं — वे टोकन की प्रामाणिकता सत्यापित करने और उपयोगकर्ता के दावों को निकालने के लिए ज़रूरी सारी जानकारी बिना किसी डेटाबेस को क्वेरी किए अपने साथ रखते हैं। यह इन्हें वितरित प्रणालियों और माइक्रोसर्विस आर्किटेक्चर में स्टेटलेस प्रमाणीकरण के लिए आदर्श बनाता है।
JWT की संरचना
एक JWT तीन Base64URL-एन्कोडेड हिस्सों से बना होता है जो बिंदुओं से अलग होते हैं: header.payload.signature।
- Header — एक JSON ऑब्जेक्ट जो टोकन प्रकार (JWT) और साइनिंग एल्गोरिदम (जैसे, HS256, RS256, ES256) निर्दिष्ट करता है
- Payload — एक JSON ऑब्जेक्ट जिसमें दावे होते हैं: पंजीकृत दावे (iss, sub, exp, iat), सार्वजनिक दावे और निजी दावे
- Signature — एन्कोडेड header और payload को एक गुप्त कुंजी (HMAC) या निजी कुंजी (RSA/ECDSA) से साइन करके बनाई जाती है
निःशुल्क आज़माएँ — कोई साइनअप आवश्यक नहीं
JWT सत्यापित करें →JWT सत्यापन कैसे काम करता है
JWT सत्यापन में संरचनात्मक जाँच, हस्ताक्षर सत्यापन और दावों का सत्यापन शामिल होता है।
- संरचना की जाँच — टोकन में ठीक तीन Base64URL-एन्कोडेड खंड होने चाहिए जो दो बिंदुओं से अलग हों
- Header सत्यापन — header में मान्य typ और alg फ़ील्ड होने चाहिए। एल्गोरिदम वही होना चाहिए जिसकी सर्वर अपेक्षा करता है
- हस्ताक्षर सत्यापन — header, payload और साइनिंग कुंजी का उपयोग करके हस्ताक्षर की दोबारा गणना की जाती है। यदि दोबारा गणना किया गया हस्ताक्षर मेल खाता है, तो टोकन के साथ छेड़छाड़ नहीं हुई है
- दावों का सत्यापन — exp (समाप्ति), nbf (इससे पहले नहीं) और iss (जारीकर्ता) दावों को वर्तमान समय और अपेक्षित मानों के विरुद्ध जाँचा जाता है
आम इस्तेमाल के मामले
JWT आधुनिक वेब स्टैक में प्रमाणीकरण और प्राधिकरण को शक्ति देते हैं।
- API प्रमाणीकरण — क्लाइंट सत्रों के बिना API अनुरोधों को प्रमाणित करने के लिए Authorization हेडर (Bearer योजना) में JWT शामिल करते हैं
- सिंगल साइन-ऑन (SSO) — पहचान प्रदाता ऐसे JWT जारी करते हैं जिन्हें कई एप्लिकेशन स्वीकार करते हैं, जिससे एप्लिकेशनों के बीच सहज प्रमाणीकरण संभव होता है
- OAuth 2.0 एक्सेस टोकन — कई OAuth कार्यान्वयन JWT को एक्सेस टोकन के रूप में इस्तेमाल करते हैं, जो स्कोप और अनुमतियों को सीधे टोकन में कूटबद्ध करते हैं
- माइक्रोसर्विस संचार — सेवाएँ उपयोगकर्ता संदर्भ और प्राधिकरण निर्णयों को सेवा सीमाओं के पार पहुँचाने के लिए JWT भेजती हैं
JWT सुरक्षा की सर्वोत्तम प्रथाएँ
JWT शक्तिशाली हैं पर आम सुरक्षा खतरों से बचने के लिए इन्हें सावधानी से संभालना ज़रूरी है।
- हमेशा एल्गोरिदम सत्यापित करें — टोकन के alg फ़ील्ड को कभी यह तय न करने दें कि आपका सर्वर कौन-सा एल्गोरिदम इस्तेमाल करेगा। यह none एल्गोरिदम हमले को रोकता है
- समाप्ति का समय कम रखें — एक बार जारी होने के बाद JWT को रद्द नहीं किया जा सकता। exp का समय कम रखें (एक्सेस टोकन के लिए 15 मिनट) और लंबे सत्रों के लिए रिफ़्रेश टोकन का उपयोग करें
- वितरित प्रणालियों के लिए असममित एल्गोरिदम का उपयोग करें — RS256 या ES256 सेवाओं को साइनिंग गुप्त कुंजी साझा किए बिना टोकन सत्यापित करने देते हैं
- payload में कभी संवेदनशील डेटा न रखें — JWT एन्कोडेड होते हैं, एन्क्रिप्टेड नहीं। कोई भी payload को डिकोड कर सकता है। गुप्त जानकारी टोकन में नहीं, अपने डेटाबेस में रखें
अक्सर पूछे जाने वाले सवाल
क्या गुप्त कुंजी के बिना किसी JWT को डिकोड किया जा सकता है?
हाँ। JWT payload Base64URL-एन्कोडेड होते हैं, एन्क्रिप्टेड नहीं। कोई भी header और payload को डिकोड करके पढ़ सकता है। गुप्त कुंजी केवल हस्ताक्षर सत्यापित करने के लिए ज़रूरी है — यह पुष्टि करने के लिए कि टोकन बदला नहीं गया है।
JWS और JWE में क्या अंतर है?
JWS (JSON Web Signature) वही है जिसे अधिकांश लोग JWT कहते हैं — एक साइन किया हुआ टोकन। JWE (JSON Web Encryption) एक एन्क्रिप्टेड टोकन है जिसका payload डिक्रिप्शन कुंजी के बिना नहीं पढ़ा जा सकता। अधिकांश JWT, JWS टोकन होते हैं।
मुझे JWT को localStorage में रखना चाहिए या कुकीज़ में?
HttpOnly कुकीज़ अधिक सुरक्षित हैं क्योंकि वे JavaScript के ज़रिए पहुँच योग्य नहीं होतीं (जिससे XSS चोरी रुकती है)। localStorage, XSS हमलों के प्रति असुरक्षित है। संवेदनशील एप्लिकेशन के लिए HttpOnly Secure SameSite कुकीज़ का उपयोग करें।