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

Question

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

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

Comments

कृपया स्पष्ट करें; stackoverflow.com/questions/9565744/…

— लर्नर

यदि आप एक संक्षिप्त विवरण और OAuth का विस्तृत प्रवाह (आरेखों के साथ) देखना चाहते हैं, तो आप oauthbible.com

— क्रिस इस्माइल

आप यहाँ अपना उत्तर OAuth 2.0 - अवलोकन

— जॉन जो

Answer 1

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

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

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

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

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

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

Comments

क्या कोई स्पष्ट कर सकता है कि ओउथ 1 और 2 के बीच कॉलबैक यूरल्स कितने अलग हैं?

— ब्रायन आर्मस्ट्रांग

OAuth 2.0 OAuth का केवल तभी पालन करेगा जब इसे RFC के रूप में अनुमोदित किया जाएगा। वर्तमान में यह एक इंटरनेट ड्राफ्ट है, लेकिन यह एक इंटरनेट मानक बनने की योजना है (जहां तक ​​इन चीजों की योजना बनाई जा सकती है)। हालांकि, इसमें कई साल लगेंगे, क्योंकि फ्रेमवर्क के बड़े हिस्से अभी तक निर्दिष्ट नहीं हैं। हम शायद आने वाले वर्षों में इंटरनेट ड्राफ्ट के एक पूरे परिवार को देखेंगे, प्रत्येक OAuth 2.0 प्राधिकरण ढांचे के विभिन्न पहलुओं से संबंधित है। यह देखने के लिए कि यह क्यों सच है, tools.ietf.org/html/draft-ietf-oauth-v2 पर जाएं , और "इस विनिर्देश के दायरे से परे" खोजें;)

— Håvard Geithus

लेख के लेखक ने पिछले साल "OAuth 2.0 और द रोड टू हेल" नामक एक अनुवर्ती लेख लिखा था, जिसे यहां पढ़ा जा सकता है: web.archive.org/web/20120731155632/http://hueniverse.com/12/… दो में एक महत्वपूर्ण अंतर सुरक्षा है - 2.0 में क्रिप्टोग्राफी की कमी के कारण पूर्वाभास।

— kdazzle

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

— ताकाहिको कावासाकी

@kdazzle, वह लिंक अब यहां स्थानांतरित हो गया है: hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

— e_i_pi

Answer 2

मुझे यहाँ बहुत अच्छे उत्तर दिखाई दे रहे हैं लेकिन जो कुछ मुझे याद आ रहा था वह कुछ आरेखों का था और चूंकि मुझे स्प्रिंग फ्रेमवर्क के साथ काम करना था इसलिए मैं उनके स्पष्टीकरण पर आया ।

मुझे निम्नलिखित चित्र बहुत उपयोगी लगते हैं। वे OAuth2 और OAuth1 के साथ पार्टियों के बीच संचार के अंतर को स्पष्ट करते हैं।

---

OAuth 2

---

OAuth 1

Comments

इस प्रवाह में "client_secret" कहाँ उपयोग किया जाता है ??

— ऐशविंटैस्टिक

यदि आपका मतलब है कि प्रदाता को पुनर्निर्देशित करते समय उपयोगकर्ता प्रवेश करता है (जैसे कि फेसबुक, ट्विटर, गूगल, आदि) तो यह चरण 2 के लिए OAuth 2और चरण 4 के लिए होगा OAuth 1।

— nyxz

दोनों आरेखों में "उपयोगकर्ता अनुदान प्राधिकरण" नामक एक सेवा प्रदाता कदम क्यों है? यह पीछे या गलत लगता है। "उपयोगकर्ता" प्राधिकरण की मांग करने वाला नहीं है?

— फोर्बिन

@ फोरबिन क्योंकि यह कदम सर्विस प्रोवाइडर की तरफ होता है। आप उनके पृष्ठ पर हैं जहाँ आपको वह अनुदान दिखाई देता है, जिसके लिए आपको सेवा की आवश्यकता होती है और जिस सेवा को आप प्रमाणित करने का प्रयास कर रहे हैं, उसके साथ इस जानकारी को साझा करने के लिए आपको सहमत होना होगा। StackOverflow वास्तव में Google खाते का उपयोग करके लॉगिन करने का विकल्प है। यह उसी तरह काम करता है। SO, Google को आपका ईमेल देखने के लिए कहेगा और आपको उस पर सहमत होना होगा।

— nyxz

Answer 3

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

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

Comments

तो मूल रूप से OAuth2 HTTPS के साथ काम करता है और इसलिए OAuth1 की तुलना में सरल है जिसे HTTPS के बिना काम करने के लिए थोड़ा और अधिक जटिल होने की आवश्यकता है?

— माइक्रो

@MicroR यह एक व्यावहारिक परिभाषा है जो आपको वहां मिली है! ;)

— एराल्पबी

Answer 4

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

एक धूमिल लेख

और एक अधिक तकनीकी एक

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

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

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

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

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

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

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

Comments

"टाइपो" तर्क बहुत मान्य नहीं है - यह http से https तक अप्रत्यक्ष करने के लिए आम बात है

— ओलेग मिखेव

@OlegMikheev हाँ, लेकिन आपके हेडर को सूँघने के लिए MITM को अनुमति देने के लिए केवल एक http (no-s) अनुरोध है और आपका टोकन अब किसी और द्वारा उपयोग किया जा रहा है!

— पैट्रिक जेम्स मैकडॉग

अगर हेडर से आपका मतलब कुकीज़ से है तो वे सुरक्षित होने वाले हैं । इसके अलावा मैं यह नहीं देखता कि उपयोगकर्ता टाइपो (ब्राउज़र URL में) टोकन का खुलासा कैसे कर सकते हैं, वे हेडर में भी नहीं होना चाहिए

