पृष्ठभूमि: मैंने OAuth 1.0a और 2.0 के लिए क्लाइंट और सर्वर स्टैक लिखे हैं।
OAuth 1.0a और 2.0 दोनों दो-पैर वाले प्रमाणीकरण का समर्थन करते हैं , जहां एक सर्वर को उपयोगकर्ता की पहचान और तीन-पैर वाले प्रमाणीकरण का आश्वासन दिया जाता है, जहां एक सर्वर को उपयोगकर्ता की पहचान के सामग्री प्रदाता द्वारा आश्वासन दिया जाता है। तीन-पैर वाला प्रमाणीकरण वह जगह है जहां प्राधिकरण अनुरोध और पहुंच टोकन खेल में आते हैं, और यह ध्यान रखना महत्वपूर्ण है कि OAuth 1 में वे भी हैं।
जटिल एक: तीन-पैर वाला प्रमाणीकरण
OAuth चश्मा का एक मुख्य बिंदु एक सामग्री प्रदाता (जैसे फेसबुक, ट्विटर, आदि) एक सर्वर को आश्वस्त करने के लिए है (उदाहरण के लिए एक वेब ऐप जो क्लाइंट की ओर से सामग्री प्रदाता से बात करना चाहता है) कि ग्राहक की कुछ पहचान है । तीन-पैर वाले प्रमाणीकरण की पेशकश वह क्षमता है जो उस ग्राहक या सर्वर के बिना उस पहचान के विवरण (जैसे उपयोगकर्ता नाम और पासवर्ड) को जानने की आवश्यकता होती है ।
OAuth के विवरण में बहुत गहरा हो रहा है;
- क्लाइंट सर्वर के लिए एक प्राधिकरण अनुरोध सबमिट करता है, जो यह पुष्टि करता है कि ग्राहक उसकी सेवा का एक वैध ग्राहक है।
- सर्वर क्लाइंट को अपने संसाधनों तक पहुंच का अनुरोध करने के लिए सामग्री प्रदाता को पुनर्निर्देशित करता है।
- सामग्री प्रदाता उपयोगकर्ता की पहचान को मान्य करता है, और अक्सर संसाधनों तक पहुंचने के लिए उनकी अनुमति का अनुरोध करता है।
- सामग्री प्रदाता क्लाइंट को सर्वर पर वापस ले जाता है, इसे सफलता या विफलता की सूचना देता है। इस अनुरोध में सफलता पर एक प्राधिकरण कोड शामिल है।
- सर्वर सामग्री प्रदाता के लिए एक आउट-ऑफ-बैंड अनुरोध करता है और एक्सेस टोकन के लिए प्राधिकरण कोड का आदान-प्रदान करता है।
सर्वर अब एक्सेस टोकन पास करके उपयोगकर्ता की ओर से सामग्री प्रदाता के लिए अनुरोध कर सकता है।
प्रत्येक एक्सचेंज (क्लाइंट-> सर्वर, सर्वर-> सामग्री प्रदाता) में एक साझा रहस्य का सत्यापन शामिल है, लेकिन चूंकि OAuth 1 एक अनएन्क्रिप्टेड कनेक्शन पर चल सकता है, प्रत्येक सत्यापन तार पर रहस्य को पारित नहीं कर सकता है।
जैसा कि आपने नोट किया है, एचएमएसी के साथ। क्लाइंट अपने प्राधिकरण अनुरोध के लिए तर्कों पर हस्ताक्षर करने के लिए सर्वर के साथ साझा किए गए रहस्य का उपयोग करता है। सर्वर तर्कों को लेता है, उन्हें क्लाइंट की कुंजी के साथ साइन करता है, और यह देखने में सक्षम है कि क्या यह एक वैध क्लाइंट है (चरण 1 में)।
इस हस्ताक्षर के लिए क्लाइंट और सर्वर दोनों को तर्कों के आदेश पर सहमत होने की आवश्यकता होती है (इसलिए वे समान स्ट्रिंग पर हस्ताक्षर कर रहे हैं), और OAuth 1 के बारे में मुख्य शिकायतों में से एक यह है कि इसके लिए सर्वर और क्लाइंट दोनों को सॉर्ट करना होगा और सांकेतिक रूप से हस्ताक्षर करें। यह पूरी तरह से कोड है और या तो यह सही है या आपको 401 Unauthorizedथोड़ी मदद मिलती है। इससे क्लाइंट लिखने की बाधा बढ़ जाती है।
SSL पर चलने के लिए प्राधिकरण अनुरोध की आवश्यकता के अनुसार, OAuth 2.0 तर्क छांटने और हस्ताक्षर करने की आवश्यकता को पूरी तरह से हटा देता है। क्लाइंट अपना सीक्रेट सर्वर से पास करता है, जो इसे सीधे सत्यापित करता है।
सर्वर-> सामग्री प्रदाता कनेक्शन में समान आवश्यकताएं मौजूद हैं, और चूंकि वह एसएसएल है जो OAuth सेवाओं तक पहुंचने वाले सर्वर को लिखने के लिए एक अवरोध को हटाता है।
इससे ऊपर के चरण 1, 2 और 5 में चीजें आसान हो जाती हैं।
तो इस बिंदु पर हमारे सर्वर में एक स्थायी पहुंच टोकन है जो उपयोगकर्ता के लिए एक उपयोगकर्ता नाम / पासवर्ड के बराबर है। यह अनुरोध के भाग के रूप में उस टोकन को पास करके उपयोगकर्ता की ओर से सामग्री प्रदाता को अनुरोध कर सकता है (क्वेरी तर्क, HTTP शीर्ष लेख या POST प्रपत्र डेटा के रूप में)।
यदि सामग्री सेवा केवल एसएसएल पर ही एक्सेस की जाती है, तो हम कर रहे हैं। यदि यह सादे HTTP के माध्यम से उपलब्ध है, तो हम उस स्थायी पहुँच टोकन को किसी तरह से सुरक्षित रखना चाहेंगे। कनेक्शन को सूँघने वाला कोई भी व्यक्ति उपयोगकर्ता की सामग्री तक हमेशा पहुँच बना सकेगा।
जिस तरह से OAuth 2 में हल किया गया है वह एक ताज़ा टोकन के साथ है । ताज़ा टोकन स्थायी पासवर्ड के बराबर हो जाता है, और यह केवल SSL पर प्रसारित होता है । जब सर्वर को सामग्री सेवा तक पहुंच की आवश्यकता होती है, तो यह अल्पकालिक एक्सेस टोकन के लिए ताज़ा टोकन का आदान-प्रदान करता है। इस तरह से सभी सूंघने योग्य HTTP एक्सेस टोकन के साथ बनाए जाते हैं जो समाप्त हो जाएंगे। Google अपने OAuth 2 API पर 5 मिनट की समाप्ति का उपयोग कर रहा है।
इसलिए ताज़ा टोकन से अलग, OAuth 2 क्लाइंट, सर्वर और सामग्री प्रदाता के बीच सभी संचारों को सरल करता है। और ताज़ा टोकन केवल तब सुरक्षा प्रदान करने के लिए मौजूद होते हैं जब सामग्री को अनएन्क्रिप्टेड एक्सेस किया जा रहा हो।
दो पैरों वाला प्रमाणीकरण
कभी-कभी, हालांकि, एक सर्वर को केवल अपनी सामग्री तक पहुंच को नियंत्रित करने की आवश्यकता होती है। दो-पैर वाला प्रमाणीकरण क्लाइंट को सर्वर से सीधे उपयोगकर्ता को प्रमाणित करने की अनुमति देता है।
OAuth 2 OAuth 1 के लिए कुछ एक्सटेंशन का मानकीकरण करता है जो व्यापक उपयोग में थे। मुझे जो सबसे अच्छी तरह से पता है वह ट्विटर द्वारा xAuth के रूप में पेश किया गया था । आप इसे OAuth 2 में रिसोर्स ओनर पासवर्ड क्रेडेंशियल्स के रूप में देख सकते हैं ।
अनिवार्य रूप से, यदि आप उपयोगकर्ता के क्रेडेंशियल्स (उपयोगकर्ता नाम और पासवर्ड) के साथ क्लाइंट पर भरोसा कर सकते हैं, तो वे एक्सेस टोकन के लिए सामग्री प्रदाता के साथ सीधे आदान-प्रदान कर सकते हैं। यह OAuth को मोबाइल एप्लिकेशन पर अधिक उपयोगी बनाता है - तीन-पैर वाले प्रमाणीकरण के साथ, आपको सामग्री सर्वर के साथ प्राधिकरण प्रक्रिया को संभालने के लिए एक HTTP दृश्य एम्बेड करना होगा।
OAuth 1 के साथ, यह आधिकारिक मानक का हिस्सा नहीं था, और अन्य सभी अनुरोधों के समान हस्ताक्षर प्रक्रिया की आवश्यकता थी।
मैंने रिसोर्स ओनर पासवर्ड क्रेडेंशियल्स के साथ OAuth 2 का सर्वर साइड लागू किया है, और क्लाइंट के नजरिए से, एक्सेस टोकन प्राप्त करना सरल हो गया है: सर्वर से एक्सेस का अनुरोध करें, क्लाइंट आईडी / सीक्रेट को HTTP ऑथराइजेशन हैडर और गुप्त रूप से पास करें प्रपत्र डेटा के रूप में उपयोगकर्ता का लॉगिन / पासवर्ड।
फायदा: सादगी
इसलिए एक कार्यान्वयनकर्ता के दृष्टिकोण से, मैं OAuth 2 में जो मुख्य लाभ देख रहा हूं, वे कम जटिलता में हैं। इसके लिए अनुरोध पर हस्ताक्षर करने की प्रक्रिया की आवश्यकता नहीं है, जो कि बिल्कुल कठिन नहीं है, लेकिन निश्चित रूप से निस्संदेह है। यह किसी सेवा के ग्राहक के रूप में कार्य करने के लिए आवश्यक कार्य को बहुत कम कर देता है, जो कि (आधुनिक, मोबाइल दुनिया में) आप सबसे अधिक दर्द को कम करना चाहते हैं। सर्वर-> कंटेंट प्रोवाइडर एंड पर कम जटिलता इसे डेटासेंटर में अधिक मापनीय बनाती है।
और यह मानक कुछ एक्सटेंशन को OAuth 1.0a (जैसे xAuth) में कोडित करता है जो अब व्यापक उपयोग में हैं।