स्टेटलेस और स्टेटफुल आर्किटेक्चर

एप्लिकेशन की स्थिति को संदर्भित करता है, यानी, एक निश्चित समय में इसकी स्थिति या गुणवत्ता। स्टेटलेस प्रमाणीकरण में, कोई सत्र या उपयोगकर्ता संग्रहीत नहीं होता है, जिसमें केवल स्थिर सामग्री होती है। यह स्टेटफुल से भिन्न है, जो कि डायनामिक कंटेंट है।

एक स्टेटलेस प्रक्रिया एक पृथक संसाधन है, जो किसी अन्य सेवा या किसी अन्य सिस्टम के साथ इंटरैक्शन का संदर्भ नहीं देती है। यह पुराने लेनदेन से जानकारी लाए बिना केवल कोड के उस हिस्से में काम करता है, क्योंकि स्टेटलेस प्रमाणीकरण इस प्रकार के डेटा को संग्रहीत नहीं करता है; प्रत्येक ऑपरेशन स्क्रैच से किया जाता है।

स्टेटफुल प्रमाणीकरण जानकारी को एक से अधिक बार उपयोग करने की अनुमति देता है और इसे पिछले लेनदेन के संदर्भ के आधार पर निष्पादित किया जाता है। इसलिए, ऐसे अनुप्रयोगों में जहां प्रतिक्रिया या पहले से मौजूद डेटा की प्रतीक्षा करना आवश्यक होता है, चाहे वह किसी अन्य सिस्टम या डेटाबेस में मौजूद हो, स्टेटफुल का उपयोग किया जाता है।

स्टेटलेस प्रमाणीकरण

स्टेटलेस प्रमाणीकरण में एक रणनीति शामिल होती है, जिसमें क्रेडेंशियल प्रदान करने के बाद, उपयोगकर्ता को प्रतिक्रिया में एक एक्सेस टोकन प्राप्त होता है। इस टोकन में पहले से ही टोकन जारी करने वाली सेवा या डेटाबेस से लगातार परामर्श करने की आवश्यकता के बिना, इसे उत्पन्न करने वाले उपयोगकर्ता की पहचान करने के लिए आवश्यक सभी जानकारी शामिल है।

यह टोकन संग्रहीत क्लाइंट-साइड (ब्राउज़र) है, इसलिए सर्वर के पास केवल यह पुष्टि करके टोकन की वैधता की जांच करने की क्षमता है कि पेलोड और हस्ताक्षर मेल खाते हैं।

स्टेटलेस प्रमाणीकरण JWT

JSON वेब टोकन (JWT) RFC-7519 में स्थापित मानकों वाली कुंजी हैं, जिसमें घोषणाओं के रूप में एक इकाई शामिल है, जो स्वतंत्र हैं, कॉल करने की आवश्यकता के बिना टोकन को पुनः सत्यापित करने के लिए सर्वर।

क्या स्ट्रिंग्स को गुप्त कुंजी का उपयोग करके बेस64 मानक में एन्कोड किया गया है, जैसा कि उदाहरण में है:

फायदे और नुकसान

फायदे:

• कम सर्वर मेमोरी खपत।
• स्केलेबिलिटी के मामले में उत्कृष्ट।
• वितरित अनुप्रयोगों, जैसे एपीआई और माइक्रोसर्विसेज के लिए आदर्श।
• तीसरे पक्षों पर निर्भरता के बिना, एक अलग एप्लिकेशन में टोकन का निर्माण और वितरण।
• टोकन उपयोगकर्ता डेटा की आसान व्याख्या और सत्यापन।

नुकसान:

• पहुँच नियंत्रण में कठिनाई।
• टोकन को किसी भी समय आसानी से रद्द करना संभव नहीं है।
• यदि किसी के पास टोकन तक पहुंच है, तो यह दुर्भावनापूर्ण तृतीय पक्षों के प्रवेश की सुविधा प्रदान कर सकता है।
• टोकन समाप्त होने तक सत्र नहीं बदला जा सकता।
• JWT टोकन अधिक जटिल है और मोनोलिथ जैसे केंद्रीकृत अनुप्रयोगों में अनावश्यक हो सकता है।

स्टेटफुल प्रमाणीकरण

