प्राधिकरण का भविष्य: क्यों OAuth 2.0 अभी शुरुआत है

प्राधिकरण एप्लिकेशन सुरक्षा का एक महत्वपूर्ण घटक है, जो केवल प्रमाणित और अधिकृत उपयोगकर्ताओं को संरक्षित संसाधनों तक पहुंच की अनुमति देता है। OAuth 2.0 प्राधिकरण के लिए उद्योग मानक प्रोटोकॉल बन गया है, जो प्रत्यायोजित पहुंच नियंत्रण के लिए एक रूपरेखा प्रदान करता है।

पहली बार 2012 में प्रकाशित, OAuth 2.0 एप्लिकेशन को एक्सेस टोकन जारी करने के माध्यम से संसाधन स्वामी की ओर से संसाधन सर्वर द्वारा होस्ट किए गए संसाधनों तक पहुंचने में सक्षम बनाता है। यह उपयोगकर्ताओं को अपनी साख उजागर किए बिना, तीसरे पक्ष के एप्लिकेशन को किसी अन्य सेवा पर अपने डेटा तक पहुंच प्रदान करने की अनुमति देता है।

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

इस लेख में, हम OAuth 2.0 कैसे काम करता है, सामान्य उपयोग के मामले, सर्वोत्तम अभ्यास और कमजोरियाँ का एक सिंहावलोकन प्रदान करेंगे। हम OAuth से परे अधिक उन्नत प्राधिकरण और प्रमाणीकरण प्रोटोकॉल पर भी गौर करेंगे जिनका उद्देश्य सुरक्षा बढ़ाना है - OpenID कनेक्ट, पारस्परिक TLS और WebAuthn। अंत तक, आपको OAuth 2.0 और इसे सुरक्षित रूप से उपयोग करने की ठोस समझ हो जाएगी। इसके अतिरिक्त, आप नए मानकों और तकनीकों के बारे में जानकारी प्राप्त करेंगे जो आधुनिक अनुप्रयोगों के लिए पहुंच नियंत्रण को और अधिक सुरक्षित करने के लिए OAuth से आगे जाते हैं।

OAuth 2.0 कैसे काम करता है

OAuth 2.0 एक्सेस डेलिगेशन के लिए एक खुला मानक है जो उपयोगकर्ता की ओर से सर्वर संसाधनों तक पहुंचने के लिए अनुप्रयोगों को सुरक्षित प्राधिकरण प्रदान करता है। यह उपयोगकर्ताओं को अपनी साख उजागर किए बिना अपने संसाधनों तक सीमित पहुंच प्रदान करने की अनुमति देता है।

OAuth 2.0 चार मुख्य प्राधिकरण प्रवाहों को परिभाषित करता है:

प्राधिकरण कोड प्रवाह

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

1. क्लाइंट एप्लिकेशन उपयोगकर्ता को लॉगिन करने और एक्सेस स्वीकृत करने के लिए प्राधिकरण सर्वर पर रीडायरेक्ट करता है।
2. प्राधिकरण सर्वर उपयोगकर्ता को प्रमाणित करता है और प्राधिकरण कोड के साथ वापस रीडायरेक्ट करता है।
3. क्लाइंट एक्सेस टोकन के लिए प्राधिकरण कोड का आदान-प्रदान करता है।
4. क्लाइंट संसाधनों तक पहुंचने के लिए एपीआई कॉल करने के लिए एक्सेस टोकन का उपयोग कर सकता है।

यह प्रवाह बढ़ी हुई सुरक्षा प्रदान करता है क्योंकि एक्सेस टोकन कभी भी उपयोगकर्ता के ब्राउज़र के माध्यम से सीधे प्रसारित नहीं होता है।

अंतर्निहित प्रवाहअंतर्निहित प्रवाह को उपयोगकर्ता-एजेंट-आधारित क्लाइंट जैसे एकल पृष्ठ वेब ऐप्स के लिए अनुकूलित किया गया है। एक्सेस टोकन बिना किसी प्राधिकरण कोड के सीधे लौटाया जाता है:

1. क्लाइंट एप्लिकेशन उपयोगकर्ता को लॉगिन करने और एक्सेस स्वीकृत करने के लिए प्राधिकरण सर्वर पर रीडायरेक्ट करता है।
2. प्राधिकरण सर्वर उपयोगकर्ता को प्रमाणित करता है और यूआरएल खंड में एक्सेस टोकन के साथ वापस रीडायरेक्ट करता है।
3. क्लाइंट संसाधनों तक पहुंचने के लिए एपीआई कॉल करने के लिए एक्सेस टोकन का उपयोग कर सकता है।

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

