3-पैर वाली ओएथ 2 क्यों है जब 2-पैर वाली अच्छी तरह से काम करता है?

Question

2-पैर वाले OAuth2 का उपयोग ब्राउज़र आधारित ऐप के लिए किया जाता है, जहां कोई क्लाइंट क्रेडेंशियल सार्वजनिक से छुपाया जा सकता है। 3-पैर वाले OAuth2 का उपयोग "वेब सर्वर ऐप्स" द्वारा किया जाता है जहां सर्वर के बीच एक तिहाई कॉल होती है। All well described here।

प्रश्न: 3-पैरों से परेशान क्यों है, जब 2-पैर ठीक लगते हैं?

यह प्रदाता और ग्राहक दोनों के लिए अधिक काम है। बड़े खिलाड़ी में से एक ने कदम क्यों नहीं उठाया और 3-पैर हटा दिया?

Answer 1

तीन पैर वाले "ब्राउज़र आधारित" के रूप में एक निश्चित प्रकार का ऐप नहीं दर्शाते हैं। तीन पैर का मतलब है कि एक आवेदन उपयोगकर्ता की सीधी ओर से कार्य करता है। पैर तीन स्थितियों में

1. एक आवेदन (उपभोक्ता),
2. एक उपयोगकर्ता (संसाधन स्वामी) और
3. एक API (सेवा प्रदाता) है।

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

1. एक आवेदन (उपभोक्ता),
2. एक API (सेवा प्रदाता)

अंतर बस है एक उपयोगकर्ता प्राधिकरण कदम की कोई जरूरत नहीं है कि 2-पैर वाले दृष्टिकोण में।

Answer 2

2-पैर वाले परिदृश्य मौजूद हैं। उदाहरण के लिए Google Apps domain-wide delegation of authority के बारे में प्रलेखन की जांच करें। निस्संदेह इन्हें केवल खातों के सुपर-मालिक द्वारा विश्वसनीय वातावरण में उपयोग किया जा सकता है - उदाहरण में मैंने ऊपर उल्लिखित किया है: एक Google Apps डोमेन व्यवस्थापक डोमेन के सभी उपयोगकर्ता खातों के सुपर-स्वामी होने के नाते वह प्रशासित है।

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