— ओलेग मिखेव

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

— skeller88

Answer 5

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

OAuth 2.0 ( RFC 6749 ) में, ऐसे भोले ग्राहक अनुप्रयोग को गोपनीय ग्राहक कहा जाता है । दूसरी ओर, एक क्लाइंट एप्लिकेशन ऐसे वातावरण में जहां गुप्त कुंजी गोपनीय रखना मुश्किल है, एक सार्वजनिक क्लाइंट कहा जाता है । 2.1 देखें । विवरण के लिए ग्राहक प्रकार ।

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

" OAuth 2.0 और द रोड टू हेल " का कहना है कि OAuth 2.0 कम सुरक्षित है, लेकिन OAuth 1.0 क्लाइंट और OAuth 2.0 गोपनीय क्लाइंट के बीच सुरक्षा स्तर में कोई व्यावहारिक अंतर नहीं है। OAuth 1.0 को हस्ताक्षर की गणना करने की आवश्यकता है, लेकिन यह सुरक्षा को नहीं बढ़ाता है यदि यह पहले से ही आश्वस्त है कि क्लाइंट साइड पर एक गुप्त कुंजी को गोपनीय रखा जा सकता है। कम्प्यूटिंग हस्ताक्षर बिना किसी व्यावहारिक सुरक्षा वृद्धि के केवल एक बोझिल गणना है। मेरा मतलब है कि सादगी की तुलना में एक OAuth 2.0 क्लाइंट टीएलएस पर एक सर्वर से जुड़ता है और बस प्रस्तुत करता है client_idऔर client_secret, यह नहीं कहा जा सकता है कि सुरक्षा के मामले में बोझिल गणना बेहतर है।

इसके अलावा, RFC 5849 (OAuth 1.0) खुले पुनर्निर्देशकों के बारे में कुछ भी उल्लेख नहीं करता है जबकि RFC 6749 (OAuth 2.0) करता है। यही है, oauth_callbackOAuth 1.0 का पैरामीटर एक सुरक्षा छेद बन सकता है।

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

---

^{[१४ अप्रैल २०१६] अपनी बात स्पष्ट करने के लिए जोड़ा गया}

OAuth 1.0 सुरक्षा हस्ताक्षर गणना पर निर्भर करती है। एक गुप्त कुंजी का उपयोग करके एक हस्ताक्षर की गणना की जाती है जहां एक गुप्त कुंजी HMAC-SHA1 ( RFC 5849, 3.4.2 ) या RSA-SHA1 ( RFC 5849, 3.4.3 ) के लिए एक निजी कुंजी के लिए एक साझा कुंजी है । जो कोई भी गुप्त कुंजी जानता है, वह हस्ताक्षर की गणना कर सकता है। इसलिए, यदि गुप्त कुंजी से छेड़छाड़ की जाती है, तो हस्ताक्षर गणना की जटिलता अर्थहीन है, लेकिन यह जटिल है।

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

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

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

Comments

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

— मार्क जी।

Answer 6

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

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

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

Answer 7

OAuth 2 स्पष्ट रूप से समय की बर्बादी है (किसी के मुंह से जो इसमें भारी रूप से शामिल था):

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

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

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

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

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

Comments

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

— क्लियोपेट्रा

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

— ताकाहिको कावासाकी

Answer 8

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

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

https://oauth.net/2/

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

OAuth 1.0 प्रवाह

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

OAuth 2.0 प्रवाह

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

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

Comments

क्या आप संकेतों को बोल्ड टेक्स्ट देख सकते हैं ? शायद कार्यात्मक में एक ही अवधारणा हो सकती है लेकिन, तकनीकी रूप से एक साधारण हेडर (oauth2) का उपयोग करना यह संपूर्ण अनुरोध पर हस्ताक्षर करने के लिए बहुत अलग है । ध्यान दें और मार्क उत्तर से पहले अपने पढ़ने की समझ में सुधार करें क्योंकि उपयोगी नहीं है

— JRichardsz

कृपया अपना स्वयं का उत्तर पढ़ें और इसका अहसास कराने का प्रयास करें। "गुप्त के साथ सभी अनुरोधों पर हस्ताक्षर करता है" और "सभी अनुरोधों के साथ गुप्त भेजें"। उनके दाहिने दिमाग में कोई भी यहाँ अंतर को समझने वाला नहीं है जब तक कि वह पहले से ही उनका इस्तेमाल नहीं करता है। मुझे अंतर पता है लेकिन ओपी नहीं है। यह उत्तर केवल ओपी को भ्रमित करेगा इसलिए नीचे की ओर। इस तरह के अस्पष्ट जवाब एक पतन के लायक हैं। कृपया अन्य उत्तर यहाँ पढ़ें जो कहीं अधिक विशिष्ट और सूचनात्मक हैं।

— saran3h

12 डेवलपर्स मिले। oauth1 और oauth2 में कई अंतर हैं। पिछले उत्तर उन्हें कवर करते हैं और जैसा कि मैंने कहा , आप अपना उत्तर बनाने के लिए इस oauth.net/core/1.0a या इस oauth.net/2 को पढ़ सकते हैं । मेरा लक्ष्य सबसे कुख्यात तकनीकी अंतर में से एक है जब एक डेवलपर को बाकी क्लाइंट विकसित करने की आवश्यकता होती है।

— JRichardsz

Answer 9

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

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

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

Answer 10

सुरक्षा के दृष्टिकोण से, मैं OAuth 1 के लिए जाऊंगा। OAuth 2.0 और नरक की सड़क देखें

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

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