प्रवाह की तुलना

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

कुल मिलाकर, OAuth 2.0 क्लाइंट अनुप्रयोगों को मानकीकृत तरीके से सर्वर संसाधनों तक पहुंचने के लिए एक सुरक्षित प्रत्यायोजित प्राधिकरण ढांचा प्रदान करता है। हालाँकि, यदि ठीक से कार्यान्वित नहीं किया गया तो कमजोरियाँ अभी भी मौजूद हैं।

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

पेशेवर:

• उपयोगकर्ता क्रेडेंशियल साझा किए बिना प्रत्यायोजित प्राधिकरण
• विभिन्न प्रकार के क्लाइंट के लिए लचीला प्राधिकरण प्रवाह
• प्रमुख प्लेटफार्मों और प्रदाताओं द्वारा व्यापक रूप से अपनाया जाना

विपक्ष:

• जटिलता सामान्य कार्यान्वयन गलतियों की ओर ले जाती है
• सुरक्षा के लिए HTTPS और टोकन गोपनीयता पर निर्भर करता है
• यदि ठीक से संरक्षित नहीं किया गया तो एक्सेस टोकन लीक हो सकते हैं
• दायरे से परे सीमित अंतर्निहित उपयोगकर्ता संदर्भ

OAuth 2.0 सुरक्षित प्राधिकरण की प्रमुख समस्या को हल करता है, लेकिन इसमें कुछ कमज़ोरियाँ हैं जिन्हें अधिक उन्नत प्रोटोकॉल संबोधित करने का प्रयास करते हैं।

OAuth 2.0 उपयोग के मामले

OAuth 2.0 का उपयोग आमतौर पर इंटरनेट पर विभिन्न प्रकार के अनुप्रयोगों और सेवाओं में प्राधिकरण प्रवाह को सक्षम करने के लिए किया जाता है। कुछ सबसे प्रचलित उपयोग के मामलों और उदाहरणों में शामिल हैं:

• सोशल मीडिया लॉगिन - फेसबुक, ट्विटर, गूगल और गिटहब जैसी सेवाएं उपयोगकर्ताओं को अपने प्लेटफ़ॉर्म क्रेडेंशियल्स के साथ “लॉगिन” करने में सक्षम बनाने के लिए OAuth 2.0 का लाभ उठाती हैं। यह उपयोगकर्ताओं को नए खाते बनाने से बचने की अनुमति देता है, और इसके बजाय इन साइटों को उनके मौजूदा सामाजिक प्रोफाइल से जुड़ने के लिए अधिकृत करता है।

• एप्लिकेशन प्राधिकरण - मोबाइल और डेस्कटॉप एप्लिकेशन अक्सर REST API तक पहुंच को अधिकृत करने के लिए OAuth को एकीकृत करते हैं। उदाहरण के लिए, कोई ऐप क्लाउड स्टोरेज सेवा में उपयोगकर्ता की तस्वीरों, एड्रेस बुक सेवा में संपर्कों या एपीआई प्रदाता से अन्य डेटा तक पहुंच प्राप्त करने के लिए OAuth का उपयोग कर सकता है।- सुरक्षा और एकल साइन-ऑन - OAuth प्रत्येक एप्लिकेशन के लिए व्यक्तिगत रूप से क्रेडेंशियल प्रबंधित करने के बजाय, एकल पहचान प्रदाता के माध्यम से केंद्रीकृत प्रमाणीकरण की अनुमति देता है। यह एकल साइन-ऑन (एसएसओ) दृष्टिकोण सुरक्षा और सुविधा में सुधार के लिए उद्यम वातावरण में लोकप्रिय है।

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

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

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

OAuth 2.0 सर्वोत्तम प्रथाएँ

OAuth 2.0 के सुरक्षा लाभों का पूरी तरह से लाभ उठाने के लिए, पंजीकरण, कुंजियाँ, टोकन और ताज़ा टोकन के आसपास सर्वोत्तम प्रथाओं का पालन करना महत्वपूर्ण है।

पंजीकरण और कुंजी प्रबंधन

• प्राधिकरण और टोकन एंडपॉइंट के लिए HTTPS का उपयोग करें। यह बीच-बीच में होने वाले हमलों से बचाता है.

