डेवलपर टूल · JWT डिकोडर
JWT बनाम सत्र कुकीज़: कैसे स्टेटलेस टोकन ने वेब प्रमाणीकरण को बदल दिया
· पेजभूमि
जेडब्ल्यूटी प्रमाणीकरण वेब-सुरक्षा
जेडब्ल्यूटी द्वारा राज्यविहीनता का वादा करने से पहले सर्वर-साइड सत्रों ने वर्षों तक वेब प्रमाणीकरण पर शासन किया। यह पोस्ट उस बदलाव का पता लगाती है, इसके द्वारा शुरू की गई लागतों का मूल्यांकन करती है, और उन हाइब्रिड डिज़ाइनों का वर्णन करती है जो अधिकांश टीमों के साथ समाप्त होती हैं।
केवल सत्र कुकी का उपयोग क्यों न करें? - वह प्रश्न जो JWTs को अपनाने से पहले एक वास्तविक उत्तर का हकदार है
JWTs को अपनाने से पहले, पूछें कि सर्वर-साइड सत्र किस समस्या को हल करने में विफल रहता है। एक अपारदर्शी कुकी मान को एक बड़े स्व-निहित क्रेडेंशियल के साथ बदलने से निरसन, प्रकटीकरण और सत्यापन जिम्मेदारियों में परिवर्तन होता है। स्टेटलेसनेस कई संपत्तियों में से एक है, स्वचालित सुरक्षा या स्केलेबिलिटी अपग्रेड नहीं।
ToolAcre यह दिखा सकता है कि JWT प्रत्येक अनुरोध पर क्या करता है, लेकिन यह एप्लिकेशन थ्रूपुट की तुलना नहीं कर सकता है या आर्किटेक्चर निर्धारित नहीं कर सकता है। सबूत के रूप में डिकोड किए गए आकार और दावों का उपयोग करें, फिर उन्हें अपनी तैनाती, खतरे के मॉडल और मौजूदा सत्र बुनियादी ढांचे के खिलाफ तौलें।
सर्वर-साइड सत्र - सर्वर स्थिति की ओर इशारा करते हुए कुकी में एक अपारदर्शी ID, और वह मॉडल क्या अच्छा करता है
पारंपरिक सर्वर-साइड सत्र में, ब्राउज़र एक अपारदर्शी पहचानकर्ता रखता है और सर्वर इसे वर्तमान स्थिति में मैप करता है। वह लुकअप सत्र समाप्त करने, विशेषाधिकार बदलने और डेटा को क्लाइंट से दूर रखने के लिए एक प्राकृतिक स्थान प्रदान करता है। यह भंडारण और उपलब्धता जिम्मेदारियां भी बनाता है।
कुकी और सत्र पर्यायवाची नहीं हैं: कुकी एक परिवहन कंटेनर है, जबकि राज्य सर्वर पर रहता है। इसकी सुरक्षा विशेषताओं, मूल सीमाओं और अनुप्रयोग व्यवहार पर निर्भर करती है। एक यादृच्छिक दिखने वाली सत्र ID एक वाहक क्रेडेंशियल बनी रहती है और इसे लापरवाही से उजागर नहीं किया जाना चाहिए।
स्व-निहित सत्यापन साझा सत्र लुकअप को कम कर सकता है; यह स्वचालित रूप से सेवाओं के बीच विश्वास पैदा नहीं करता है
एक स्व-निहित टोकन एक संसाधन सर्वर को प्रत्येक अनुरोध पर साझा सत्र लुकअप के बिना संरक्षित बाइट्स और दावों को सत्यापित करने देता है। यह वितरित सिस्टम के अनुरूप हो सकता है, लेकिन क्रॉस-सर्विस ट्रस्ट प्रारूप द्वारा नहीं बनाया जाता है। सेवाओं को अभी भी विश्वसनीय जारीकर्ता कुंजी, स्वीकृत एल्गोरिदम, ऑडियंस नीति और संगत टोकन प्रोफाइल की आवश्यकता है।
ToolAcre उनमें से कोई भी भरोसेमंद रिश्ता प्रदान नहीं करता है। यह हेडर और पेलोड को डिकोड करता है और हस्ताक्षर को असत्यापित के रूप में रिपोर्ट करता है। एक सेवा जो अपने स्वयं के कॉन्फ़िगरेशन को छोड़ देती है वह केवल केंद्रीय सत्र निर्भरता को असुरक्षित स्वीकृति पथ से बदल देती है।
लागत - निरस्तीकरण, प्रत्येक अनुरोध में टोकन आकार, और कुकीज़ और वेब स्टोरेज के बीच भंडारण दुविधा
स्व-निहित प्रमाण-पत्र बड़े हो सकते हैं क्योंकि दावे और क्रिप्टोग्राफ़िक सामग्री बार-बार यात्रा करते हैं। जब तक बाहरी स्थिति या लघु स्वीकृति विंडो शुरू नहीं की जाती तब तक तत्काल निरस्तीकरण कठिन हो जाता है। कुकीज़, ब्राउज़र मेमोरी या वेब स्टोरेज में स्टोरेज एक्सपोज़र को ख़त्म करने के बजाय उसे बदल देता है।
पढ़ने योग्य पेलोड लॉग और मध्यस्थों में व्यक्तिगत या प्राधिकरण डेटा की नकल भी कर सकते हैं। दावे कम से कम करें और एन्कोडिंग को गोपनीयता मानने से बचें। सत्र पहचानकर्ता कम संरचना का खुलासा करते हैं, लेकिन सत्र सक्रिय रहने के दौरान चोरी अभी भी अधिकार प्रदान कर सकती है।
CSRF और XSS क्रेडेंशियल ट्रांसपोर्ट और स्टोरेज विकल्पों पर निर्भर करते हैं, न कि केवल JWT बनाम सत्र लेबल पर
CSRF जोखिम दृढ़ता से उन क्रेडेंशियल्स से संबंधित है जो ब्राउज़र स्वचालित रूप से संलग्न करते हैं, जबकि XSS पेज स्क्रिप्ट के लिए उपलब्ध डेटा और कार्यों को उजागर कर सकते हैं। कुकी में एक JWT कुकी परिवहन व्यवहार के अधीन होना बंद नहीं करता है, और वेब स्टोरेज में एक सत्र पहचानकर्ता एक वाहक रहस्य होना बंद नहीं करता है।
इसलिए केवल प्रारूप लेबल ही बचाव का चयन नहीं कर सकता। मॉडल जहां क्रेडेंशियल संग्रहीत किए जाते हैं, उन्हें कौन पढ़ सकता है, ब्राउज़र उन्हें कब भेजता है और राज्य-बदलते अनुरोधों को कैसे संरक्षित किया जाता है। सरल दावों से बचें कि एक आर्किटेक्चर "CSRF को हल करता है" या "XSS को हल करता है।"
कार्यान्वित उदाहरण - चरण दर चरण सत्रों और जेडब्ल्यूटी के साथ समान लॉगिन प्रवाह का वर्णन किया गया है
सत्र प्रवाह में, लॉगिन सर्वर स्थिति स्थापित करता है और एक अपारदर्शी पहचानकर्ता लौटाता है; बाद के अनुरोध इसे प्रस्तुत करते हैं और सर्वर वर्तमान नीति को लोड करता है। JWT प्रवाह में, लॉगिन एक संरक्षित टोकन जारी करता है; बाद के अनुरोध बड़ा मूल्य भेजते हैं और संसाधन सर्वर इसे प्रासंगिक दावों के साथ सत्यापित करता है।
लॉगआउट दोनों प्रवाहों में ब्राउज़र कॉपी को हटा सकता है, लेकिन तत्काल सर्वर अमान्यकरण स्वाभाविक रूप से सत्र स्थिति से जुड़ा हुआ है और इसे स्व-निहित टोकन के लिए स्पष्ट रूप से डिज़ाइन किया जाना चाहिए। ToolAcre JWT की घोषित समाप्ति और दर्शकों को प्रदर्शित कर सकता है, न कि लॉगआउट या निरस्तीकरण वास्तव में प्रभावी हुआ या नहीं।
हाइब्रिड डिज़ाइनों को अभी भी स्पष्ट ताज़ा, निरस्तीकरण और सत्यापनकर्ता नीति की आवश्यकता होती है
हाइब्रिड डिज़ाइन एक स्टेटफुल रिफ्रेश प्रक्रिया के साथ बाउंडेड एक्सेस टोकन का उपयोग कर सकते हैं, या केवल नियंत्रित सेवाओं के बीच जेडब्ल्यूटी के साथ अपारदर्शी बाहरी क्रेडेंशियल्स का उपयोग कर सकते हैं। ये दृष्टिकोण राज्य को ख़त्म करने के बजाय आगे बढ़ाते हैं। उन्हें अभी भी सुरक्षित ताज़ा भंडारण, कुंजी रोटेशन, निरस्तीकरण व्यवहार और नीति परीक्षणों की आवश्यकता है।
यह भंडार किसी सार्वभौमिक टोकन जीवनकाल या हाइब्रिड रेसिपी को परिभाषित नहीं करता है, इसलिए यह आलेख कुछ भी प्रदान नहीं करता है। मापे गए जोखिम और परिचालन बाधाओं से अवधि और तंत्र चुनें, फिर आर्किटेक्चरल लेबल पर भरोसा करने के बजाय चोरी-टोकन और लॉगआउट परिदृश्यों का परीक्षण करें।
टेकअवे: स्टेटलेसनेस एक व्यापार है, अपग्रेड नहीं - यदि आप JWTs चुनते हैं, तो ToolAcre JWT डिकोडर दिखाता है कि प्रत्येक टोकन प्रत्येक अनुरोध पर क्या करता है
राज्यविहीनता एक व्यापार है, उन्नयन नहीं। सर्वर सत्र लुकअप की कीमत पर वर्तमान स्थिति और निरस्तीकरण को केंद्रीकृत करते हैं। स्व-निहित टोकन बड़े क्रेडेंशियल्स, पठनीय दावों और अधिक स्पष्ट अमान्यकरण डिज़ाइन की कीमत पर सत्यापन वितरित करते हैं।
यदि JWT फिट बैठता है, तो सुरक्षित उदाहरणों का निरीक्षण करने और यह समझने के लिए कि प्रत्येक अनुरोध में क्या है, ToolAcre का उपयोग करें। इसके प्रदर्शन को प्रामाणिकता या प्राधिकरण का प्रमाण न मानें। आर्किटेक्चर तभी सफल होता है जब विश्वसनीय सत्यापनकर्ता, भंडारण विकल्प और निरस्तीकरण तंत्र खतरे के मॉडल से मेल खाते हैं।