OAuth 2 OAuth 1 से अलग कैसे है?




oauth-2.0 authorization (9)

बहुत सरल शब्दों में, क्या कोई OAuth 2 और OAuth 1 के बीच अंतर को समझा सकता है?

क्या OAuth 1 अप्रचलित है? OAuth 2 लागू करना चाहिए? मुझे ओथ 2 के कई कार्यान्वयन नहीं दिख रहे हैं; अधिकांश अभी भी OAuth 1 का उपयोग कर रहे हैं, जो मुझे संदेह करता है कि OAuth 2 उपयोग करने के लिए तैयार है। क्या यह?


एक बार टोकन उत्पन्न होने के बाद वास्तविक API कॉल के लिए OAuth 2.0 हस्ताक्षर आवश्यक नहीं हैं। इसमें केवल एक सुरक्षा टोकन है।

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

Here OAuth 1.0 और 2.0 के बीच के अंतर का वर्णन किया गया है और दोनों कैसे काम करते हैं।


OAuth 2.0 निम्न तरीकों से चीजों को सरल बनाने का वादा करता है:

  1. टोकन उत्पन्न करने के लिए आवश्यक सभी संचारों के लिए एसएसएल आवश्यक है। जटिलता में यह एक बड़ी कमी है क्योंकि उन जटिल हस्ताक्षरों की अब आवश्यकता नहीं है।
  2. टोकन उत्पन्न होने के बाद वास्तविक API कॉल के लिए हस्ताक्षर आवश्यक नहीं हैं - एसएसएल की भी दृढ़ता से अनुशंसा की जाती है।
  3. एक बार टोकन जेनरेट हो जाने के बाद, OAuth 1.0 की आवश्यकता होती है कि क्लाइंट प्रत्येक एपीआई कॉल पर दो सुरक्षा टोकन भेजता है, और हस्ताक्षर उत्पन्न करने के लिए दोनों का उपयोग करता है। OAuth 2.0 में केवल एक सुरक्षा टोकन है, और कोई हस्ताक्षर आवश्यक नहीं है।
  4. यह स्पष्ट रूप से निर्दिष्ट किया गया है कि प्रोटोकॉल के कौन से हिस्से "संसाधन स्वामी" द्वारा कार्यान्वित किए जाते हैं, जो वास्तविक सर्वर है जो एपीआई लागू करता है, और कौन से हिस्सों को एक अलग "प्राधिकरण सर्वर" द्वारा कार्यान्वित किया जा सकता है। यह एपीजी जैसे उत्पादों के लिए मौजूदा एपीआई को ओएथ 2.0 समर्थन प्रदान करने के लिए आसान बना देगा।

स्रोत: http://blog.apigee.com/detail/oauth_differences


एक सुरक्षा बिंदु से, मैं OAuth के लिए जाना होगा 1. OAuth 2.0 और नरक के लिए सड़क देखें

उस लिंक से उद्धरण दें: "यदि आप वर्तमान में 1.0 का सफलतापूर्वक उपयोग कर रहे हैं, तो 2.0 को अनदेखा करें। यह 1.0 से अधिक वास्तविक मूल्य प्रदान नहीं करता है (मुझे लगता है कि आपके क्लाइंट डेवलपर्स को अब तक 1.0 हस्ताक्षर पहले ही पता चला है)।

यदि आप इस जगह के लिए नए हैं, और अपने आप को एक सुरक्षा विशेषज्ञ मानते हैं, तो इसकी सुविधाओं की सावधानीपूर्वक जांच के बाद 2.0 का उपयोग करें। यदि आप एक विशेषज्ञ नहीं हैं, तो या तो 1.0 का उपयोग करें या एक प्रदाता के 2.0 कार्यान्वयन की प्रतिलिपि बनाएँ जिसे आप सही मानने के लिए भरोसा करते हैं (फेसबुक के एपीआई दस्तावेज शुरू करने के लिए एक अच्छी जगह हैं)। 2.0 बड़े पैमाने पर बेहतर है, लेकिन यदि आप एक बड़ा ऑपरेशन चला रहे हैं, तो संभवतः आपके पास साइट पर कुछ सुरक्षा विशेषज्ञ हैं जो इसे आपके लिए समझते हैं। "


ओथ 2 जाहिर तौर पर समय की बर्बादी है (उस व्यक्ति के मुंह से जो इसमें भारी शामिल था):

hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

वह कहता है (ब्रेवटी के लिए संपादित और जोर देने के लिए साहस):

... अब मैं OAuth 2.0 मानक से संबद्ध नहीं हो सकता। मैंने मुख्य लेखक और संपादक के रूप में अपनी भूमिका से इस्तीफा दे दिया, विनिर्देश से अपना नाम वापस ले लिया, और कार्य समूह छोड़ दिया। एक दस्तावेज़ से मेरा नाम हटाकर मैंने तीन साल तक दर्दनाक रूप से काम किया है और दो दर्जन से अधिक ड्राफ्ट आसान नहीं थे। एक प्रयास से आगे बढ़ने का फैसला मैंने पांच साल से अधिक समय तक पीड़ित किया था।

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

