कार्यात्मक प्रमाणीकरण और प्राधिकरण प्रणालियों का डिजाइन

इस लेख में, हम प्रमाणीकरण और प्राधिकरण को सुरक्षित रूप से निष्पादित करने के लिए एक प्रणाली के बारे में बात करने जा रहे हैं। सबसे पहले, आइए समझते हैं कि प्रमाणीकरण और प्राधिकरण के बीच क्या अंतर है।

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

इस लेख में हम देखेंगे:

• प्रमाणीकरण और प्राधिकरण क्यों महत्वपूर्ण है
• प्रमाणीकरण कैसे काम करता है
• प्राधिकरण कैसे काम करता है
• प्रमाणीकरण प्रणाली डिजाइन
• निष्कर्ष

प्रमाणीकरण और प्राधिकरण क्यों महत्वपूर्ण है?

मान लीजिए कि हम मीटिंग में हैं और आप बातचीत का नेतृत्व कर रहे हैं। किसी चीज़ के अपडेट/स्थिति के बारे में सही व्यक्ति से पूछने के लिए, आपको उस व्यक्ति की पहचान (यानी प्रमाणीकरण ) करने की ज़रूरत है। किसी व्यक्ति के साथ कुछ संवेदनशील डेटा साझा करने के लिए भी, आपको उस व्यक्ति को सही तरीके से प्रमाणित करने की ज़रूरत है। और यहीं प्रमाणीकरण की ज़रूरत होती है।

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

प्रमाणीकरण कैसे काम करता है?

किसी व्यक्ति को प्रमाणित करने के लिए, हम प्रत्येक व्यक्ति को एक अद्वितीय वाक्यांश दे सकते हैं, और यह देखते हुए कि व्यक्ति वाक्यांश को सही ढंग से बताता है और उसका नाम बताता है। हम कह सकते हैं कि ठीक है, हमने व्यक्ति की पहचान कर ली है। यह सामान्य उपयोगकर्ता नाम और पासवर्ड दृष्टिकोण है। जब सही क्रेडेंशियल दिए जाते हैं, तो सिस्टम पहचान को वैध मानता है और पहुँच प्रदान करता है। इसे 1FA या सिंगल-फैक्टर ऑथेंटिकेशन (SFA) के रूप में जाना जाता है।

SFA को काफी असुरक्षित माना जाता है। क्यों? क्योंकि उपयोगकर्ता अपनी लॉगिन जानकारी को सुरक्षित रखने में बेहद खराब हैं। मल्टी-फैक्टर ऑथेंटिकेशन (MFA) एक अधिक सुरक्षित विकल्प है जिसके लिए उपयोगकर्ताओं को एक से अधिक तरीकों से अपनी पहचान साबित करनी होती है। ऐसे कुछ तरीके हैं:

• एकल-उपयोग पिन नंबर / ओटीपी
• सुरक्षित तृतीय पक्ष (जैसे Google/Microsoft प्रमाणक) द्वारा चलाए जाने वाले प्रमाणीकरण ऐप्स
• बॉयोमेट्रिक्स

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

उपयोगकर्ता को प्रमाणित रखने के 2 तरीके:

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

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

टोकन-आधारित प्रमाणीकरण के लिए, हम ज्यादातर JWTs (JSON वेब टोकन) का उपयोग करते हैं।

प्राधिकरण कैसे काम करता है?

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

• भूमिका-आधारित पहुँच नियंत्रण (RBAC) : उपयोगकर्ताओं को एक निश्चित समूह/भूमिका सौंपी जाती है जो निर्धारित अनुमतियों के साथ आती है। उदाहरण: व्यवस्थापक, सदस्य, स्वामी।
• नीति-आधारित पहुँच नियंत्रण (PBAC) : नीतियों और नियमों के आधार पर प्राधिकरण के दौरान पहुँच विशेषाधिकारों को गतिशील रूप से निर्धारित करता है। नीतियाँ उपयोगकर्ता की भूमिकाओं, नौकरी के कार्यों और संगठनात्मक आवश्यकताओं पर आधारित होती हैं।
• विशेषता-आधारित प्रवेश नियंत्रण (एबीएसी) : उपयोगकर्ताओं को शीर्षक, प्रमाणीकरण, प्रशिक्षण और/या स्थान जैसे पर्यावरणीय कारकों जैसी विशेषताओं के अनुसार प्रवेश की अनुमति दी जाती है।
• एक्सेस कंट्रोल लिस्ट (ACLs) : प्रत्येक उपयोगकर्ता या इकाई के पास अलग-अलग अनुमतियाँ होती हैं जिन्हें चालू या बंद किया जा सकता है, यह आपके फोन पर एक नया ऐप इंस्टॉल करने और यह तय करने के समान है कि कौन सी अनुमतियाँ दी जाएँ (स्थान सेवाएँ, संपर्क, आदि)