आमतौर पर विभिन्न अनुप्रयोगों में उपयोग किया जाता है, विशेष रूप से जिन्हें अधिक स्केलेबिलिटी की आवश्यकता नहीं होती है, स्टेटफुल सत्र एप्लिकेशन के बैक-एंड में बनाया जाता है, और सत्र संदर्भ संबंधित उपयोगकर्ता को वापस भेजा जाता है . हर बार जब उपयोगकर्ता अनुरोध करता है, तो एप्लिकेशन का एक हिस्सा टोकन उत्पन्न करता है। उस क्षण से, प्रत्येक नए अनुरोध के साथ, यह टोकन पहुंच को पुनः मान्य करने के लिए एप्लिकेशन पर फिर से भेजा जाएगा। इस मॉडल में, यदि उपयोगकर्ता डेटा में कोई बदलाव होता है, तो टोकन आसानी से रद्द किया जा सकता है।

ये अपारदर्शी एक्सेस टोकन हैं, यानी, मालिकाना प्रारूप में एक सरल स्ट्रिंग जिसमें उस टोकन से संबंधित कोई पहचानकर्ता या उपयोगकर्ता डेटा शामिल नहीं है। प्राप्तकर्ता को उस सर्वर को कॉल करने की आवश्यकता है जिसने टोकन को सत्यापित करने के लिए बनाया है।

उदाहरण टोकन: 8c90e55a-e867-45d5-9e42-8fcbd9c30a74

यह आईडी उस उपयोगकर्ता के पास डेटाबेस में संग्रहीत होनी चाहिए जिसके पास टोकन है।

फायदे और नुकसान

फायदे:

• केंद्रीकृत कार्यान्वयन तर्क।
• सरलीकृत पहुंच प्रबंधन और नियंत्रण।
• मोनोलिथ, एमवीसी अनुप्रयोगों और आंतरिक प्रक्रियाओं के लिए उत्कृष्ट।
• दुर्भावनापूर्ण तृतीय पक्षों के विरुद्ध अधिक सुरक्षित।

नुकसान:

• टोकन को मान्य करने के लिए जिम्मेदार एपीआई में ओवरलोड हो सकता है।
• स्केलेबिलिटी के मामले में विफलता।
• माइक्रोसर्विसेज के बीच प्रमाणीकरण वितरित करने में बड़ी कठिनाई।
• किसी वितरित एप्लिकेशन में, यदि प्रमाणीकरण सेवा विफल हो जाती है, तो अन्य सभी सेवाएँ अनुपलब्ध हो जाती हैं।
• अधिक कार्यान्वयन जटिलता।
• तृतीय-पक्ष सिस्टम के साथ एकीकरण में बड़ी कठिनाई।

प्रत्येक दृष्टिकोण का उपयोग कब करें?

JWT टोकन और स्टेटलेस प्रमाणीकरण का उपयोग कब करें

• जब एपीआई को ओवरलोड करने की चिंता किए बिना बेहतर प्रदर्शन की आवश्यकता होती है।
• जब सेवाओं के बीच कई संचार वितरित किए जाते हैं।
• जब यह पहचानना आवश्यक हो कि कौन सा उपयोगकर्ता विभिन्न सेवाओं में सिस्टम में कोई कार्रवाई कर रहा है।
• जब किसी उपयोगकर्ता के डेटा को जारी रखने का इरादा नहीं है, तो केवल उनका प्रारंभिक पंजीकरण।
• यदि सेवा तक बाहरी पहुंच उत्पन्न करना आवश्यक है।
• यदि सिस्टम पर न्यूनतम प्रभाव के साथ एक निश्चित कार्रवाई करने वाले व्यक्ति के डेटा में हेरफेर करना आवश्यक है।

अपारदर्शी टोकन और स्टेटफुल प्रमाणीकरण का उपयोग कब करें

• यदि किसी सिस्टम के उपयोगकर्ताओं का पूर्ण एक्सेस नियंत्रण आवश्यक है, मुख्य रूप से एक्सेस पदानुक्रम को परिभाषित करने के लिए।
• एक केंद्रीकृत एप्लिकेशन में, वितरित सेवाओं के बिना और बाहरी सेवाओं के साथ संचार के बिना।

अंतिम विचार:

• कुछ स्थानों पर, जैसे "एपीआई तनाव", स्पष्टता के लिए शब्द को "एपीआई ओवरहेड" से बदला जा सकता है।
• यदि लक्षित दर्शकों को अधिक संदर्भ की आवश्यकता है, तो "जेडब्ल्यूटी टोकन" अनुभाग में आरएफसी-7519 में उल्लिखित "घोषणाएं" क्या हैं, इसकी अधिक विस्तृत व्याख्या शामिल हो सकती है।
• स्टेटफुल ऑथेंटिकेशन पर अनुभाग में, वाक्यांश "एप्लिकेशन का एक भाग टोकन उत्पन्न करेगा" को यह समझाकर स्पष्ट किया जा सकता है कि एप्लिकेशन का कौन सा विशिष्ट भाग इसके लिए जिम्मेदार है।