आपके प्रश्न का उत्तर कोड स्तर, प्रोटोकॉल स्तर या वास्तुकला स्तर पर हो सकता है। मैं यहाँ अधिकतर प्रोटोकॉल स्तर के मुद्दों को संक्षेप में प्रस्तुत करने का प्रयास करूँगा क्योंकि यह आमतौर पर पेशेवरों और विपक्षों के विश्लेषण में महत्वपूर्ण है। ध्यान रखें कि OAuth2 रिसोर्स ओनर पासवर्ड क्रेडेंशियल्स की तुलना में बहुत अधिक है , जो कि विनिर्देश के अनुसार, "विरासत या माइग्रेशन कारणों" के लिए मौजूद है, "अन्य अनुदान प्रकारों की तुलना में उच्च जोखिम" माना जाता है और विनिर्देश स्पष्ट रूप से कहता है कि क्लाइंट और प्राधिकरण सर्वर "इस अनुदान प्रकार का उपयोग कम से कम करें और जब भी संभव हो अन्य अनुदान प्रकारों का उपयोग करें"।
ROPC को बेसिक ऑथेंटिकेशन पर इस्तेमाल करने के कई फायदे हैं, लेकिन इससे पहले कि हम इसमें आएँ, आइए OAuth2 और बेसिक ऑथेंटिकेशन के बीच बुनियादी प्रोटोकॉल अंतर को समझें। कृपया मुझे समझाएं क्योंकि मैं इन्हें समझाता हूं और बाद में ROPC में आऊंगा।
उपयोगकर्ता प्रमाणीकरण प्रवाह
OAuth2 विनिर्देश में चार भूमिकाएँ निर्धारित हैं। उदाहरण के साथ, वे हैं:
- संसाधन स्वामी: वह उपयोगकर्ता जिसके पास कुछ संसाधन तक पहुँच है, उदाहरण के लिए आपके मामले में, अलग-अलग उपयोगकर्ताओं के पास REST API तक अलग पहुँच स्तर हो सकता है;
- क्लाइंट: आमतौर पर उपयोगकर्ता द्वारा उपयोग किए जाने वाले एप्लिकेशन, और उपयोगकर्ता को सेवाएं प्रदान करने के लिए संसाधन तक पहुंच की आवश्यकता होती है;
- संसाधन सर्वर: आपके मामले में बाकी एपीआई; तथा
- प्राधिकरण सर्वर: वह सर्वर, जिसके लिए उपयोगकर्ता की साख प्रस्तुत की जाती है और जो उपयोगकर्ता को प्रमाणित करेगा।
जब कोई क्लाइंट एप्लिकेशन चलता है, तो उसे उपयोगकर्ता के आधार पर संसाधनों तक पहुंच प्रदान की जाती है। यदि किसी उपयोगकर्ता के पास व्यवस्थापक विशेषाधिकार हैं, तो REST API में उपयोगकर्ता के लिए उपलब्ध संसाधन और संचालन, व्यवस्थापक विशेषाधिकारों के बिना उपयोगकर्ता की तुलना में कहीं अधिक हो सकते हैं।
OAuth2 भी कई ग्राहकों के साथ और कई संसाधनों के लिए एकल प्राधिकरण सर्वर का उपयोग करने की संभावना देता है। एक उदाहरण के रूप में, एक संसाधन सर्वर फेसबुक के साथ उपयोगकर्ता के प्रमाणीकरण को स्वीकार कर सकता है (जो इस तरह के मामले में प्राधिकरण सर्वर के रूप में कार्य कर सकता है)। इसलिए जब उपयोगकर्ता एक एप्लिकेशन (यानी क्लाइंट) चलाता है, तो वह उपयोगकर्ता को फेसबुक पर भेजता है। फेसबुक में उपयोगकर्ता अपने क्रेडेंशियल टाइप करते हैं, और क्लाइंट को एक "टोकन" वापस मिल जाता है, जिसे वह संसाधन सर्वर को प्रस्तुत कर सकता है। संसाधन सर्वर टोकन को देखता है और यह सत्यापित करने के बाद स्वीकार करता है कि वास्तव में फेसबुक ने इसे जारी किया है और उपयोगकर्ता को संसाधन तक पहुंच की अनुमति देता है। इस मामले में, क्लाइंट कभी भी उपयोगकर्ता की क्रेडेंशियल्स (यानी उनके फेसबुक क्रेडेंशियल्स) नहीं देखता है।
लेकिन मान लें कि आप फेसबुक के बजाय अपने उपयोगकर्ता की पहचान (और एक प्राधिकरण सर्वर) का प्रबंधन कर रहे हैं, जो आपके ग्राहक को टोकन पहले से ही प्रदान करता है। अब, मान लें कि आपका एक साथी भी है और आप अपने एप्लिकेशन (यानी क्लाइंट) को अपने REST API तक पहुंचने देना चाहते हैं। बुनियादी प्रमाणीकरण (या यहां तक कि ROPC) के साथ, उपयोगकर्ता उस क्लाइंट को क्रेडेंशियल्स प्रदान करेगा जो इसे प्राधिकरण सर्वर पर भेज देगा। प्राधिकरण सर्वर तब एक टोकन प्रदान करेगा जिसका उपयोग क्लाइंट द्वारा संसाधनों तक पहुंचने के लिए किया जा सकता है। दुर्भाग्य से, इसका मतलब है कि उपयोगकर्ता की साख अब उस ग्राहक को भी दिखाई दे रही है। हालांकि, आप एक उपयोगकर्ता के पासवर्ड को जानने के लिए एक भागीदार का आवेदन (जो आपके संगठन के लिए बाहरी हो सकता है) नहीं चाहेंगे। यह एक सुरक्षा मुद्दा है। उस लक्ष्य को प्राप्त करने के लिए,
इस प्रकार, OAuth2 के साथ, एक आदर्श रूप से ऐसे मामलों में ROPC का उपयोग नहीं करेगा, बल्कि एक अलग तरह का उपयोग करेगा, जैसे कि प्राधिकरण कोड प्रवाह। यह किसी भी एप्लिकेशन को उपयोगकर्ता के क्रेडेंशियल्स को जानने से बचाता है जो केवल प्राधिकरण सर्वर को प्रस्तुत किए जाते हैं। इस प्रकार, उपयोगकर्ता की साख लीक नहीं होती है। मूल प्रमाणीकरण के साथ भी यही मुद्दे लागू होते हैं, लेकिन अगले भाग में, मैं बताऊंगा कि ROPC अभी भी कैसे बेहतर है क्योंकि उपयोगकर्ता की साख को अभी भी क्लाइंट द्वारा लगातार पहुंच के लिए ROPC में क्लाइंट द्वारा संग्रहीत करने की आवश्यकता नहीं है।
ध्यान दें कि जब उपयोगकर्ता प्राधिकरण सर्वर पर जाता है, तो प्राधिकरण सर्वर उपयोगकर्ता से यह पुष्टि करने के लिए भी कह सकता है कि वे क्लाइंट को अपनी ओर से संसाधनों तक पहुंचने की अनुमति देना चाहते हैं या नहीं। इसीलिए इसे प्राधिकरण सर्वर कहा जाता है क्योंकि संसाधनों तक पहुंचने के लिए क्लाइंट को अधिकृत करने की प्रक्रिया में प्रवेश किया जाता है। यदि उपयोगकर्ता क्लाइंट को अधिकृत नहीं करता है, तो उसे संसाधनों तक पहुंच नहीं मिलेगी। इसी तरह, यदि उपयोगकर्ता के पास संसाधनों तक पहुंच नहीं है, तो प्राधिकरण सर्वर अभी भी पहुंच से इनकार कर सकता है और टोकन जारी नहीं कर सकता है।
मूल प्रमाणीकरण में, यहां तक कि प्राधिकरण सर्वर और संसाधन सर्वर को एक इकाई में जोड़ा जाता है। इस प्रकार, संसाधन सर्वर उपयोगकर्ता को अधिकृत करना चाहता है, इसलिए क्लाइंट से क्रेडेंशियल्स पूछता है। क्लाइंट उन क्रेडेंशियल्स को प्रस्तुत करता है जो उपयोगकर्ता को प्रमाणित करने के लिए संसाधन सर्वर द्वारा उपयोग किए जाते हैं। इसका अर्थ है कि कई संसाधन सर्वरों को अनिवार्य रूप से उपयोगकर्ता से क्रेडेंशियल की आवश्यकता होगी।
टोकन जारी करना
ग्राहकों को प्राधिकरण सर्वर से टोकन मिलते हैं, उन्हें आसपास रखते हैं और संसाधनों का उपयोग करने के लिए उनका उपयोग करते हैं (नीचे खुद टोकन पर अधिक विवरण)। क्लाइंट कभी भी उपयोगकर्ता के पासवर्ड (ROPC के अलावा अन्य प्रवाह में) को नहीं जानते हैं और इसे स्टोर करने की आवश्यकता नहीं है। ROPC में, भले ही ग्राहक उपयोगकर्ता के पासवर्ड को जानते हों, फिर भी उन्हें इसे संग्रहीत करने की आवश्यकता नहीं है क्योंकि वे संसाधनों तक पहुंचने के लिए इन टोकन का उपयोग करते हैं। इसके विपरीत, बुनियादी प्रमाणीकरण में, यदि कोई ग्राहक नहीं चाहता है कि उपयोगकर्ता को हर सत्र में क्रेडेंशियल प्रदान करना है, तो ग्राहक को उपयोगकर्ता के पासवर्ड को संग्रहीत करना होगा ताकि वे इसे अगली बार के आसपास प्रस्तुत कर सकें। बुनियादी प्रमाणीकरण का उपयोग करने के लिए यह एक बड़ी कमी है जब तक कि ग्राहक केवल एक वेब अनुप्रयोग नहीं है, जिस स्थिति में, कुकीज़ इन चिंताओं में से कुछ को संबोधित कर सकती हैं। मूल अनुप्रयोगों के साथ, यह आमतौर पर एक विकल्प नहीं है।
OAuth2 का एक और पहलू है जो कि टोकन जारी करने में कैसे फंसाया जाता है और वे काम करते हैं। जब कोई उपयोगकर्ता प्राधिकरण सर्वर (ROPC में भी) को क्रेडेंशियल प्रस्तुत करता है, तो प्राधिकरण सर्वर टोकन के दो प्रकारों में से एक या अधिक दे सकता है: 1) एक्सेस टोकन, और 2) रीफ्रेश टोकन।
एक्सेस टोकन संसाधन सर्वर को भेजे जाते हैं जो इसे सत्यापित करने के बाद संसाधनों तक पहुंच प्रदान करेंगे, और आमतौर पर उनके पास एक छोटा जीवनकाल होता है, जैसे कि 1.hr। रिफ्रेश टोकन क्लाइंट द्वारा प्राधिकरण सर्वर को भेजे जाते हैं जब यह समाप्त हो जाता है, तो एक और एक्सेस टोकन प्राप्त करने के लिए, और आमतौर पर एक बड़ा जीवनकाल होता है (उदाहरण के लिए कुछ दिनों से महीनों या वर्षों तक)।
जब क्लाइंट संसाधन सर्वर तक पहुंच टोकन प्रदान करता है, तो यह टोकन को देखता है और सत्यापन के बाद, टोकन के अंदर दिखता है यह निर्धारित करने के लिए कि क्या एक्सेस की अनुमति है या नहीं। जब तक पहुंच टोकन मान्य है, ग्राहक इसका उपयोग कर सकते हैं। मान लें कि उपयोगकर्ता एप्लिकेशन को बंद कर देता है और इसे अगले दिन शुरू करता है, और एक्सेस टोकन की समय सीमा समाप्त हो जाती है। अब ग्राहक प्राधिकरण सर्वर पर कॉल करेगा और यह समाप्त नहीं होने वाला मानते हुए ताज़ा टोकन पेश करेगा। प्राधिकरण सर्वर, चूंकि यह पहले से ही टोकन जारी करता है, इसे सत्यापित करता है और यह निर्धारित कर सकता है कि उपयोगकर्ता को फिर से क्रेडेंशियल्स प्रदान करने की आवश्यकता नहीं है और इस तरह ग्राहक को एक और एक्सेस टोकन देता है। क्लाइंट के पास अब संसाधन सर्वर तक फिर से पहुंच है। यह आमतौर पर फेसबुक और ट्विटर के लिए क्लाइंट एप्लिकेशन एक बार क्रेडेंशियल्स के लिए पूछते हैं और फिर उपयोगकर्ता को फिर से क्रेडेंशियल्स प्रदान करने की आवश्यकता नहीं होती है। इन एप्लिकेशन को उपयोगकर्ताओं को क्रेडेंशियल जानने की कभी आवश्यकता नहीं होती है और फिर भी उपयोगकर्ता एप्लिकेशन शुरू करने पर हर बार संसाधनों तक पहुंच सकता है।
अब उपयोगकर्ता प्राधिकरण सर्वर में जा सकता है (जैसे कि उनके फेसबुक उपयोगकर्ता प्रोफाइल में), किसी भी क्लाइंट एप्लिकेशन को प्रभावित किए बिना पासवर्ड बदलें। वे सभी ठीक से काम करना जारी रखेंगे। यदि उपयोगकर्ता एक उपकरण खो देता है, जिस पर उनके पास पहले से ही ताज़ा टोकन के साथ एक एप्लिकेशन है, तो वे प्राधिकरण सर्वर (जैसे फेसबुक) को उन अनुप्रयोगों के "लॉग आउट" करने के लिए कह सकते हैं, जो प्राधिकरण सर्वर (यानी फेसबुक) किसी भी मौजूदा को सम्मानित नहीं करके पूरा करेगा। जब वे उन अनुप्रयोगों के माध्यम से संसाधनों तक पहुंचने की कोशिश करते हैं, तो उपयोगकर्ता को फिर से क्रेडेंशियल्स प्रदान करने के लिए टोकन को ताज़ा करें और मजबूर करें।
JWT केवल टोकन प्रारूप है जो आमतौर पर OAuth2 और OpenID कनेक्ट के साथ उपयोग किया जाता है। टोकन पर हस्ताक्षर करने और इसे मान्य करने के तरीकों को भी उन पुस्तकालयों के साथ मानकीकृत किया गया है जो हर संसाधन सर्वर के बजाय अभी तक किसी अन्य समाधान को लागू करने के लिए उपलब्ध हैं। इस प्रकार, लाभ कोड के पुन: प्रयोज्य में निहित है जिसे वीटो कर दिया गया है और इसका समर्थन जारी है।
सुरक्षा निहितार्थ
मूल प्रमाणीकरण तब कमजोर होगा जब उपरोक्त परिदृश्य में से कोई भी चित्र में हो। डेवलपर्स के लिए OAuth2 के लिए एक व्यापक खतरा मॉडल भी उपलब्ध है जो अपने कार्यान्वयन में आम कमजोरियों से बचने के लिए इसमें सुझावों का उपयोग कर सकते हैं। यदि आप खतरे के मॉडल से गुजरते हैं, तो आप देखेंगे कि कई कार्यान्वयन संबंधी कमजोरियां (जैसे कि खुले पुनर्निर्देशक और सीएसआरएफ) भी इसमें शामिल हैं। मैं इस प्रतिक्रिया में बुनियादी प्रमाणीकरण के खिलाफ उन लोगों की तुलना के माध्यम से नहीं गया था।
OAuth2 का अंतिम प्रमुख लाभ यह है कि प्रोटोकॉल मानकीकृत है और कई प्राधिकरण सर्वर, क्लाइंट और संसाधन सर्वर इसका सम्मान करते हैं। डेवलपर्स के लिए कई पुस्तकालय उपलब्ध हैं, जिन्हें रखरखाव में सुरक्षा के मुद्दों के रूप में बनाए रखा जाता है, पुस्तकालयों को इंटरऑपरेबिलिटी की अनुमति देते समय अपडेट किया जाता है।
निष्कर्ष
यदि आप एक नया अनुप्रयोग, IMO लिख रहे हैं, तो मूल मामला मूल प्रमाणीकरण और ROPC दोनों से बचना होगा क्योंकि उनमें निहित मुद्दे हैं। हालाँकि, प्रत्येक एप्लिकेशन की अलग-अलग ज़रूरतें, समय-सीमाएँ, डेवलपर प्रवीणता आदि होती हैं इसलिए निर्णय केस-बाय-केस होता है। लेकिन यहां तक कि अगर आपको मूल प्रमाणीकरण की तुलना में कोई और आवश्यकता नहीं थी, तो इसे चुनकर, आप अपने आप को एक वास्तुकला में बंद कर सकते हैं, जिसे विस्तारित करना आसान नहीं हो सकता है (जैसे यदि आपके पास भविष्य में कई सर्वर हैं, तो आप जरूरी नहीं चाहते हैं उपयोगकर्ता उनमें से प्रत्येक को क्रेडेंशियल प्रदान करते हैं, बल्कि केवल एक बार प्राधिकरण सर्वर को प्रदान करते हैं, जो टोकन, आदि को सौंप सकते हैं।
ध्यान दें कि मैंने आपकी टिप्पणी को संबोधित नहीं किया था कि तार पर क्रेडेंशियल्स कैसे भेजे जाते हैं क्योंकि उन्हें टीएलएस या इसी तरह के प्रोटोकॉल का उपयोग करके सुरक्षित किया जा सकता है, या कब्जे का प्रमाण आदि। जैसा कि किसी ने पहले ही सुझाव दिया है, आधार 64 एन्कोडिंग 0 सुरक्षा है, कृपया नहीं उस से बहक जाना। ऊपर बताए गए अंतर आमतौर पर वास्तुकला के स्तर पर हैं और इस तरह से मैंने ध्यान केंद्रित किया है क्योंकि वास्तुकला एक बार लागू होने के बाद सबसे कठिन है।
एज़्योर एक्टिव डायरेक्ट्री बी 2 सी बेसिक , एक सेवा, जिस पर मैं काम करता हूं और हाल ही में सार्वजनिक पूर्वावलोकन के लिए जारी किया गया था, तीसरे पक्ष के आवेदन को एएडी को सामाजिक आईडीपी (जैसे कि फेसबुक, गूगल, आदि) के साथ अंतर सर्वर के साथ प्राधिकरण सर्वर के रूप में उपयोग करने की अनुमति देता है। यह उपयोगकर्ताओं को सामाजिक आईडीपी का उपयोग करने के बजाय अपने स्वयं के खाते बनाने की अनुमति देता है और जिन्हें बाद में प्रमाणीकरण उद्देश्यों के लिए उपयोग किया जा सकता है। इस तरह की कुछ अन्य सेवाएं भी हैं (उदाहरण के लिए मुझे पता है कि दूसरा है)) जो डेवलपर्स द्वारा अपने अनुप्रयोगों और संसाधनों के लिए प्रमाणीकरण और उपयोगकर्ता प्रबंधन को पूरी तरह से आउटसोर्स करने के लिए उपयोग किया जा सकता है। समान प्रोटोकॉल विशेषताएँ जो मैंने ऊपर बताई हैं, डेवलपर्स द्वारा सर्वर (एएडी), एक संसाधन (उदाहरण के लिए उनके आरएएस एपीआई), क्लाइंट (जैसे उनके मोबाइल एप्लिकेशन), और उपयोगकर्ताओं को डिकूप करने के लिए उपयोग किया जाता है। मुझे उम्मीद है कि यह स्पष्टीकरण कुछ हद तक मदद करता है।