OAuth 2 में अंतर्निहित अनुदान प्राधिकरण प्रकार का उद्देश्य क्या है?




user-agent oauth-2.0 (6)

अंतर्निहित प्रवाह में यदि उपयोगकर्ता का ब्राउज़र दूषित हो गया है (बुरा विस्तार / वायरस) तो भ्रष्टाचार उपयोगकर्ता के संसाधनों तक पहुंच प्राप्त करता है और खराब चीजें कर सकता है।

लेख प्रवाह में भ्रष्टाचार नहीं कर सकता क्योंकि यह ग्राहक रहस्य को नहीं जानता है।

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

दोनों प्रवाह एक ही शुरू होते हैं (स्रोत: http://tools.ietf.org/html/draft-ietf-oauth-v2-22 ):

  1. ग्राहक संसाधन मालिक के उपयोगकर्ता-एजेंट को प्राधिकरण समापन बिंदु पर निर्देशित करके प्रवाह शुरू करता है।
  2. प्राधिकरण सर्वर संसाधन स्वामी (उपयोगकर्ता-एजेंट के माध्यम से) को प्रमाणित करता है और यह स्थापित करता है कि संसाधन स्वामी ग्राहक के पहुंच अनुरोध को अनुदान या अस्वीकार करता है या नहीं।
  3. मान लें कि संसाधन मालिक पहुंच प्रदान करता है, प्राधिकरण सर्वर पहले से प्रदान किए गए पुनर्निर्देशन यूआरआई (अनुरोध में या ग्राहक पंजीकरण के दौरान) का उपयोग कर उपयोगकर्ता-एजेंट को क्लाइंट को रीडायरेक्ट करता है।
    • पुनर्निर्देशन यूआरआई में एक प्राधिकरण कोड (प्राधिकरण कोड प्रवाह) शामिल है
    • पुनर्निर्देशन यूआरआई में यूआरआई टुकड़े (लागू प्रवाह) में पहुंच टोकन शामिल है

यहां पर प्रवाह बहता है। दोनों मामलों में इस बिंदु पर पुनर्निर्देशन यूआरआई क्लाइंट द्वारा होस्ट किए गए कुछ एंडपॉइंट के लिए है:

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

इसलिए मेरा प्रश्न: क्लाइंट प्रमाणीकरण चरण छोड़कर यहां क्या हासिल किया गया है?


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


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


यह नीचे उबलता है: यदि कोई उपयोगकर्ता ब्राउज़र-आधारित, या "सार्वजनिक", (जावास्क्रिप्ट) वेब ऐप चला रहा है जिसमें कोई सर्वर साइड घटक नहीं है, तो उपयोगकर्ता पूरी तरह से ऐप पर भरोसा करता है (और ब्राउज़र जहां यह चलता है, संभावित रूप से अन्य ब्राउज़र के साथ आधारित एप्स ...)।

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

सुरक्षा प्रभाव, हालांकि, महत्वपूर्ण हैं। http://tools.ietf.org/html/rfc6749#section-10.3 :

अंतर्निहित अनुदान प्रकार का उपयोग करते समय, एक्सेस टोकन यूआरआई टुकड़े में प्रसारित होता है, जो इसे अनधिकृत पार्टियों के सामने उजागर कर सकता है।

http://tools.ietf.org/html/rfc6749#section-10.16 :

एक संसाधन स्वामी किसी हमलावर के दुर्भावनापूर्ण क्लाइंट को पहुंच टोकन प्रदान करके स्वेच्छा से किसी संसाधन तक पहुंच का प्रतिनिधि हो सकता है। यह फ़िशिंग या कुछ अन्य pretext के कारण हो सकता है ...


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

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

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

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

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


https://tools.ietf.org/html/rfc6749#page-8

अंतर्निहित

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

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

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