OpenID और OAuth में क्या अंतर है?

Question

मैं वास्तव में OpenID और OAuth के बीच के अंतर को समझने की कोशिश कर रहा हूं? शायद वे दो पूरी तरह से अलग चीजें हैं?

Comments

यह समझना महत्वपूर्ण है कि OAuth एक प्रमाणीकरण ढांचा नहीं है मददगार हो सकता है - जब OpenID और OpenID Connect हैं .. blog.api-security.org/2013/02/...

— Prabath Siriwardena

OpenID कनेक्ट (2014) OpenID 2.0, OpenID विशेषता विनिमय 1.0 और OAuth 2.0 की विशेषताओं को एक प्रोटोकॉल में जोड़ती है। Security.stackexchange.com/questions/44611/…

— माइकल फ्रीजिम

यह प्रत्येक मानक के उद्देश्य की एक महान व्याख्या है: stackoverflow.com/a/33704657/557406

— चार्ल्स एल

Answer 1

OpenID प्रमाणीकरण के बारे में है (यानी यह साबित करता है कि आप कौन हैं), OAuth प्राधिकरण के बारे में है (यानी, मूल प्रमाणीकरण से निपटने के लिए कार्यक्षमता / डेटा / आदि तक पहुंच प्रदान करने के लिए)।

OAuth का उपयोग बाहरी भागीदार साइटों में किया जा सकता है ताकि किसी उपयोगकर्ता को फिर से प्रमाणित किए बिना संरक्षित डेटा तक पहुंच की अनुमति दी जा सके।

ब्लॉग पोस्ट " उपयोगकर्ता के दृष्टिकोण से ओयूआईडी बनाम ओउथ " में उपयोगकर्ता के दृष्टिकोण से दो की एक सरल तुलना है और " ऑउथ-ओपेनिड: यू आर बार्किंग अप रौंग ट्री अगर आपको लगता है कि वे वही बात कर रहे हैं " अधिक जानकारी है इसके बारे में।

Comments

बस इसमें शामिल सभी जानकारी मिली। आशा है कि यह OpenID और OAuth तुलना उपयोगी है।

— राकजा

यह वास्तव में किसी भी अधिक सच नहीं है। OAuth2 का उपयोग प्रमाणीकरण और प्राधिकरण के लिए किया जा सकता है । Google API प्रमाणीकरण और प्राधिकरण के लिए OAuth 2.0 का उपयोग करते हैं। आप अपने आवेदन के लिए उपयोगकर्ता प्रमाणीकरण को आउटसोर्स करने के तरीके के रूप में Google के प्रमाणीकरण प्रणाली का उपयोग करने का विकल्प भी चुन सकते हैं। ओपनआईडी पर मैं केवल इतना ही देख सकता हूं कि आपको इसे प्रति साइट के आधार पर लागू करना होगा। प्लस साइड पर, यह एंड्रॉइड के साथ ठीक से एकीकृत करता है।

— तम्मम्म

"ओपनआईडी कनेक्ट" और भी अधिक भ्रम को सुनिश्चित करता है क्योंकि यह वास्तव में एक मामूली विस्तार के साथ OAuth v2 है।

— विल्मंतस बरनौस्कास

सिंगल साइन ऑन (SSO)

— रिचर्ड

@Timmmm, "OAuth 2.0 एक प्रमाणीकरण प्रोटोकॉल नहीं है" जैसा कि वे यहाँ उल्लेख करते हैं । यहाँ एक और सहायक वीडियो है

— रेवेल्वेस

Answer 2

OAuth और OpenID की तुलना करने के तीन तरीके हैं:

1. उद्देश्य

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

उपयोगकर्ताओं को अपने पासवर्ड को तृतीय-पक्ष एप्लिकेशन के साथ साझा करने की आवश्यकता को दूर करने के लिए OAuth बनाया गया था । यह वास्तव में एक OpenID समस्या को हल करने के तरीके के रूप में शुरू हुआ था: यदि आप अपनी साइट पर OpenID का समर्थन करते हैं, तो आप API प्रदान करने के लिए HTTP बेसिक क्रेडेंशियल (उपयोगकर्ता नाम और पासवर्ड) का उपयोग नहीं कर सकते क्योंकि उपयोगकर्ताओं के पास आपकी साइट पर पासवर्ड नहीं है।

