इस लेख में
JWT क्या है?
एक JSON Web Token (JWT) एक संक्षिप्त, URL-सुरक्षित टोकन फ़ॉर्मेट है जो पक्षों के बीच JSON ऑब्जेक्ट के रूप में जानकारी को सुरक्षित रूप से भेजने के लिए इस्तेमाल होता है। एक JWT में डॉट से अलग किए गए तीन Base64URL-एन्कोडेड हिस्से होते हैं: header.payload.signature। हेडर हस्ताक्षर एल्गोरिथम निर्दिष्ट करता है, पेलोड में दावे (डेटा) होते हैं, और हस्ताक्षर यह सत्यापित करता है कि टोकन के साथ छेड़छाड़ नहीं हुई है।
JWT स्टेटलेस प्रमाणीकरण को संभव बनाते हैं — सर्वर को सत्र डेटा संग्रहीत करने की ज़रूरत नहीं होती क्योंकि सारी आवश्यक जानकारी टोकन के भीतर ही समाहित होती है। यह JWT को वितरित प्रणालियों, माइक्रोसर्विसेज़ और APIs के लिए आदर्श बनाता है, जहाँ सत्र भंडारण जटिलता और विलंबता जोड़ देता।
JWT संरचना की व्याख्या
हर JWT तीन अलग हिस्सों से बना होता है, जिनमें से हर एक टोकन के जीवनचक्र में एक विशिष्ट उद्देश्य पूरा करता है:
- हेडर — एक JSON ऑब्जेक्ट जो टोकन प्रकार (typ: JWT) और हस्ताक्षर एल्गोरिथम (alg: HS256, RS256, आदि) निर्दिष्ट करता है, फिर Base64URL-एन्कोडेड होता है
- पेलोड — एक JSON ऑब्जेक्ट जिसमें iss (issuer), sub (subject), exp (समाप्ति समय), iat (issued at) जैसे दावे और आपके द्वारा भेजा जाने वाला कोई भी कस्टम डेटा होता है
- हस्ताक्षर — एन्कोडेड हेडर और पेलोड को एक गुप्त कुंजी (HMAC) या निजी कुंजी (RSA/ECDSA) से हस्ताक्षरित करके बनाया जाता है, जो टोकन की अखंडता सुनिश्चित करता है
पेलोड एन्क्रिप्टेड नहीं होता — कोई भी उसे डिकोड करके पढ़ सकता है। JWT पेलोड में पासवर्ड या क्रेडिट कार्ड नंबर जैसी संवेदनशील जानकारी कभी न रखें। हस्ताक्षर केवल यह गारंटी देता है कि डेटा में बदलाव नहीं हुआ है, यह नहीं कि वह छिपा हुआ है।
हस्ताक्षर एल्गोरिथम
हस्ताक्षर एल्गोरिथम का चुनाव यह तय करता है कि JWT हस्ताक्षर कैसे बनाया और सत्यापित किया जाता है। एल्गोरिथम के तीन मुख्य परिवार हैं:
- HMAC (HS256, HS384, HS512) — सममित एल्गोरिथम जो हस्ताक्षर और सत्यापन दोनों के लिए एक ही गुप्त कुंजी का उपयोग करते हैं। इन्हें लागू करना सरल है, और ये एकल-सर्वर सेटअप के लिए सर्वोत्तम हैं जहाँ जारीकर्ता और सत्यापनकर्ता एक ही गुप्त कुंजी साझा करते हैं
- RSA (RS256, RS384, RS512) — असममित एल्गोरिथम जो हस्ताक्षर के लिए निजी कुंजी और सत्यापन के लिए सार्वजनिक कुंजी का उपयोग करते हैं। ये वितरित प्रणालियों के लिए आदर्श हैं जहाँ कई सेवाओं को हस्ताक्षर कुंजी तक पहुँच के बिना टोकन सत्यापित करने की ज़रूरत होती है
- ECDSA (ES256, ES384, ES512) — असममित एल्गोरिथम जो इलिप्टिक कर्व क्रिप्टोग्राफ़ी का उपयोग करते हैं। ये काफ़ी छोटे कुंजी आकार और तेज़ गणना के साथ RSA जैसी ही सुरक्षा प्रदान करते हैं, जिससे ये मोबाइल और IoT एप्लिकेशन के लिए ख़ूब उपयुक्त होते हैं
अधिकांश वेब एप्लिकेशन के लिए, HS256 पर्याप्त है जब टोकन जारीकर्ता और उपभोक्ता दोनों एक ही सर्वर हों। जब टोकन को तृतीय पक्षों द्वारा या विभिन्न सेवाओं में सत्यापित करने की ज़रूरत हो, तब RS256 या ES256 चुनें।
निःशुल्क आज़माएँ — कोई साइनअप आवश्यक नहीं
JWT बनाएँ और हस्ताक्षरित करें →एन्कोडिंग बनाम डिकोडिंग
किसी JWT को एन्कोड करने का अर्थ है हेडर, पेलोड को जोड़कर और अपनी गुप्त या निजी कुंजी से हस्ताक्षर बनाकर एक नया टोकन तैयार करना। यह आम तौर पर लॉगिन या टोकन रिफ़्रेश के दौरान सर्वर की ओर किया जाता है। परिणामी टोकन स्ट्रिंग को आगे के प्रमाणित अनुरोधों के लिए क्लाइंट को भेजा जाता है।
किसी JWT को डिकोड करने के दो अर्थ हो सकते हैं: हस्ताक्षर सत्यापित किए बिना पेलोड के दावे निकालना (क्लाइंट पर टोकन मेटाडेटा पढ़ने के लिए उपयोगी), या टोकन के प्रामाणिक और अछूता होने की पुष्टि के लिए हस्ताक्षर को पूरी तरह सत्यापित करना। प्रोडक्शन सिस्टम को पेलोड में मौजूद किसी भी दावे पर भरोसा करने से पहले हमेशा हस्ताक्षर सत्यापित करना चाहिए।
आम उपयोग के मामले
JWT वेब और मोबाइल एप्लिकेशन में आधुनिक प्रमाणीकरण तथा प्राधिकरण पैटर्न के लिए मानक बन गए हैं:
- API प्रमाणीकरण — क्लाइंट हर अनुरोध के साथ Authorization हेडर (Bearer token) में JWT शामिल करते हैं, जिससे सर्वर डेटाबेस लुकअप के बिना पहचान सत्यापित कर पाता है
- OAuth 2.0 एक्सेस टोकन — OAuth प्रदाता JWT को एक्सेस टोकन के रूप में जारी करते हैं, जो प्राधिकृत API एक्सेस के लिए scope और अनुमति संबंधी जानकारी लेकर चलते हैं
- माइक्रोसर्विस संचार — सेवाएँ केंद्रीकृत सत्र भंडारण के बिना सेवा सीमाओं के आर-पार उपयोगकर्ता पहचान और अनुमतियाँ पहुँचाने के लिए आपस में JWT भेजती हैं
- सिंगल साइन-ऑन (SSO) — एक केंद्रीय पहचान प्रदाता एक JWT जारी करता है जिसे कई एप्लिकेशन स्वीकार करते हैं, जिससे उपयोगकर्ता एक बार प्रमाणित होकर सभी जुड़ी सेवाओं तक पहुँच सकते हैं
सुरक्षा की सर्वोत्तम प्रथाएँ
JWT शक्तिशाली हैं, पर आम सुरक्षा ख़तरों से बचने के लिए सावधानीपूर्वक कार्यान्वयन की माँग करते हैं:
- छोटे समाप्ति समय सेट करें — एक्सेस टोकन के लिए 15 मिनट से 1 घंटे के exp दावे का उपयोग करें, और लंबे सत्रों के लिए रिफ़्रेश टोकन रोटेशन लागू करें
- पेलोड में संवेदनशील डेटा कभी संग्रहीत न करें — JWT पेलोड केवल Base64URL-एन्कोडेड होते हैं, एन्क्रिप्टेड नहीं। टोकन रखने वाला कोई भी व्यक्ति दावे पढ़ सकता है
- हमेशा सभी दावों को वैलिडेट करें — हर अनुरोध पर exp, iss, aud और किसी भी कस्टम दावे को सत्यापित करें। पूर्ण हस्ताक्षर सत्यापन के बिना पेलोड पर भरोसा न करें
- विशेष रूप से HTTPS का उपयोग करें — मैन-इन-द-मिडल हमलों के ज़रिए टोकन इंटरसेप्शन रोकने के लिए JWT को केवल एन्क्रिप्टेड कनेक्शन पर भेजें
- "none" एल्गोरिथम को अस्वीकार करें — हमेशा सत्यापित करें कि alg हेडर आपके अपेक्षित एल्गोरिथम से मेल खाता है। "none" एल्गोरिथम हस्ताक्षर सत्यापन को पूरी तरह दरकिनार कर देता है
अक्सर पूछे जाने वाले सवाल
JWT और सत्र कुकीज़ में क्या अंतर है?
सत्र कुकीज़ क्लाइंट पर एक सत्र ID संग्रहीत करती हैं जबकि वास्तविक सत्र डेटा सर्वर पर रहता है। JWT स्वयं-निहित होते हैं — सारा डेटा टोकन के भीतर ही होता है। यह JWT को स्टेटलेस और क्षैतिज रूप से स्केल करने में आसान बनाता है, लेकिन इन्हें रद्द करना कठिन होता है क्योंकि आप केवल एक सर्वर-साइड सत्र को हटा नहीं सकते। पारंपरिक वेब ऐप्स के लिए सत्र कुकीज़ सरल हैं; APIs और वितरित प्रणालियों के लिए JWT बेहतर हैं।
मैं किसी JWT के समाप्त होने से पहले उसे कैसे रद्द करूँ?
चूँकि JWT स्टेटलेस होते हैं, इसलिए कोई अंतर्निहित रद्दीकरण तंत्र नहीं होता। आम रणनीतियों में शामिल हैं: एक टोकन ब्लॉकलिस्ट बनाए रखना (हर अनुरोध पर उसके विरुद्ध जाँचना), रिफ़्रेश टोकन रोटेशन के साथ अल्पकालिक एक्सेस टोकन का उपयोग करना (रिफ़्रेश टोकन को रद्द करना भविष्य की पहुँच को अमान्य कर देता है), या उपयोगकर्ता रिकॉर्ड में एक टोकन संस्करण संग्रहीत करना और लॉगआउट पर उसे बढ़ा देना।
क्या JWT के लिए कोई आकार सीमा है?
JWT विनिर्देश में कोई औपचारिक आकार सीमा नहीं है, पर व्यावहारिक सीमाएँ मौजूद हैं। अधिकांश HTTP सर्वर हेडर आकार को 8 KB तक सीमित करते हैं। चूँकि JWT आम तौर पर Authorization हेडर में भेजे जाते हैं, इसलिए टोकन को 4 KB से नीचे रखने की सलाह दी जाती है। कई दावों वाले बड़े पेलोड इस सीमा को पार कर सकते हैं — JWT में केवल आवश्यक दावे संग्रहीत करने और अतिरिक्त डेटा किसी API से लाने पर विचार करें।