• पर्याप्त एन्ट्रापी के साथ क्रिप्टोग्राफ़िक रूप से मजबूत कुंजियाँ उत्पन्न करें। अनुशंसित कुंजी आकार आरएसए के लिए 2048 बिट्स और ईसी के लिए 256 बिट्स हैं।

• ऐप्स में कभी भी क्लाइंट सीक्रेट्स को हार्डकोड न करें या अविश्वसनीय पार्टियों के साथ सीक्रेट्स साझा न करें। रहस्यों को सर्वर साइड पर सुरक्षित रूप से संग्रहीत करें।

• प्राधिकरण कोड के लिए छोटी समाप्ति समय निर्धारित करें, लगभग 10 मिनट। इससे अवरोधन की संभावना कम हो जाती है।

• उजागर ग्राहक रहस्यों को तुरंत रद्द करें और नई कुंजी उत्पन्न करें।

टोकन उपयोग

• एक्सेस टोकन को अल्पकालिक रखें, लगभग 1 घंटा। रिफ्रेश टोकन की समाप्ति तिथि लगभग 2 सप्ताह लंबी हो सकती है।

• एक्सेस टोकन केवल HTTPS पर और केवल विश्वसनीय बैकएंड पर भेजें। यूआरएल, लॉग या फ्रंट-एंड कोड में कभी भी टोकन शामिल न करें।

• अपने एपीआई के लिए अपेक्षित दर्शकों से मेल खाने के लिए टोकन दर्शकों को हमेशा मान्य करें।

• जांचें कि जारीकर्ता आपके प्राधिकरण सर्वर डोमेन से मेल खाता है।

• ज्ञात विश्वसनीय कुंजियों के विरुद्ध टोकन हस्ताक्षर एल्गोरिथ्म और कुंजी को सत्यापित करें।

टोकन ताज़ा करें- केवल विश्वसनीय, प्रथम-पक्ष ऐप्स और उपकरणों के लिए ताज़ा टोकन जारी करें। तीसरे पक्ष के ग्राहकों के लिए ताज़ा टोकन प्रदान करने से बचें।

• रीफ्रेश टोकन को एक विशिष्ट क्लाइंट आईडी और उपयोगकर्ता पहचान संयोजन से बांधें।

• जब उपयोगकर्ता लॉग आउट करता है या अनुमतियाँ बदल जाती हैं तो ताज़ा टोकन रद्द करें। पुन:प्रमाणीकरण पर नये टोकन जारी करें।

• दीर्घकालिक प्राधिकरण के बराबर सुरक्षित ताज़ा टोकन। केवल HTTPS पर संचारित करें और एन्क्रिप्शन के माध्यम से पहुंच प्रतिबंधित करें।

इन सर्वोत्तम प्रथाओं का पालन करने से यह सुनिश्चित होगा कि OAuth 2.0 एपीआई प्राधिकरण के लिए मजबूत सुरक्षा प्रदान करता है।

OAuth 2.0 कमजोरियाँ

जबकि OAuth 2.0 पिछले प्रमाणीकरण प्रोटोकॉल की तुलना में एक सुधार है, फिर भी इसमें कमजोरियाँ हैं जिनका हमलावर फायदा उठा सकते हैं यदि इसे ठीक से लागू और सुरक्षित नहीं किया गया है। कुछ सामान्य OAuth हमलों में शामिल हैं:

• टोकन अपहरण - एक हमलावर एक एक्सेस टोकन चुरा लेता है और संसाधनों तक अनधिकृत पहुंच हासिल करने के लिए इसका उपयोग करता है। ऐसा तब हो सकता है जब टोकन ठीक से सुरक्षित न हों या असुरक्षित चैनलों पर प्रसारित न हों।

• प्राधिकरण कोड अवरोधन - एक्सेस टोकन के आदान-प्रदान के लिए उपयोग किए जाने वाले प्राधिकरण कोड को प्राधिकरण प्रक्रिया के दौरान एक हमलावर द्वारा इंटरसेप्ट किया जा सकता है, जिससे उन्हें एक वैध एक्सेस टोकन प्राप्त करने की अनुमति मिलती है।

• ग्राहक प्रतिरूपण - एक हमलावर प्राधिकरण सर्वर को एक्सेस टोकन जारी करने के लिए धोखा देने के लिए एक वैध ग्राहक होने का दिखावा करता है। कमजोर ग्राहक प्रमाणीकरण इसे संभव बनाता है।