प्रमाणीकरण के लिए OpenID के अलग होने और प्राधिकरण के लिए OAuth के साथ समस्या यह है कि दोनों प्रोटोकॉल कई समान चीजों को पूरा कर सकते हैं। वे प्रत्येक सुविधाओं का एक अलग सेट प्रदान करते हैं जो अलग-अलग कार्यान्वयन द्वारा वांछित हैं लेकिन अनिवार्य रूप से, वे बहुत विनिमेय हैं। उनके मूल में, दोनों प्रोटोकॉल एक सत्यापन सत्यापन विधि है (ओपनआईडी केवल यह है कि मैं कौन हूँ 'तक सीमित है, जबकि OAuth एक' एक्सेस टोकन 'प्रदान करता है जिसे किसी एपीआई के माध्यम से किसी भी समर्थित दावे के लिए बदला जा सकता है)।

2. सुविधाएँ

दोनों प्रोटोकॉल साइट के लिए एक उपयोगकर्ता को कहीं और पुनर्निर्देशित करने का एक तरीका प्रदान करते हैं और एक सत्यापन के साथ वापस आते हैं। OpenID एक पहचान प्रदान करता है जबकि OAuth एक एक्सेस टोकन के रूप में अधिक सामान्य है जिसे तब "OAuth प्रदाता प्रश्न पूछने" के लिए उपयोग किया जा सकता है । हालांकि, वे प्रत्येक अलग सुविधाओं का समर्थन करते हैं:

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

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

3. तकनीकी कार्यान्वयन

दो प्रोटोकॉल उपयोगकर्ता प्राधिकरण प्राप्त करने के लिए पुनर्निर्देशन का उपयोग करने में एक सामान्य वास्तुकला साझा करते हैं। OAuth में उपयोगकर्ता अपने संरक्षित संसाधनों और OpenID में अपनी पहचान तक पहुँच को अधिकृत करता है। लेकिन यह सब वे साझा करते हैं।

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

Comments

धन्यवाद, मुझे इस संदर्भ में 'फेडरेटेड' और 'खोज' शब्दों से बहुत परेशानी हो रही थी और उत्तर ने इसे पूरी तरह से साफ कर दिया।

— आदित्य एमपी

एक अच्छा जवाब है, लेकिन मैं "सफेद-सूचियों के अपवाद" के साथ थोड़ा भ्रमित हूं। क्या आप सफेद सूची बहिष्करण करते हैं?

— रोना

OAuth प्रमाणीकरण के साथ समाप्त नहीं होता है, लेकिन समान तृतीय-पक्ष सेवा द्वारा प्रदान किए गए अतिरिक्त संसाधनों तक पहुंच प्राप्त करने के लिए एक पहुंच टोकन प्रदान करता है। बिल्कुल नहीं। से rfc6749 : प्राधिकरण सर्वर संसाधन सर्वर या एक अलग इकाई के रूप में एक ही सर्वर हो सकता है। एक एकल प्राधिकरण सर्वर कई संसाधन सर्वरों द्वारा स्वीकार किए गए टोकन तक पहुँच जारी कर सकता है।

— यूजीन यमश

Answer 3

OpenID (मुख्य रूप से) पहचान / प्रमाणीकरण के लिए है, ताकि पता stackoverflow.comचले कि मैं chris.boyle.name(या जहां भी) हूं और इसलिए मैं शायद वही व्यक्ति हूं जो chris.boyle.nameकल स्वामित्व रखता था और कुछ प्रतिष्ठा अंक अर्जित करता था।

OAuth को आपकी ओर से कार्रवाई करने के लिए प्राधिकरण के लिए डिज़ाइन किया गया है, ताकि stackoverflow.com (या जहां भी) आपके ट्विटर पासवर्ड को जाने बिना, आपकी ओर से स्वचालित रूप से ट्वीट करने की अनुमति, पूछ सकें।

Comments

लेकिन अगर आपने अपनी ओर से कार्रवाई करने के लिए ट्विटर को अधिकृत किया है, तो इसका मतलब है कि आप वह व्यक्ति हैं जो आप कहते हैं कि आप हैं - इसलिए यह दोनों को जोड़ती है?

— डेविड डी सी ई फ्रीटास

डेविड, आप सही हैं। Google इसे इस तरह से करता है।

— तम्मम्म

ऐसा लगता है कि ऑउथ के साथ, 3 पार्टी साइट को एक टोकन मिलेगा जिसे वह ओउथ प्रदाता की साइट पर कार्रवाई करने के लिए उपयोग कर सकता है (कहते हैं, अपनी ओर से ट्वीट करें), लेकिन उपयोगकर्ता की पहचान (उपयोगकर्ता नाम) प्राप्त करना अंतर्निहित नहीं है प्रोटोकॉल इसलिए प्रदाताओं को एक कस्टम संसाधन के रूप में जोड़ना होगा।

— केवल

क्या ऐसा नहीं है कि स्टैक ओवरफ्लो या अन्य वेबसाइटें जो सर्वरफॉल्ट की तरह स्टैकओवरफ्लो से संबंधित हैं, Google या फेसबुक और ओपनआईडी के लिए OAuth का उपयोग अपने डोमेन की अन्य वेबसाइट जैसे सर्वरफॉल्ट या आस्कुबंटु का उपयोग करके करते हैं। OAuth में हम पहचान प्रदाता (facebook) से सेवा प्रदाता (stackoverflow) तक जो जानकारी प्रवाहित कर रहे हैं उसे प्रतिबंधित कर सकते हैं। OpenID में हम व्यक्ति को कानूनी रूप से प्रतीक के रूप में प्रमाण पत्र देते हैं और पूरे डेटाबेस तक पहुँच प्रदान करते हैं। चूंकि stackoverflow या askubuntu एक ही डोमेन से संबंधित है, वे उपयोगकर्ता डेटाबेस के लिए पूर्ण पहुँच के साथ प्रमाण पत्र का आदान-प्रदान कर सकते हैं।

— रेवंत कुमार

@ jlo-gmail OAuth 2.0 में इस उद्देश्य के लिए रिफ्रेश टोकन शामिल हैं: आप कभी-कभी एक नया एक्सेस टोकन प्राप्त करने के लिए रिफ्रेश टोकन का उपयोग करते हैं। अधिक जानकारी: tools.ietf.org/html/rfc6749#section-1.5

— क्रिस बॉयल

Answer 4

बहुत से लोग अभी भी इसे देखने के लिए यहाँ आए हैं और इसे समझाने के लिए एक बहुत ही सरल चित्र है

सौजन्य विकिपीडिया

Comments

क्या OAuth उदाहरण में एक और कदम नहीं होना चाहिए जहां एंड्रॉइड ऐप उपयोगकर्ताओं की पहचान खोजने के लिए Google के साथ संवाद करने के लिए वैलेट कुंजी का उपयोग करता है?

— 18

मुझे लगता है कि लापता कदम अधिक सामान्य होना चाहिए। यानी यह पहचान के बारे में इतना नहीं है क्योंकि यह डेटा के बारे में है जो एपीआई के माध्यम से प्रदान किया जा सकता है। यानी आपके Google फ़ोटो या आपके G-Mail ईमेल जो एंड्रॉइड ऐप को किसी भी उद्देश्य के लिए उपयोग कर सकते हैं। बेशक, पहचान एपीआई के माध्यम से सुलभ हो सकती है।

— उपग्रह

OAuth के लिए, यह होना चाहिए "मुझे अपने घर के लिए वैलेट कुंजी दें ताकि मैं आपके घर तक पहुंच / संशोधित (अनुमति के अनुसार) कर सकूं"?

— hendryanw

Answer 5

OAuth

authorizationकेवल प्रत्यायोजित के लिए उपयोग किया जाता है - जिसका अर्थ है कि आप एक पासवर्ड देने के बिना, व्यक्तिगत डेटा का उपयोग करने के लिए एक तृतीय-पक्ष सेवा एक्सेस को अधिकृत कर रहे हैं। इसके अलावा OAuth "सत्र" आम तौर पर उपयोगकर्ता सत्रों की तुलना में लंबे समय तक रहते हैं। मतलब यह है कि OAuth को प्राधिकरण की अनुमति देने के लिए डिज़ाइन किया गया है

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

OpenID

authenticateएकल साइन-ऑन पहचान के लिए उपयोग किया जाता है । सभी ओपनआईडी को माना जाता है कि ओपनआईडी प्रदाता को यह साबित करने की अनुमति है कि आप कहते हैं कि आप हैं। हालाँकि कई साइटें प्राधिकरण प्रदान करने के लिए पहचान प्रमाणीकरण का उपयोग करती हैं (हालाँकि दोनों को अलग किया जा सकता है)

यानी वन हवाई अड्डे पर अपने पासपोर्ट को प्रमाणित करने (या साबित करने) के लिए दिखाता है कि जिस व्यक्ति का नाम वे उपयोग कर रहे हैं, वह टिकट पर है।

Comments

आप निश्चित रूप से एकल साइन-ऑन को प्रमाणित करने के लिए OAuth का उपयोग कर सकते हैं?

— टिम्मम्म

Answer 6

OAuth का उपयोग करें यदि आपके उपयोगकर्ता केवल फेसबुक, या ट्विटर के साथ लॉगिन करना चाहते हैं। OpenID का उपयोग करें यदि आपके उपयोगकर्ता नेकबर्ड हैं जो अपने स्वयं के OpenID प्रदाता चलाते हैं क्योंकि वे "किसी और को अपनी पहचान नहीं चाहते हैं"।

Comments

मुझे वास्तव में यह स्पष्टीकरण पसंद है। हालाँकि, मैं Google को अपने OTP कार्यान्वयन के साथ अपनी साख को संभालने देने के लिए अधिक खुश हूं जो लॉगिन के शीर्ष पर बैठता है।

— नेटली एडम्स

Answer 7

• OpenID एक खुला मानक और विकेन्द्रीकृत प्रमाणीकरण प्रोटोकॉल है जो OpenID Foundation द्वारा नियंत्रित किया जाता है।
• OAuth पहुँच प्रतिनिधि के लिए एक खुला मानक है ।
• OpenID कनेक्ट (OIDC) OpenID और OAuth की विशेषताओं को जोड़ती है अर्थात प्रमाणीकरण और प्राधिकरण दोनों करता है।

OpenID कुछ "OpenID प्रदाता" अर्थात पहचान प्रदाता (idP) द्वारा प्रबंधित एक अद्वितीय URI का रूप लेता है।

OAuth का उपयोग XACML के साथ संयोजन में किया जा सकता है जहां OAuth का उपयोग स्वामित्व सहमति और अभिगम प्रतिनिधिमंडल के लिए किया जाता है जबकि XACML का उपयोग प्राधिकरण नीतियों को परिभाषित करने के लिए किया जाता है।

OIDC सरल JSON वेब टोकन (JWT) का उपयोग करता है, जिसे आप OAuth 2.0 विनिर्देशों के अनुरूप प्रवाह का उपयोग करके प्राप्त कर सकते हैं । OAuth OIDC से सीधे संबंधित है क्योंकि OIDC एक प्रमाणीकरण परत है जो OAuth 2.0 के शीर्ष पर बनी है ।

उदाहरण के लिए , आप में प्रवेश करने का फैसला किया है, तो Auth0 अपने Google खाते तो आप उपयोग किए थे ओआईडीसी । एक बार जब आप सफलतापूर्वक गूगल के साथ प्रमाणित और अधिकृत करते Auth0 अपने जानकारी का उपयोग करने, Google के पास वापस भेज देंगे Auth0 उपयोगकर्ता के बारे में जानकारी और प्रमाणीकरण प्रदर्शन किया। यह जानकारी JSON वेब टोकन (JWT) में दी गई है। आपको एक अनुरोध टोकन प्राप्त होगा, और यदि अनुरोध किया गया है, तो एक आईडी टोकन। टोकन के प्रकार : स्रोत: ओपनआईडी कनेक्ट

सादृश्य :
एक संगठन पहचान के उद्देश्य के लिए आईडी कार्ड का उपयोग करता है और इसमें चिप्स होते हैं, यह प्राधिकरण के साथ कर्मचारी के बारे में विवरण संग्रहीत करता है अर्थात कैम्पस / गेट / ओडीसी पहुंच। आईडी कार्ड एक OIDC के रूप में कार्य करता है और चिप OAuth के रूप में कार्य करता है । अधिक उदाहरण और फार्म विकी

Answer 8

OpenID और OAuth प्रमाणीकरण और / या प्राधिकरण के लिए प्रत्येक HTTP- आधारित प्रोटोकॉल हैं। दोनों का उद्देश्य उपयोगकर्ताओं को ग्राहकों या तीसरे पक्ष को प्रमाणीकरण क्रेडेंशियल या कंबल की अनुमति दिए बिना कार्रवाई करने की अनुमति देना है। हालांकि वे समान हैं, और उन दोनों को एक साथ उपयोग करने के लिए प्रस्तावित मानक हैं, वे अलग-अलग प्रोटोकॉल हैं।

OpenID फ़ेडरेटेड प्रमाणीकरण के लिए अभिप्रेत है। एक ग्राहक किसी भी प्रदाता से एक पहचान का दावा स्वीकार करता है (हालांकि ग्राहक श्वेतसूची या ब्लैकलिस्ट प्रदाताओं के लिए स्वतंत्र हैं)।

OAuth प्रतिनिधि प्राधिकरण के लिए अभिप्रेत है। एक ग्राहक एक प्रदाता के साथ पंजीकरण करता है, जो प्राधिकरण टोकन प्रदान करता है जिसे वह उपयोगकर्ता की ओर से कार्रवाई करने के लिए स्वीकार करेगा।

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

Answer 9

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

OpenID कनेक्ट OpenID 1.0 / 2.0 की तरह एक प्रमाणीकरण प्रोटोकॉल है, लेकिन यह वास्तव में OAuth 2.0 के शीर्ष पर बनाया गया है, इसलिए आपको प्रमाणीकरण सुविधाओं के साथ प्राधिकरण सुविधाएँ मिलेंगी। इस (अपेक्षाकृत हाल ही में, लेकिन महत्वपूर्ण) लेख में दोनों के बीच का अंतर बहुत अच्छी तरह से समझाया गया है: http://oauth.net/articles/authentication/

Answer 10

OpenID, OAuth, OpenID कनेक्ट के बीच अंतर की व्याख्या:

OpenID प्रमाणीकरण के लिए एक प्रोटोकॉल है जबकि OAuth प्राधिकरण के लिए है। प्रमाणीकरण यह सुनिश्चित करने के बारे में है कि आप जिस आदमी से बात कर रहे हैं वह वास्तव में वह है जो वह होने का दावा करता है। प्राधिकरण यह तय करने के बारे में है कि उस आदमी को क्या करने की अनुमति दी जानी चाहिए।

OpenID में, प्रमाणीकरण प्रत्यायोजित किया जाता है: सर्वर A उपयोगकर्ता U को प्रमाणित करना चाहता है, लेकिन U का क्रेडेंशियल्स (जैसे U का नाम और पासवर्ड) किसी अन्य सर्वर, B को भेजा जाता है, कि A ट्रस्ट (कम से कम, उपयोगकर्ताओं को प्रमाणित करने के लिए ट्रस्ट)। वास्तव में, सर्वर बी सुनिश्चित करता है कि यू वास्तव में यू है, और फिर ए को बताता है: "ठीक है, यह वास्तविक यू है"।

OAuth में, प्राधिकरण को प्रत्यायोजित किया गया है: इकाई A को इकाई B से एक "एक्सेस राइट" प्राप्त होता है जिसे A सर्वर एस को दिखा सकता है कि उसे एक्सेस दी जाए; बी इस प्रकार ए, बहुत अधिक शक्ति देने के बिना ए के लिए अस्थायी, विशिष्ट पहुँच कुंजी वितरित कर सकते हैं। आप एक बड़े होटल में प्रमुख मास्टर के रूप में एक OAuth सर्वर की कल्पना कर सकते हैं; वह कर्मचारियों को चाबी देता है जो उन कमरों के दरवाजे खोलते हैं जिन्हें वे दर्ज करने वाले हैं, लेकिन प्रत्येक कुंजी सीमित है (यह सभी कमरों तक पहुंच नहीं देता है); इसके अलावा, चाबियाँ कुछ घंटों के बाद खुद को नष्ट कर देती हैं।

कुछ हद तक, प्राधिकरण को कुछ छद्म प्रमाणीकरण में दुर्व्यवहार किया जा सकता है, इस आधार पर कि यदि इकाई A, B से OAuth के माध्यम से एक एक्सेस कुंजी प्राप्त करता है, और इसे सर्वर S को दिखाता है, तो सर्वर S उस B को प्रमाणित कर सकता है जो एक्सेस देने से पहले A प्रमाणित कर सकता है चाभी। इसलिए कुछ लोग OAuth का उपयोग करते हैं जहां उन्हें OpenID का उपयोग करना चाहिए। यह स्कीमा ज्ञानवर्धक हो भी सकता है और नहीं भी; लेकिन मुझे लगता है कि यह छद्म प्रमाणीकरण किसी भी चीज़ से अधिक भ्रमित करने वाला है। OpenID कनेक्ट बस यही करता है: यह ऑथेंटिकेशन प्रोटोकॉल में OAuth का दुरुपयोग करता है। होटल की सादृश्य में: अगर मेरा किसी कथित कर्मचारी से सामना होता है और वह व्यक्ति मुझे दिखाता है कि उसके पास एक चाबी है जो मेरा कमरा खोलती है, तो मुझे लगता है कि यह एक सच्चा कर्मचारी है, इस आधार पर कि मुख्य स्वामी ने उसे चाबी नहीं दी होगी। अगर वह नहीं था तो मेरे कमरे को खोलता है।

(स्रोत)

OpenID 2.0 OpenID से कैसे अलग है?

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

(स्रोत)

OpenID कनेक्ट आपको एक एक्सेस टोकन और एक आईडी टोकन देगा। आईडी टोकन एक JWT है और इसमें प्रमाणित उपयोगकर्ता के बारे में जानकारी होती है। यह पहचान प्रदाता द्वारा हस्ताक्षरित है और पहचान प्रदाता तक पहुंच के बिना इसे पढ़ा और सत्यापित किया जा सकता है।

इसके अलावा, OpenID कनेक्ट काफी कुछ चीजों को मानकीकृत करता है जो oauth2 पसंद करने के लिए छोड़ देता है। उदाहरण के लिए स्कोप्स, एंडपॉइंट डिस्कवरी और क्लाइंट्स का डायनेमिक रजिस्ट्रेशन।

इससे कोड लिखना आसान हो जाता है जो उपयोगकर्ता को कई पहचान प्रदाताओं के बीच चयन करने देता है।

(स्रोत)

Google का OAuth 2.0

Google के OAuth 2.0 API का उपयोग प्रमाणीकरण और प्राधिकरण दोनों के लिए किया जा सकता है। यह दस्तावेज़ प्रमाणीकरण के लिए हमारे OAuth 2.0 कार्यान्वयन का वर्णन करता है, जो OpenID कनेक्ट विनिर्देश के अनुरूप है, और OpenID प्रमाणित है। Google API तक पहुँचने के लिए OAuth 2.0 का उपयोग करते हुए पाया गया दस्तावेज़ भी इस सेवा पर लागू होता है। यदि आप इस प्रोटोकॉल का अंतःक्रियात्मक रूप से अन्वेषण करना चाहते हैं, तो हम Google OAuth 2.0 प्लेग्राउंड की अनुशंसा करते हैं ।

(स्रोत)

Comments

अच्छी व्याख्या। उसके लिए +1।

— अताउर रहमान मुन्ना

Answer 11

एक उत्तर की तुलना में प्रश्न के लिए अधिक विस्तार, लेकिन यह ऊपर महान तकनीकी उत्तरों के लिए कुछ परिप्रेक्ष्य जोड़ सकता है। मैं कई क्षेत्रों में एक अनुभवी प्रोग्रामर हूं, लेकिन वेब के लिए प्रोग्रामिंग करने के लिए कुल noob। अब Zend फ्रेमवर्क का उपयोग करके एक वेब-आधारित एप्लिकेशन बनाने की कोशिश कर रहा है।

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

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

वास्तव में, जब मैं इस "उत्तर" को पोस्ट करने के लिए गया था, उस समय सदस्य नहीं होने के कारण, मैं अपनी पहचान करने के विकल्पों पर इस पृष्ठ के निचले भाग में लंबा और कठोर दिख रहा था। OpenID लॉगिन का उपयोग करने या एक प्राप्त करने का विकल्प अगर मेरे पास एक नहीं था, लेकिन ट्विटर या फेसबुक के बारे में कुछ भी नहीं है, तो यह सुझाव दिया गया कि OAuth नौकरी के लिए पर्याप्त नहीं था। लेकिन फिर मैंने एक और खिड़की खोली और स्टैकओवरफ्लो के लिए सामान्य साइनअप प्रक्रिया की तलाश की - और लो और निहारना फेसबुक और ट्विटर सहित 3-पार्टी प्रमाणीकरण विकल्पों में से एक है। अंत में मैंने अपनी google id (जो कि एक OpenID) का उपयोग करने का निर्णय लिया, ठीक उसी कारण से कि मैं अपने मित्रों की सूची में स्टैक्वरफ्लो एक्सेस का अनुदान नहीं देना चाहता था और कुछ और जो facebook अपने उपयोगकर्ताओं के बारे में साझा करना पसंद करता है - लेकिन कम से कम '

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

खेद है कि यह इतना लंबा था, और एक उत्तर की तुलना में अधिक प्रश्न था - लेकिन कार्ल की टिप्पणी ने OAuth और OpenID पर थ्रेड्स की मात्रा के बीच पोस्ट करने के लिए सबसे उपयुक्त जगह की तरह प्रतीत होता है। अगर इसके लिए एक बेहतर जगह है जो मुझे नहीं मिली, तो मैं पहले से माफी मांगता हूं, मैंने कोशिश की।

Answer 12

OpenID साबित करता है कि आप कौन हैं।

OAuth अधिकृत पार्टी द्वारा प्रदान की गई सुविधाओं तक पहुँच प्रदान करता है।

Comments

OAuth: कुछ सुविधा तक पहुंच प्रदान करने से पहले, प्रमाणीकरण किया जाना चाहिए, सही? तो OAuth = क्या OpenId + कुछ सुविधाओं तक पहुँच प्रदान करता है?

— हसन तारेक

Answer 13

मैं वर्तमान में OAuth 2.0 और OpenID कनेक्ट युक्ति पर काम कर रहा हूं। तो यहाँ मेरी समझ है: पहले वे थे:

1. OpenID Google का स्वामित्व कार्यान्वयन था जो समाचार पत्रों की वेबसाइटों की तरह तीसरे पक्ष के एप्लिकेशनों की अनुमति देता है, जिन्हें आप Google का उपयोग करके लॉगिन कर सकते हैं और एक लेख और अन्य उपयोगों पर टिप्पणी कर सकते हैं। इसलिए अनिवार्य रूप से, अखबार की वेबसाइट पर कोई पासवर्ड शेयरिंग नहीं। मुझे यहां एक परिभाषा देनी चाहिए, उद्यम दृष्टिकोण में इस दृष्टिकोण को फेडरेशन कहा जाता है। फेडरेशन में, आपके पास एक सर्वर होता है जहां आप प्रमाणित करते हैं और अधिकृत करते हैं (जिसे आईडीपी, आइडेंटिटी प्रोवाइडर कहा जाता है) और आम तौर पर उपयोगकर्ता क्रेडेंशियल्स का रक्षक होता है। क्लाइंट अनुप्रयोग जहाँ आपके पास व्यवसाय है उसे SP या सेवा प्रदाता कहा जाता है। यदि हम उसी अखबार की वेबसाइट के उदाहरण पर वापस जाते हैं तो अखबार की वेबसाइट यहां एसपी है और Google आईडीपी है। उद्यम में इस समस्या को पहले एसएएमएल का उपयोग करके हल किया गया था। उस समय XML सॉफ्टवेयर उद्योग पर राज करता था। तो webservices से विन्यास के लिए, सब कुछ XML में जाता था ताकि हमारे पास SAML हो,

2. OAuth: OAuth ने देखा कि यह एक मानक के रूप में उभर रहा है जो इन सभी प्रकार के स्वामित्व दृष्टिकोणों को देख रहा है और इसलिए हमारे पास OAuth 1.o मानक के रूप में था लेकिन केवल प्राधिकरण को संबोधित करते हुए। बहुत से लोगों का ध्यान नहीं गया लेकिन यह एक तरह से उठा। तब हमारे पास 2012 में OAuth 2.0 था। सीटीओ, आर्किटेक्ट्स ने वास्तव में ध्यान देना शुरू कर दिया क्योंकि दुनिया क्लाउड कंप्यूटिंग की ओर बढ़ रही है और कंप्यूटिंग डिवाइस मोबाइल और ऐसे अन्य उपकरणों की ओर बढ़ रही है। OAuth तरह की समस्याओं को हल करने पर ध्यान दिया जाता है जहाँ सॉफ्टवेयर ग्राहक एक कंपनी को IDP सेवा दे सकते हैं और विभिन्न विक्रेताओं जैसे सेल्सफोर्स, SAP इत्यादि से कई सेवाएँ ले सकते हैं। इसलिए यहाँ एकीकरण वास्तव में फेडरेशन परिदृश्य की तरह दिखता है एक बड़ी समस्या, SAML का उपयोग करना महंगा है। तो आइये OAuth 2.o. ओह, एक महत्वपूर्ण बिंदु चूक गया कि इस समय के दौरान, Google को लगा कि OAuth वास्तव में नहीं है '

   ए। OAuth 2.o स्पष्ट रूप से नहीं कहता है कि क्लाइंट पंजीकरण बी कैसे होगा। यह SP (संसाधन सर्वर) और क्लाइंट एप्लिकेशन के बीच की बातचीत के बारे में कुछ भी उल्लेख नहीं करता है (जैसे डेटा प्रदान करने वाला Analytics सर्वर संसाधन सर्वर है और उस डेटा को प्रदर्शित करने वाला एप्लिकेशन क्लाइंट है)

तकनीकी रूप से यहां पहले से ही अद्भुत जवाब दिए गए हैं, मैंने संक्षिप्त विकास के परिप्रेक्ष्य देने के बारे में सोचा

Answer 14

OpenId प्रमाणीकरण से निपटने के लिए OAuth का उपयोग करता है।

सादृश्य से, यह ऐसा है जैसे .NET विंडोज एपीआई पर निर्भर करता है। आप सीधे विंडोज एपीआई कह सकते हैं, लेकिन यह इतना व्यापक, जटिल और विधि संबंधी तर्क इतना विशाल है, आप आसानी से गलती / बग / सुरक्षा मुद्दा बना सकते हैं।

OpenId / OAuth के साथ भी। OpenId प्रमाणीकरण का प्रबंधन करने के लिए OAuth पर निर्भर करता है, लेकिन एक विशिष्ट टोकन (Id_token), डिजिटल हस्ताक्षर और विशेष प्रवाह को परिभाषित करता है।

Answer 15

मैं इस प्रश्न के एक विशेष पहलू को संबोधित करना चाहूंगा, जैसा कि इस टिप्पणी में लिया गया है:

OAuth: कुछ सुविधा तक पहुंच प्रदान करने से पहले, प्रमाणीकरण किया जाना चाहिए, सही? तो OAuth = क्या OpenId + कुछ सुविधाओं तक पहुँच प्रदान करता है? - हसन मकरोव जून 21 को 1:57 बजे

हां और ना। जवाब सूक्ष्म है, इसलिए मेरे साथ सहन करो।

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

ध्यान दें कि अंतिम वाक्य की सामान्यता: विशेष रूप से, मैं "एक दिया उपयोगकर्ता की ओर से" लिखा था, नहीं "की ओर से आप "। यह मान लेना एक सामान्य त्रुटि है कि "किसी दिए गए उपयोगकर्ता के स्वामित्व वाले संसाधन के साथ बातचीत करने की क्षमता" का तात्पर्य है "आप और लक्ष्य संसाधन (ओं) के मालिक एक ही हैं"।

यह गलती मत करो।

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

प्रमाणीकरण को संभालने के लिए, आप संभवतः OpenID कनेक्ट को देखना चाहेंगे, जो कि OAuth 2.0 द्वारा निर्धारित नींव के शीर्ष पर अनिवार्य रूप से एक और परत है। यहां एक ऐसा उद्धरण है जो ओपनआईडी कनेक्ट ( https://oauth.net/articles/authentication/ से ) के बारे में सबसे प्रमुख बिंदुओं पर (मेरी राय में) कब्जा करता है :

OpenID कनेक्ट 2014 के प्रारंभ में प्रकाशित एक खुला मानक है जो उपयोगकर्ता प्रमाणीकरण करने के लिए OAuth 2.0 का उपयोग करने के लिए एक अंतर तरीका को परिभाषित करता है। संक्षेप में, यह चॉकलेट ठगना के लिए एक व्यापक रूप से प्रकाशित नुस्खा है जिसे विशेषज्ञों की एक विस्तृत संख्या और विविधता द्वारा आज़माया गया है। प्रत्येक संभावित पहचान प्रदाता के लिए एक अलग प्रोटोकॉल के निर्माण के बजाय, एक एप्लिकेशन एक प्रोटोकॉल को कई प्रदाताओं को बोल सकता है जितना वे काम करना चाहते हैं। चूंकि यह एक खुला मानक है, OpenID Connect को बिना किसी प्रतिबंध या बौद्धिक संपदा चिंताओं के किसी के द्वारा भी लागू किया जा सकता है।

OpenID कनेक्ट सीधे OAuth 2.0 पर बनाया गया है और ज्यादातर मामलों में एक OAuth बुनियादी ढांचे के साथ (या शीर्ष पर) सही तैनात किया गया है। OpenID कनेक्ट विभिन्न स्थानों में साइन इन और एन्क्रिप्टेड जानकारी को ले जाने के लिए विनिर्देशों के JSON ऑब्जेक्ट साइनिंग और एन्क्रिप्शन (JOSE) सुइट का उपयोग करता है। वास्तव में, JOSE क्षमताओं के साथ एक OAuth 2.0 तैनाती पहले से ही पूरी तरह से आज्ञाकारी OpenID कनेक्ट सिस्टम को परिभाषित करने का एक लंबा रास्ता है, और दोनों के बीच का डेल्टा अपेक्षाकृत छोटा है। लेकिन वह डेल्टा एक बड़ा अंतर बनाता है, और ओपनआईडी कनेक्ट OAuth बेस में कई प्रमुख घटकों को जोड़कर ऊपर चर्चा की गई कई कमियों से बचने का प्रबंधन करता है: [...]

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

Answer 16

दोनों प्रोटोकॉल अलग-अलग कारणों से बनाए गए थे। OAuth को संसाधनों तक पहुंचने के लिए तीसरे पक्ष को अधिकृत करने के लिए बनाया गया था। OpenID विकेंद्रीकरण पहचान सत्यापन करने के लिए बनाया गया था। यह वेबसाइट निम्नलिखित बताती है:

OAuth एक प्रोटोकॉल है जिसे एंड-यूज़र की पहचान को सत्यापित करने और तीसरे पक्ष को अनुमति देने के लिए डिज़ाइन किया गया है। इस सत्यापन से टोकन प्राप्त होता है। उपयोगकर्ता की ओर से संसाधनों तक पहुंचने के लिए तीसरा पक्ष इस टोकन का उपयोग कर सकता है। टोकन का एक दायरा है। स्कोप का उपयोग यह सत्यापित करने के लिए किया जाता है कि संसाधन उपयोगकर्ता के लिए सुलभ है या नहीं

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

Answer 17

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

Answer 18

OAuth 2.0 एक सुरक्षा प्रोटोकॉल है। यह एक प्रमाणीकरण नॉर एक प्राधिकरण प्रोटोकॉल है।

दो सवालों के जवाब परिभाषा द्वारा प्रमाणीकरण।

1. उपयोगकर्ता कौन है?
2. क्या उपयोगकर्ता वर्तमान में सिस्टम पर मौजूद है?

OAuth 2.0 में निम्नलिखित अनुदान प्रकार हैं

• client_credentials: जब एक ऐप को दूसरे ऐप के साथ इंटरैक्ट करना होगा और कई यूज़र्स के डेटा को संशोधित करना होगा।
• authorization_code: उपयोगकर्ता एक access_token जारी करने के लिए प्राधिकरण सर्वर को दर्शाता है जिसे क्लाइंट संरक्षित संसाधन तक पहुंचने के लिए उपयोग कर सकता है
• ताज़ा_टोकन: जब access_token समाप्त हो जाता है, तो ताज़ा पहुँच पाने के लिए ताज़ा टोकन का लाभ उठाया जा सकता है
• पासवर्ड: उपयोगकर्ता अपने लॉगिन क्रेडेंशियल को एक क्लाइंट को प्रदान करता है जो प्राधिकरण सर्वर को कॉल करता है और एक access_token प्राप्त करता है

सभी 4 में एक चीज समान है, access_token, एक विरूपण साक्ष्य जिसका उपयोग संरक्षित संसाधन तक पहुंचने के लिए किया जा सकता है।

Access_token उन 2 प्रश्नों के उत्तर प्रदान नहीं करता है जो "प्रमाणीकरण" प्रोटोकॉल का उत्तर देना चाहिए।

Oauth 2.0 (क्रेडिट: OAuth 2 इन एक्शन, मैनिंग प्रकाशन) को समझाने के लिए एक उदाहरण

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

यदि आप प्रमाणीकरण चाहते हैं, तो आप OpenID कनेक्ट के लिए जा सकते हैं, जो एक "id_token" प्रदान करता है, इसके अलावा एक access_token है, जो उन सवालों के जवाब देता है जिनका हर प्रमाणीकरण प्रोटोकॉल को जवाब देना चाहिए।

Answer 19

ऑउथ प्राधिकरण के शीर्ष पर प्रमाणीकरण का निर्माण करता है: उपयोगकर्ता अपनी पहचान का उपयोग आवेदन में करता है, जो तब, पहचान एपीआई का उपभोक्ता बन जाता है, जिससे पता चलता है कि ग्राहक को पहली बार में किसने अधिकृत किया है http://oauth.net/ लेख / प्रमाणीकरण /