ACL का उपयोग अक्सर ABAC या RBAC की तुलना में विस्तृत स्तर पर किया जाता है - उदाहरण के लिए, व्यक्तिगत उपयोगकर्ताओं को किसी निश्चित फ़ाइल तक पहुँच प्रदान करने के लिए। ABAC और RBAC को आम तौर पर कंपनी-व्यापी नीतियों के रूप में स्थापित किया जाता है।

प्रमाणीकरण प्रणाली डिजाइन

आवश्यकताएं

आइये सबसे पहले सिस्टम की कार्यात्मक आवश्यकताओं को परिभाषित करें:

• पंजीकरण : उपयोगकर्ताओं को आवश्यक जानकारी प्रदान करके पंजीकरण करने की अनुमति दें।
• लॉगिन : उपयोगकर्ताओं को उनके क्रेडेंशियल के आधार पर प्रमाणित करें।
• सत्र प्रबंधन : सुरक्षा सुनिश्चित करने के लिए उपयोगकर्ता सत्रों का कुशलतापूर्वक प्रबंधन करें।
• पासवर्ड पुनर्प्राप्ति : उपयोगकर्ताओं को अपना पासवर्ड पुनर्प्राप्त करने के लिए एक सुरक्षित प्रक्रिया प्रदान करें।
• अभिगम नियंत्रण : विभिन्न उपयोगकर्ता प्रकारों के लिए भूमिकाएं और अनुमतियाँ परिभाषित करें।
• ऑडिट ट्रेल : ऑडिटिंग के लिए प्रमाणीकरण घटनाओं का विस्तृत लॉग बनाए रखें।
• प्रदर्शन : कम विलंबता और त्वरित प्रतिक्रिया समय सुनिश्चित करें।

कुछ गैर-कार्यात्मक आवश्यकताएं जिन पर हम इस लेख के दायरे में विचार नहीं करने जा रहे हैं, वे हैं:

• बहु-कारक प्रमाणीकरण (एमएफए) : एक मजबूत एमएफए प्रणाली लागू करना।
• सुरक्षा : एन्क्रिप्शन, सुरक्षित भंडारण और सुरक्षित संचार के माध्यम से डेटा सुरक्षा को प्राथमिकता दें।
• मापनीयता (स्केलेबिलिटी) : उपयोगकर्ताओं और लेनदेन की बढ़ती संख्या को संभालने के लिए सिस्टम को डिज़ाइन करें।
• विश्वसनीयता : सिस्टम डाउनटाइम को न्यूनतम करें और उच्च उपलब्धता सुनिश्चित करें।
• प्रयोज्यता : निर्बाध अनुभव के लिए एक सहज उपयोगकर्ता इंटरफ़ेस विकसित करें।

क्षमता अनुमान

यातायात अनुमान

सबसे पहले ट्रैफ़िक अनुमान से शुरुआत करते हैं। मान लें कि प्रति माह औसतन 100,000 ट्रैफ़िक है। हम प्रति माह 100k उपयोगकर्ता ट्रैफ़िक का अनुमान लगा रहे हैं। जिसका मतलब है कि प्रति सेकंड 0.04 अनुरोध। हमें 90% समय में प्रत्येक अनुरोध का 500ms के भीतर जवाब देना होगा, यानी हमें 500ms की p90 विलंबता की आवश्यकता है।

 assumed_traffic_per_month = 100000 #requests assumed_traffic_per_day = assumed_traffic_per_month / 30 ~= 3350 (assuming on higher end; 3333.33 to be precise) estimated_time_per_request = 500 #ms; P90 of 500ms traffic_per_second = (assumed_traffic_per_month) / (30*24*60*60) = 0.04