• उपयोगकर्ता प्रतिरूपण - हमलावर उपयोगकर्ता की साख चुराता है या अनुमान लगाता है और उनका उपयोग उपयोगकर्ता के रूप में प्रमाणित करने और उनके डेटा तक पहुंच प्राप्त करने के लिए करता है।

• टूटे हुए OAuth प्रवाह - OAuth प्रवाह और सत्यापन का गलत कार्यान्वयन समापन बिंदुओं को शोषण के लिए खुला छोड़ सकता है। हमलावर खातों से समझौता करने के लिए रीडायरेक्ट_यूरी सत्यापन, राज्य पैरामीटर और कोड/टोकन जारी करने में खामियों का दुरुपयोग कर सकते हैं।

• क्रॉस साइट अनुरोध जालसाजी (सीएसआरएफ) - प्रवाह के लिए ब्राउज़र पुनर्निर्देशन पर OAuth की निर्भरता का फायदा उठाकर हमलावर प्रमाणित उपयोगकर्ताओं को उनकी ओर से अनजाने में अनुरोध करने के लिए बाध्य कर सकते हैं।

• ओपन रीडायरेक्टर्स - OAuth लॉगिन के बाद ओपन रीडायरेक्ट की अनुमति देने से हमलावर उपयोगकर्ताओं को फ़िशिंग साइटों पर रीडायरेक्ट कर सकते हैं और क्रेडेंशियल या टोकन चुरा सकते हैं।

OAuth के दुरुपयोग को रोकने के लिए, उचित कार्यान्वयन महत्वपूर्ण है:

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

OAuth 2.0 से आगे बढ़ना

OAuth 2.0 प्राधिकरण के लिए एक महत्वपूर्ण मानक रहा है और आज भी व्यापक रूप से उपयोग किया जाता है। हालाँकि, 10+ वर्ष पुराने मानक के रूप में, OAuth 2.0 आधुनिक सुरक्षा खतरों के सामने अपनी उम्र और सीमाएं दिखाना शुरू कर रहा है। यहां कुछ प्रमुख कारण दिए गए हैं कि क्यों OAuth 2.0 अब पर्याप्त नहीं हो सकता है:

• डेस्कटॉप और वेब के लिए डिज़ाइन किया गया, मोबाइल या नेटिव ऐप्स के लिए नहीं - OAuth 2.0 मोबाइल और नेटिव ऐप्स से पहले के युग में बनाया गया था। यह रीडायरेक्ट पर निर्भर करता है जो वेब ब्राउज़र संदर्भ के बाहर अच्छी तरह से काम नहीं करता है। इससे सुरक्षा संबंधी कमज़ोरियाँ पैदा हो सकती हैं.

• डिफ़ॉल्ट रूप से टोकन एन्क्रिप्ट नहीं करना - OAuth 2.0 टोकन अक्सर अनएन्क्रिप्टेड भेजे जाते हैं, जिससे उन्हें अवरोधन के लिए खुला छोड़ दिया जाता है। प्राधिकरण प्रवाह के लिए विनिर्देशन को https की आवश्यकता होती है, लेकिन एक्सेस टोकन अभी भी स्पष्ट रूप से प्रसारित किए जा सकते हैं।

• पहचान को सत्यापित करने के लिए कोई अंतर्निहित विधियां नहीं - OAuth 2.0 प्राधिकरण और एक्सेस प्रतिनिधिमंडल पर केंद्रित है। यह उपयोगकर्ता की पहचान सत्यापित नहीं करता है. यह प्रतिरूपण हमलों के लिए जगह छोड़ देता है।

• टोकन का पुन: उपयोग और एम्बेडिंग जोखिम - OAuth 2.0 एकल-उपयोग प्राधिकरण प्रदान करता है लेकिन टोकन को कई बार उपयोग करने से नहीं रोकता है। व्यापक पहुंच वाले टोकन भी ऐप्स में एम्बेड किए जा सकते हैं, जिससे एक्सपोज़र व्यापक हो जाता है।

• कब्जे के प्रमाण की कोई आवश्यकता नहीं - कोई क्रिप्टोग्राफ़िक प्रमाण नहीं है कि टोकन का उपयोग करने वाली पार्टी इच्छित अधिकृत उपयोगकर्ता है। यदि कोई टोकन इंटरसेप्ट किया जाता है तो यह अधिक जोखिम पैदा करता है।

