सुरक्षा · 4 मिनट में पढ़ें ·
JWT के अंदर क्या होता है, और डिकोड करना वेरिफ़ाई करना क्यों नहीं
JSON Web Token बेतरतीब अक्षरों जैसा दिखता है, लेकिन इसे कोई भी पढ़ सकता है। इसके तीन हिस्सों में क्या होता है और कौन-सी गलती सुरक्षा में छेद कर देती है।
JWT (JSON Web Token) वह लंबी स्ट्रिंग है जो आपको कई वेब ऐप और API में लॉग-इन रखती है। यह एन्क्रिप्टेड दिखती है, लेकिन ज़्यादातर मामलों में होती नहीं: जिसके पास टोकन है, वह इसके अंदर की बातें पढ़ सकता है।
डॉट से अलग तीन हिस्से
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI0MiJ9.3q2-7w…
└ header ──────────┘ └ payload ───────┘ └ signatureheader बताता है कि टोकन किस तरह साइन किया गया है, जैसे HS256 या RS256। payload में claims होते हैं: यूज़र कौन है (sub), टोकन कब जारी हुआ (iat) और कब ख़त्म होगा (exp), साथ में ऐप जो कुछ जोड़े, जैसे रोल। दोनों base64url में एन्कोड किया गया साधारण JSON हैं, और यह एन्कोडिंग है, एन्क्रिप्शन नहीं।
असली चीज़ सिग्नेचर है
तीसरा हिस्सा पहले दो पर एक सिग्नेचर है, जो किसी सीक्रेट या प्राइवेट की से बनता है। सिर्फ़ सही की वाला सर्वर ही इसे जाँच सकता है। अगर कोई payload का एक भी अक्षर बदल दे, जैसे रोल को user से admin, तो सिग्नेचर मेल नहीं खाता।
डिकोड करना वेरिफ़ाई करना नहीं है
जो टोकन ठीक से डिकोड हो जाता है, वह बताता है कि वह क्या दावा करता है, यह नहीं कि दावे सच हैं। आपके बैकएंड को की से सिग्नेचर वेरिफ़ाई करना चाहिए, जिन टोकनों का exp बीत चुका हो उन्हें ठुकराना चाहिए और सिर्फ़ अपेक्षित एल्गोरिद्म स्वीकार करने चाहिए, "none" कभी नहीं। JWT लाइब्रेरी यह आपके लिए करती हैं; इसे छोड़ देना एक क्लासिक कमज़ोरी है।
काम के नियम
payload में पासवर्ड जैसे राज़ न रखें, क्योंकि इसे पढ़ा जा सकता है। एक्सपायरी का समय छोटा रखें। जब तक टोकन वैध है, उसे पासवर्ड की तरह संभालें: जो भी इसे कॉपी करे, वह एक्सपायर होने तक इसका इस्तेमाल कर सकता है।
ब्राउज़र में टोकन कहाँ रखें
localStorage में रखी हर चीज़ पेज की कोई भी स्क्रिप्ट पढ़ सकती है, इसलिए एक ही क्रॉस-साइट स्क्रिप्टिंग (XSS) बग टोकन लीक कर सकता है। HttpOnly कुकी को JavaScript पढ़ ही नहीं सकती, जिससे यह जोखिम ख़त्म हो जाता है; इसे Secure और SameSite फ़्लैग और क्रॉस-साइट रिक्वेस्ट फ़ोर्जरी (CSRF) से सुरक्षा के साथ इस्तेमाल करें। कोई भी विकल्प परफ़ेक्ट नहीं है, लेकिन सेशन टोकन के लिए HttpOnly कुकी ज़्यादा सुरक्षित डिफ़ॉल्ट है।
एक्सपायरी और रिफ़्रेश टोकन
JWT को अपने आप "लॉग आउट" नहीं किया जा सकता: वह अपने exp समय तक मान्य रहता है, जब तक सर्वर कोई रिवोकेशन लिस्ट न रखे। इसीलिए एक्सेस टोकन आमतौर पर कुछ मिनट चलते हैं, दिनों तक नहीं। ज़्यादा समय तक चलने वाला रिफ़्रेश टोकन, जिसे ज़्यादा सावधानी से रखा जाता है और सर्वर पर जाँचा जाता है, पुराने टोकन के एक्सपायर होने पर नया एक्सेस टोकन लेने के काम आता है।
आम claims एक नज़र में
iss जारीकर्ता टोकन किसने बनाया
sub विषय वह यूज़र या क्लाइंट जिसके बारे में है
aud ऑडियंस किस सर्विस को इसे स्वीकार करना चाहिए
exp एक्सपायरी Unix समय जिसके बाद यह अमान्य है
nbf इससे पहले नहीं Unix समय जिससे पहले यह अमान्य है
iat जारी हुआ Unix समय जब यह बनासमय वाले claims सेकंड में Unix टाइमस्टैम्प होते हैं। सर्वर को exp के साथ aud भी जाँचना चाहिए: एक सर्विस के लिए जारी हुआ मान्य टोकन दूसरी सर्विस को स्वीकार नहीं करना चाहिए।
टोकन पढ़ना
4Dev का JWT डिकोडर टोकन को उसके हिस्सों में बाँटता है और header और payload को पढ़ने लायक JSON में दिखाता है। यह सिर्फ़ डिकोड करता है और सिग्नेचर नहीं जाँचता। टोकन डिकोड करने के लिए 4Dev के सर्वर पर भेजा जाता है और न लॉग होता है न सेव, फिर भी प्रोडक्शन के चालू टोकन पेस्ट न करें, और जिस टोकन के लीक होने का शक हो उसे रद्द कर दें।