सेवा स्तर उद्देश्य (एसएलओ) : 500एमएस (अधिकतम स्वीकार्य विलंबता, सिस्टम पर लोड की परवाह किए बिना) हमारी गणना के आधार पर, एक अनुरोध को पूरा करने के लिए 1 इंस्टेंस की औसत क्षमता लगभग 35एमएस है, यह मानते हुए कि विशेष अनुरोध के लिए कोई भारी प्रसंस्करण नहीं हो रहा है।

आइए उपरोक्त मेट्रिक्स का उपयोग करके दो और व्युत्पन्न मेट्रिक्स उत्पन्न करें।

• क्षमता : प्रति इंस्टैंस स्वीकार्य बैकलॉग : अनुरोधों (लोड) की अधिकतम संख्या जो SLO से समझौता किए बिना, किसी इंस्टैंस द्वारा स्वीकार की जा सकती है।
• मांग : प्रति इंस्टेंस बैकलॉग : वर्तमान ट्रैफ़िक के आधार पर एक इकाई/इंस्टेंस में आने वाले अनुरोधों (लोड) की कुल संख्या।

इस प्रकार,

 SLO = 500ms approx_response_time_for_one_request = 35 #ms capacity = SLO/approx_response_time_for_one_request = 500 / 35 ~= 20 load_on_one_instance = 0.04 instances_available = 1 demand = traffic_per_second / instances_available = 0.04

मांग और उपलब्ध क्षमता के आधार पर, आइए आवश्यक इंस्टैंसों की कुल संख्या की गणना करें।

 total_units_required = demand / capacity = 0.04 / 20 = 0.002 ~= 1

इस प्रकार, हम आसानी से 1 इंस्टेंस के साथ प्रति माह 100k अनुरोधों को संभालने में सक्षम होंगे, जिसमें प्रति सेकंड 0.04 अनुरोध होंगे। जहां प्रत्येक इकाई SLO से समझौता किए बिना प्रति सेकंड 20 अनुरोधों को संभाल सकती है।

भंडारण अनुमान

हमें प्रमाणीकरण और प्राधिकरण पहुँच के लिए आदर्श रूप से प्रत्येक उपयोगकर्ता के लिए उपयोगकर्ता विवरण संग्रहीत करने की आवश्यकता होगी। मान लें, 5kb / उपयोगकर्ता

 monthly_new_users = 500 monthly_additional_storage = 500 * 5kb = 2500kb ~= 2GB

इसलिए हर महीने, यह मानते हुए कि हम 500 नए उपयोगकर्ताओं को शामिल करेंगे, हमें 2GB अधिक स्टोरेज की आवश्यकता होगी। अगर हम प्रमाणीकरण लॉग रखना चाहते हैं। प्रत्येक प्रमाणीकरण अनुरोध को संग्रहीत करने के लिए 2kb की आवश्यकता होगी।

 auth_request_size = 2kb #assumption monthly_storage = monthly_visitors * auth_request_size = 100,000 * 2KB ~= 200MB

इस प्रकार, यदि मासिक ट्रैफिक 100 हजार हो तो हमें हर महीने अतिरिक्त 200 एमबी की आवश्यकता होगी।

डेटाबेस डिजाइन

अब जबकि हमने क्षमता का आकलन कर लिया है, तो चलिए कार्यात्मक आवश्यकताओं का समर्थन करने के लिए आवश्यक डेटाबेस की स्कीमा बनाते हैं।

आइये जल्दी से तालिकाओं पर नज़र डालें। हम 6 तालिकाओं का उपयोग कर रहे हैं।