स्पष्ट होने के लिए, वेब सुरक्षा की गहरी समझ के साथ डेवलपर के हाथ में OAuth 2.0 संभवतः एक सुरक्षित कार्यान्वयन होगा। हालांकि, अधिकांश डेवलपर्स के हाथों - जैसा कि पिछले दो वर्षों से अनुभव रहा है - 2.0 असुरक्षित कार्यान्वयन का उत्पादन कर सकता है।


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

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


ईरान हैमर-लाहव ने अपने लेख में ओथ 2.0 का परिचय देने वाले अधिकांश मतभेदों को समझाने में उत्कृष्ट काम किया है। संक्षेप में, यहां महत्वपूर्ण अंतर हैं:

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

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

OAuth 2.0 हस्ताक्षर बहुत कम जटिल हैं। कोई और विशेष पार्सिंग, सॉर्टिंग, या एन्कोडिंग नहीं।

OAuth 2.0 एक्सेस टोकन "अल्पकालिक" हैं। आम तौर पर, ओथ 1.0 एक्सेस टोकन एक वर्ष या उससे अधिक के लिए संग्रहीत किया जा सकता है (ट्विटर ने उन्हें कभी समाप्त नहीं किया)। ओथ 2.0 में रीफ्रेश टोकन की धारणा है। जबकि मुझे पूरी तरह से यकीन नहीं है कि ये क्या हैं, मेरा अनुमान है कि आपका एक्सेस टोकन कम रहता है (यानी सत्र आधारित) जबकि आपका ताज़ा टोकन "जीवन समय" हो सकता है। उपयोगकर्ता को आपके एप्लिकेशन को दोबारा अधिकृत करने के बजाय आप एक नया एक्सेस टोकन प्राप्त करने के लिए रीफ्रेश टोकन का उपयोग करेंगे।

अंत में, ओथ 2.0 का मतलब ओएथ अनुरोधों को संभालने के लिए ज़िम्मेदार सर्वर के बीच भूमिकाओं का एक अलग पृथक्करण और सर्वर प्राधिकरण को संभालने वाला सर्वर है। इसके बारे में अधिक जानकारी उपर्युक्त लेख में विस्तृत है।


यदि आपको कुछ उन्नत स्पष्टीकरण की आवश्यकता है तो आपको दोनों विनिर्देशों को पढ़ने की आवश्यकता है:

https://oauth.net/core/1.0a/

https://oauth.net/2/

यदि आपको प्रवाह मतभेदों की स्पष्ट व्याख्या की आवश्यकता है, तो यह आपकी मदद कर सकता है:

ओथ 1.0 फ्लो

  1. क्लाइंट एप्लिकेशन प्रदाता के साथ पंजीकृत करता है, जैसे ट्विटर।
  2. ट्विटर उस एप्लिकेशन के लिए अद्वितीय "उपभोक्ता रहस्य" के साथ क्लाइंट प्रदान करता है।
  3. क्लाइंट ऐप अपने अद्वितीय "उपभोक्ता रहस्य" के साथ ट्विटर पर सभी OAuth अनुरोधों पर हस्ताक्षर करता है
  4. यदि OAuth अनुरोध में से कोई भी विकृत है, डेटा खो रहा है, या अनुचित तरीके से हस्ताक्षर किया गया है, तो अनुरोध अस्वीकार कर दिया जाएगा।

OAuth 2.0 प्रवाह

  1. क्लाइंट एप्लिकेशन प्रदाता के साथ पंजीकृत करता है, जैसे ट्विटर।
  2. ट्विटर उस एप्लिकेशन के लिए अद्वितीय "क्लाइंट गुप्त" ग्राहक प्रदान करता है।
  3. ग्राहक आवेदन में प्रत्येक अनुरोध के साथ "ग्राहक रहस्य" शामिल है
  4. यदि ओएथ अनुरोध में से कोई भी विकृत है, डेटा खो रहा है, या गलत रहस्य है, तो अनुरोध अस्वीकार कर दिया जाएगा।

स्रोत: https://codiscope.com/oauth-2-0-vs-oauth-1-0/


ध्यान दें Oauth 2 का उपयोग करने के खिलाफ गंभीर सुरक्षा तर्क हैं:

hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

और एक और तकनीकी एक

ध्यान दें कि ये ओथ 2 के मुख्य लेखक से आ रहे हैं।