• सीमित एन्क्रिप्शन मानक - OAuth 2.0 केवल SHA-1 जैसे पुराने एन्क्रिप्शन का समर्थन करता है। SHA-256 जैसे मजबूत आधुनिक एल्गोरिदम मूल विनिर्देश में अंतर्निहित नहीं हैं।

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

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

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

कुछ प्रमुख उपयोग के मामले जहां ओपनआईडी कनेक्ट सुरक्षा बढ़ाता है:

• सिंगल साइन-ऑन (एसएसओ) - ओपनआईडी कनेक्ट कई साइटों और एप्लिकेशन पर सरल एसएसओ की अनुमति देता है। प्रमाणीकरण को पहचान प्रदाता के प्राधिकरण सर्वर द्वारा नियंत्रित किया जाता है, इसलिए साइटों को प्रत्येक को अपने स्वयं के प्रमाणीकरण को संभालने की आवश्यकता नहीं होती है।

• बढ़ी हुई अखंडता - आईडी टोकन में हस्ताक्षरित दावे शामिल हैं जिन्हें पहचान प्रदाता द्वारा सुरक्षित रूप से सत्यापित किया गया है। यह मानक OAuth एक्सेस टोकन की तुलना में बेहतर अखंडता गारंटी प्रदान करता है।

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

• पहचान में उच्च विश्वास - स्कोप, जेडब्ल्यूटी दावों और एन्क्रिप्शन के उपयोग के मानक बुनियादी OAuth की तुलना में उच्च विश्वास प्रदान करते हैं कि उपयोगकर्ता वही है जिसका वे दावा करते हैं।

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

मजबूत प्रमाणीकरण के लिए पारस्परिक टीएलएस

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

यहां बताया गया है कि एमटीएलएस प्रमाणीकरण कैसे काम करता है:

• क्लाइंट सर्वर को अपना क्लाइंट प्रमाणपत्र भेजकर हैंडशेक शुरू करता है। यह प्रमाणपत्र एक विश्वसनीय प्रमाणपत्र प्राधिकारी (सीए) से जारी किया जाता है और ग्राहक की पहचान सत्यापित करता है।

• फिर सर्वर क्लाइंट को अपना स्वयं का सर्वर प्रमाणपत्र प्रदान करता है। यह प्रमाणपत्र सर्वर की पहचान प्रमाणित करने के लिए विश्वसनीय सीए के विरुद्ध मान्य है।- यदि दोनों पक्ष एक-दूसरे के प्रमाणपत्रों को सफलतापूर्वक सत्यापित करते हैं तो क्लाइंट और सर्वर एक एन्क्रिप्टेड टीएलएस सत्र पर बातचीत करते हैं। यह एक प्रमाणित द्वि-दिशात्मक संचार चैनल बनाता है।

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

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

ऐसे मामलों का उपयोग करें जहां एमटीएलएस सुरक्षा बढ़ाता है:

• माइक्रोसर्विसेज के बीच संचार सुरक्षित करना। एमटीएलएस अनधिकृत माइक्रोसर्विसेज को जाल में शामिल होने से रोकता है।

• आंतरिक रूप से कनेक्ट होने वाले कुबेरनेट्स पॉड्स के लिए प्रमाणीकरण। एमटीएलएस क्लस्टर के भीतर संचार करने वाली पॉड पहचान की पुष्टि करता है।

• IoT डिवाइस संचार सुरक्षित करना। एमटीएलएस क्लाइंट प्रमाणपत्रों की आवश्यकता के द्वारा मशीन-टू-मशीन संचार को बंद कर देता है।

• बैंकिंग और वित्तीय लेनदेन। एमटीएलएस वित्तीय प्रणालियों के बीच लेनदेन की अखंडता की गारंटी देता है।

कार्यान्वयन के लिए क्लाइंट और सर्वर दोनों का समर्थन mTLS आवश्यक है। एनजीआईएनएक्स जैसे लोड बैलेंसर एमटीएलएस कनेक्शन को समाप्त कर सकते हैं और फिर सादे टीएलएस मोड में ट्रैफ़िक रिले कर सकते हैं। क्लाइंट एसडीके बैकएंड सेवाओं से कनेक्ट होने वाले मोबाइल और वेब ऐप्स में एमटीएलएस प्रमाणीकरण को एकीकृत करना आसान बनाते हैं। उपयुक्त लाइब्रेरी और लोड संतुलन के साथ, कंपनियां बड़े पैमाने पर एमटीएलएस सुरक्षा तैनात कर सकती हैं।