1. उपयोगकर्ता - सभी उपयोगकर्ता जानकारी संग्रहीत करने के लिए
2. क्रेडेंशियल - उपयोगकर्ता को अधिकृत करने के बाद पहुंच/ताज़ा क्रेडेंशियल को संग्रहीत करने के लिए।
3. पासवर्ड - उपयोगकर्ता के एन्क्रिप्टेड पासवर्ड को संग्रहीत करने के लिए।
4. पासवर्ड अनुरोध - किसी विशेष उपयोगकर्ता के लिए आने वाले पासवर्ड परिवर्तन अनुरोधों को संग्रहीत करने के लिए।
5. सत्र - यह संग्रहीत करने के लिए कि उपयोगकर्ता का सक्रिय सत्र कब था और उनकी अंतिम गतिविधि कब थी।
6. गतिविधि अनुमोदन - किसी विशेष उपयोगकर्ता द्वारा निष्पादित गतिविधि के लिए अनुमोदन अनुरोधों को संग्रहीत करने के लिए, जिसे व्यवस्थापक द्वारा सत्यापित किया जाएगा।

प्रमाणीकरण प्रणाली के लिए उच्च-स्तरीय डिज़ाइन

सिस्टम एंडपॉइंट

आवश्यकताओं की पूर्ति

अब, जब सारी चीजें तैयार हो गई हैं तो आइए देखें कि हम सभी आवश्यकताओं को कैसे पूरा कर सकते हैं।

पंजीकरण

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

लॉग इन करें

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

सत्र प्रबंधन

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

पासवर्ड की दोबारा प्राप्ति

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

अभिगम नियंत्रण

• आवश्यकता - जब कोई उपयोगकर्ता कोई निश्चित कार्य करता है, तो हमें यह सुनिश्चित करना होता है कि उपयोगकर्ता उस कार्य को करने के लिए प्रमाणित है और उसके बाद ही उस कार्य को करने की अनुमति दी जाती है।
• पूर्ण - हम सरलता के लिए 1-12 क्रियाओं की सूची बनाए रखेंगे। प्रत्येक उपयोगकर्ता के लिए हम उस उपयोगकर्ता के लिए प्रमाणित क्रियाएँ बनाए रखेंगे। तो अब मान लें कि उपयोगकर्ता #id 4 क्रिया करने का प्रयास करता है। हम जाँच करेंगे कि उपयोगकर्ता के पास क्रिया 4 करने की अनुमति है या नहीं। यदि हाँ, तो हम आगे बढ़ेंगे और अनुरोध पूरा करेंगे। अन्यथा हम दिखाते हैं कि अनुमतियों की कमी के कारण अनुरोध सफल नहीं हुआ है।

लेखापरीक्षा

• आवश्यकता - किसी सुरक्षा घटना के मामले में, हमारे पास देखने के लिए पर्याप्त लॉग होने चाहिए और यह जानने का उचित कारण होना चाहिए कि क्या हुआ होगा / या यह जानने का कोई सुराग होना चाहिए कि इसका संभावित कारण क्या हो सकता है।
• पूर्ण - ऐसे परिदृश्यों के लिए, हम सर्वर पर होने वाली प्रत्येक प्रमाणीकरण क्रिया के लिए लॉग रख सकते हैं। (ए)। प्रत्येक लॉगिन अनुरोध के लिए, हम एक लॉग रखेंगे कि प्रमाणीकरण कब हुआ, कहाँ से, आईपी और अन्य प्रासंगिक विवरण। (बी)। प्रत्येक पासवर्ड पुनर्प्राप्ति अनुरोध के लिए, हम एक लॉग रखेंगे कि यह कब शुरू किया गया था, कहाँ से, आईपी, क्या अनुरोध पूरा हुआ और अन्य प्रासंगिक विवरण। (सी)। इसके अतिरिक्त, हम हर बार लॉग रखेंगे जब कोई उपयोगकर्ता किसी कार्रवाई के लिए अधिकृत / अनधिकृत होता है और किसके द्वारा। इन लॉग में, कुल मिलाकर, यह संकेत देने में सक्षम होना चाहिए कि कुछ परिदृश्य को समझने की कोशिश करने पर क्या हुआ होगा।

प्रदर्शन

• आवश्यकता - क्षमता आकलन अनुभाग में चर्चा के अनुसार प्रदर्शन के लिए आवश्यकता 0.04 अनुरोध/सेकेंड और 100k अनुरोध प्रति माह है।
• पूर्ण - हमने क्षमता अनुमान अनुभाग में पर्याप्त सर्वरों के साथ आवश्यकता को पहले ही पूरा कर लिया है।

निष्कर्ष

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