ओपनआईड कनेक्ट ओएथ 2.0 में क्या जोड़ता है (ओएथ 2.0 प्रमाणीकरण के लिए पर्याप्त क्यों नहीं है?)

Question

मैंने अब इस पर कई अलग-अलग लेखन-अप पढ़े हैं, लेकिन मैं अभी भी प्राथमिक मान के रूप में अस्पष्ट हूं कि ओपनआईडी कनेक्ट OAuth 2.0 के शीर्ष पर प्रदान करता है।

मेरी समझ:
ओएथ 2.0 प्रवाह के माध्यम से एक्सेस टोकन प्राप्त करते समय, क्लाइंट को पता चला है कि उपयोगकर्ता प्रमाणीकरण सर्वर द्वारा प्रमाणीकृत किया गया था। ऐसा लगता है कि ओपनआईडी कनेक्ट सिर्फ उपयोगकर्ता की जानकारी के साथ एक आईडी टोकन जोड़ रहा है - लेकिन वह जानकारी एक्सेस टोकन का हिस्सा हो सकती है या संरक्षित संसाधन (जैसे एक अलग उपयोगकर्ता विवरण संसाधन) के माध्यम से उपलब्ध हो सकती है। ऐसा लगता है कि ओपनआईडी कनेक्ट के निर्माण को उचित ठहराना प्रतीत नहीं होता है, इसलिए मुझे यकीन है कि मुझे कुछ याद आ रहा है ...

आपकी मदद के लिए धन्यवाद!

अधिक जानकारी जोड़ना जो एक टिप्पणी के लिए बहुत लंबा है। अब तक आपकी मदद के लिए बहुत बहुत धन्यवाद।

मुझे लगता है कि मैं करीब आ रहा हूं, आपकी प्रतिक्रियाओं के लिए धन्यवाद। तो मैंने इस आलेख की समीक्षा की: http://oauth.net/articles/authentication/। यह कहता है कि "ओथ यूजर के बारे में बिल्कुल कुछ नहीं कहता है"। हालांकि, आप एक्सेस टोकन जारी करने से पहले एंड-यूजर को प्रमाणीकृत करने के लिए उसी सेवा पर भरोसा कर रहे हैं। "सामान्य नुकसान अनुभाग" में, लेख चर्चा करता है कि आप प्रमाणीकरण के लिए एक्सेस टोकन का उपयोग क्यों नहीं कर सकते हैं। मैं मेरी समझ में उस के साथ निम्न समस्याओं है:

प्रमाणीकरण पहुँच टोकन के प्रमाण के रूप

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

प्रवेश।

पहुंच टोकन को इंजेक्शन नहीं स्पष्ट कैसे OpenID दर्शकों प्रतिबंध के इस

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

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

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

Answer 1

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

मतभेद में http://oauth.net/articles/authentication/

Answer 2

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

इसके अलावा, OpenID Connect ने अन्य प्रमाणीकरण से संबंधित तंत्र शुरू की है जैसे:

1. प्रमाणीकरण प्रसंग कक्षा संदर्भ
2. अधिकतम प्रमाणीकरण उम्र claims
3. sub दावे में अनुरोध पैरामीटर

सरकारों द्वारा उच्च स्तरीय सुरक्षा आवश्यकताओं को पूरा करने के लिए।

OpenID Connect Core 1.0 और अन्य संबंधित विनिर्देश पढ़ें। इसके अलावा, आपको "Authorization interaction" मिल सकता है जो एंड-यूजर प्रमाणीकरण को नियंत्रित करने के लिए ओपनआईडी कनेक्ट ने जो जोड़ा है, उसके सारांश के रूप में उपयोगी है।

Answer 3

OAuth 2.0 एक संसाधन के लिए एक तीसरी पार्टी सीमित पहुँच देने के बारे में है।

OAuth 2.0 प्राधिकरण ढांचे के साथ शुरू होता है The RFC एक तीसरे पक्ष के एक HTTP सेवा तक सीमित पहुंच प्राप्त करने के लिए आवेदन ...

OpenID Connect ने एक अंतिम-उपयोगकर्ता की पहचान स्थापित करने के बारे में है सक्षम बनाता है।

OpenID Connect ने 1.0 के साथ शुरू होता है OpenID Connect Core spec OAuth 2.0 प्रोटोकॉल के शीर्ष पर एक सरल पहचान परत है। यह अंतिम-उपयोगकर्ता एक प्राधिकरण सर्वर द्वारा किया जाता प्रमाणीकरण के आधार पर की पहचान सत्यापित करने के लिए ...

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

एक कंपनी का मानना ​​है कि Salesforce या गूगल की तरह किसी बेहतर सुसज्जित है की तुलना में वे उपयोगकर्ता खाते, पासवर्ड, डिजिटल प्रमाण पत्र, आदि के प्रबंधन के लिए, कंपनी की जगह OpenID Connect इस्तेमाल कर सकते हैं अनिवार्य रूप से एक जगह OpenID Connect प्रदाता है कि जिम्मेदारी "आउटसोर्स" करने के लिए कर रहे हैं । जब कंपनी को ओपनआईडी कनेक्ट प्रवाह के संदर्भ में एक आईडी टोकन प्राप्त होता है, तो यह जानता है कि प्रदाता ने अंतिम उपयोगकर्ता को प्रमाणित किया है और उपयोगकर्ता की पहचान स्थापित की है।

ओपनआईडी कनेक्ट ने ओएथ 2.0 प्रवाह को दोहराया है ताकि अंत उपयोगकर्ता की पहचान स्थापित की जा सके।