वेबऑथ्न/FIDO2

WebAuthn (वेब प्रमाणीकरण) और FIDO2 उभरते वेब मानक हैं जो पारंपरिक पासवर्ड-आधारित प्रमाणीकरण का विकल्प प्रदान करते हैं।

WebAuthn वेबसाइटों को पासवर्ड के बजाय सार्वजनिक कुंजी क्रिप्टोग्राफी का उपयोग करके उपयोगकर्ताओं को पंजीकृत और प्रमाणित करने की अनुमति देता है। इसे सुरक्षा कुंजी या बायोमेट्रिक्स जैसे प्रमाणकों के माध्यम से सक्षम किया जाता है। मानक FIDO एलायंस और वर्ल्ड वाइड वेब कंसोर्टियम (W3C) द्वारा बनाया गया था।

FIDO2 तकनीकी विशिष्टताओं का एक सेट है जो सुरक्षा कुंजी, बायोमेट्रिक्स, या प्लेटफ़ॉर्म प्रमाणक जैसे सुरक्षित क्रेडेंशियल्स का उपयोग करके पासवर्ड रहित प्रमाणीकरण विधियों को सक्षम करता है। यह FIDO (फास्ट आइडेंटिटी ऑनलाइन) मानक का विस्तार है।

पारंपरिक पासवर्ड प्रमाणीकरण की तुलना में WebAuthn और FIDO2 के कुछ प्रमुख लाभ यहां दिए गए हैं:

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

• कम लागत - संगठन पासवर्ड रीसेट, हेल्प डेस्क कॉल और अन्य पासवर्ड से संबंधित मुद्दों से निपटने में कम खर्च करते हैं जो आईटी ओवरहेड जोड़ते हैं।

• गोपनीयता सुरक्षा - WebAuthn के साथ, मूल क्रेडेंशियल (बायोमेट्रिक टेम्पलेट या निजी कुंजी) उपयोगकर्ता के डिवाइस को कभी नहीं छोड़ते हैं। यह गोपनीयता की रक्षा करता है.

• प्लेटफ़ॉर्म/डिवाइस अज्ञेयवादी - WebAuthn डेस्कटॉप और मोबाइल डिवाइस पर काम करता है। और यह उपयोगकर्ताओं को किसी विशेष प्लेटफ़ॉर्म या डिवाइस में लॉक नहीं करता है।

कुल मिलाकर, WebAuthn और FIDO2 वेब पर प्रमाणीकरण सुरक्षा और प्रयोज्यता के लिए एक प्रमुख कदम का प्रतिनिधित्व करते हैं। जैसे-जैसे इन मानकों को व्यापक रूप से अपनाया जाएगा, हम कमजोर पासवर्ड-आधारित सिस्टम पर कम निर्भरता देखेंगे।

निष्कर्ष

OAuth 2.0 कई अनुप्रयोगों के लिए प्राधिकरण और प्रमाणीकरण के लिए मानक बन गया है, जो उपयोगकर्ताओं को क्रेडेंशियल्स को उजागर किए बिना अपने डेटा तक सीमित पहुंच प्रदान करने का एक तरीका प्रदान करता है। हालाँकि, एक पुराने प्रोटोकॉल के रूप में, OAuth 2.0 में सुरक्षा, पहुंच के दायरे और उपयोगकर्ता अनुभव से संबंधित कुछ सीमाएँ हैं।

नए प्रोटोकॉल का लक्ष्य विभिन्न तरीकों से OAuth 2.0 में सुधार करना है:

• ओपनआईडी कनेक्ट पहचान सेवाओं को जोड़ने के लिए OAuth 2.0 के शीर्ष पर निर्मित होता है, जो प्रमाणीकरण और प्राधिकरण के साथ पहचान का सत्यापन प्रदान करता है। यह OAuth 2.0 में कुछ सुरक्षा कमजोरियों को दूर करने में मदद करता है।

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

• WebAuthn/FIDO2 प्रमाणीकरण के लिए पासवर्ड के बजाय सार्वजनिक कुंजी क्रिप्टोग्राफी का उपयोग करता है, जो फ़िशिंग-प्रतिरोधी और छेड़छाड़-प्रतिरोधी लॉगिन प्रदान करता है। यह प्रोटोकॉल कई मामलों में लॉगिन के लिए OAuth को पूरी तरह से बदल सकता है।

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

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