प्रमुख बिंदु:

  • ओथ 2 एसएसएल के शीर्ष पर कोई सुरक्षा प्रदान नहीं करता है जबकि ओथ 1 परिवहन-स्वतंत्र है।

  • एक अर्थ में एसएसएल सुरक्षित नहीं है कि सर्वर कनेक्शन को सत्यापित नहीं करता है और सामान्य क्लाइंट पुस्तकालय विफलताओं को अनदेखा करना आसान बनाता है।

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

  • आप अपनी सारी सुरक्षा को वसा-उंगली कर सकते हैं, जो OAuth 1.0 में करना बहुत कठिन है:

    दूसरी आम संभावित समस्या टाइपो हैं। क्या आप एक चरित्र को छोड़कर एक उचित डिज़ाइन पर विचार करेंगे ('' '' 'https' में) टोकन की पूरी सुरक्षा को voids? या शायद गलत गंतव्य पर अनुरोध (वैध और सत्यापित एसएसएल / टीएलएस कनेक्शन पर) भेजना (' http://gacebook.com ' कहें?)। याद रखें, कमांड लाइन से ओथ बेयरर टोकन का उपयोग करने में सक्षम होने के कारण स्पष्ट रूप से एक उपयोग केस बीयर टोकन वकालत करने वाले वकील थे।


ओएथ 1.0 प्रोटोकॉल ( आरएफसी 5849 ) की सुरक्षा इस धारणा पर निर्भर करती है कि क्लाइंट एप्लिकेशन में एम्बेडेड एक गुप्त कुंजी को गोपनीय रखा जा सकता है। हालांकि, धारणा निष्पक्ष है।

ओएथ 2.0 ( आरएफसी 674 9) में, इस तरह के एक बेवकूफ ग्राहक आवेदन को एक गोपनीय ग्राहक कहा जाता है। दूसरी तरफ, एक ऐसे माहौल में एक ग्राहक आवेदन जहां गोपनीय कुंजी गोपनीय रखना मुश्किल है, उसे सार्वजनिक ग्राहक कहा जाता है। 2.1 देखें विवरण के लिए ग्राहक प्रकार

उस अर्थ में, OAuth 1.0 केवल गोपनीय ग्राहकों के लिए एक विनिर्देश है।

" hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell " का कहना है कि ओथ 2.0 कम सुरक्षित है, लेकिन ओएथ 1.0 क्लाइंट्स और ओएथ 2.0 गोपनीय ग्राहकों के बीच सुरक्षा स्तर में कोई व्यावहारिक अंतर नहीं है। OAuth 1.0 को हस्ताक्षर की गणना करने की आवश्यकता है, लेकिन यह सुरक्षा में वृद्धि नहीं करता है अगर यह पहले से ही आश्वस्त है कि ग्राहक पक्ष पर एक गुप्त कुंजी को गोपनीय रखा जा सकता है। कंप्यूटिंग हस्ताक्षर किसी भी व्यावहारिक सुरक्षा वृद्धि के बिना बस एक बोझिल गणना है। मेरा मतलब है, सादगी की तुलना में कि client_secret 2.0 क्लाइंट टीएलएस पर किसी सर्वर से कनेक्ट होता है और client_secret और client_secret प्रस्तुत करता है, यह नहीं कहा जा सकता है कि सुरक्षा के मामले में बोझिल गणना बेहतर है।

इसके अलावा, आरएफसी 5849 (ओएथ 1.0) ओपन रीडायरेक्टर के बारे में कुछ भी नहीं बताता है जबकि आरएफसी 674 9 (ओएथ 2.0) करता है। यही है, OAuth 1.0 का oauth_callback पैरामीटर सुरक्षा छेद बन सकता है।

इसलिए, मुझे नहीं लगता कि OAuth 1.0 OAuth 2.0 से अधिक सुरक्षित है।

[14 अप्रैल, 2016] मेरे बिंदु को स्पष्ट करने के लिए जोड़

OAuth 1.0 सुरक्षा हस्ताक्षर गणना पर निर्भर करता है। एक गुप्त कुंजी का उपयोग करके एक हस्ताक्षर की गणना की जाती है जहां एक गुप्त कुंजी एचएमएसी-एसएचए 1 ( आरएफसी 5849, 3.4.2 ) या आरएसए-एसएचए 1 ( आरएफसी 5849, 3.4.3 ) के लिए एक निजी कुंजी के लिए साझा कुंजी है। कोई भी जो गुप्त कुंजी जानता है हस्ताक्षर की गणना कर सकता है। इसलिए, यदि गुप्त कुंजी से समझौता किया गया है, तो हस्ताक्षर गणना की जटिलता अर्थहीन है हालांकि यह जटिल है।

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

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

OAuth 2.0 को OAuth 2.0 को दोष देने के लिए मुझे कोई अच्छा कारण नहीं मिल रहा है। तथ्य यह है कि (1) ओएथ 1.0 केवल गोपनीय ग्राहकों के लिए एक विनिर्देश है और (2) ओएथ 2.0 ने गोपनीय ग्राहकों के लिए प्रोटोकॉल को सरल बनाया है और सार्वजनिक ग्राहकों को भी समर्थित किया है। भले ही इसे अच्छी तरह से जाना जाता है या नहीं, स्मार्टफोन अनुप्रयोगों को सार्वजनिक क्लाइंट ( आरएफसी 674 9, 9 ) के रूप में वर्गीकृत किया जाता है, जो ओएथ 2.0 से लाभान्वित होते हैं।