OAuth 2.0 को समझना आसान है

हाब पर पहले से ही OAuth 1.0 के बारे में लिखा था, लेकिन इस तरह के OAuth 2.0 का कोई स्पष्ट स्पष्टीकरण नहीं था। नीचे मैं आपको बताऊंगा कि OAuth 2.0 के अंतर और फायदे क्या हैं और इसका उपयोग साइटों पर, मोबाइल और डेस्कटॉप अनुप्रयोगों में कैसे किया जाता है।

OAuth 2.0 क्या है

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

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

इस तथ्य के बावजूद कि इस विषय पर पहले से ही कई स्पष्टीकरण थे, यह अभी भी कुछ गलतफहमी का कारण बनता है।

OpenID प्रमाणीकरण के लिए अभिप्रेत है - अर्थात, यह समझने के लिए कि यह विशेष उपयोगकर्ता है कि वह कौन है। उदाहरण के लिए, ओपनआईडी की मदद से, एक निश्चित ओलोलो सेवा समझ सकती है कि जिस उपयोगकर्ता ने वहां प्रवेश किया है वह Mail.Ru से रोमा नोविकोव है। अगले प्रमाणीकरण में, ओलोलो उसे फिर से पहचानने और समझने में सक्षम हो जाएगा, यह आखिरी बार के समान रोमा है।

OAuth एक प्राधिकरण प्रोटोकॉल है, अर्थात यह आपको उन कार्यों के अधिकार जारी करने की अनुमति देता है, जो ओलाओ खुद रोमा की ओर से Mail.Ru में प्रदर्शन कर सकते हैं। उसी समय, प्राधिकरण के बाद, रोमा प्रदर्शन करने की प्रक्रिया में बिल्कुल भी भाग नहीं ले सकता है, उदाहरण के लिए, ओलोलो स्वतंत्र रूप से रोमिन खाते में फ़ोटो अपलोड करने में सक्षम होगा।

कैसे OAuth 2.0 काम करता है

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

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

OAuth का उपयोग करके किसी एप्लिकेशन के संचालन की सामान्य योजना इस प्रकार है:

1. प्राधिकरण प्राप्त करना
2. सुरक्षित संसाधनों तक पहुंच

प्राधिकरण का परिणाम टोकन है - एक निश्चित कुंजी (आमतौर पर पात्रों का एक सेट), जिसकी प्रस्तुति संरक्षित संसाधनों के लिए एक पास है। सरलतम मामले में, उन्हें HTTPS के माध्यम से एक्सेस किया जाता है, हेडर में संकेत दिया जाता है या प्राप्त एक्सेस टोकन में से एक पैरामीटर के रूप में।

प्रोटोकॉल विभिन्न स्थितियों के लिए उपयुक्त कई प्राधिकरण विकल्पों का वर्णन करता है:

• सर्वर भाग वाले अनुप्रयोगों के लिए प्राधिकरण (सबसे अधिक बार, ये साइट और वेब अनुप्रयोग हैं)
• पूरी तरह से ग्राहक अनुप्रयोगों (मोबाइल और डेस्कटॉप अनुप्रयोगों) के लिए प्राधिकरण
• लॉगिन और पासवर्ड प्राधिकरण
• पिछले प्राधिकरण को पुनर्स्थापित करें

सर्वर-साइड अनुप्रयोगों के लिए प्राधिकरण

1. लॉगिन पेज पर रीडायरेक्ट करें
2. प्राधिकरण पृष्ठ पर, उपयोगकर्ता को अधिकारों के जारी होने की पुष्टि करने का अनुरोध किया जाता है
3. उपयोगकर्ता की सहमति के मामले में, ब्राउज़र जीआरई मापदंडों में एक विशेष कुंजी के अलावा - प्राधिकरण कोड खोलते समय निर्दिष्ट URL पर रीडायरेक्ट करेगा - प्राधिकरण कोड
4. एप्लिकेशन सर्वर एक पैरामीटर के रूप में प्राप्त प्राधिकरण कोड के साथ एक POST अनुरोध करता है। यह अनुरोध पहुँच टोकन लौटाता है

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

उदाहरण

यहां और आगे के उदाहरण Mail.Ru API के लिए दिए गए हैं, लेकिन तर्क सभी सेवाओं के लिए समान है, केवल प्राधिकरण पृष्ठों के पते बदल जाते हैं। कृपया ध्यान दें कि अनुरोध HTTPS से अधिक होने चाहिए ।

उपयोगकर्ता के ब्राउज़र को प्राधिकरण पृष्ठ पर पुनर्निर्देशित करें:

 > GET / oauth / अधिकृत करें? Response_type = code & client_id = 464119 और
       redirect_uri = http% 3A% 2F% 2Fexample.com% 2Fcb% 2F123 HTTP / 1.1
 > होस्ट: connect.mail.ru

इसके बाद, client_id और client_secret प्लेटफ़ॉर्म पर एप्लिकेशन को पंजीकृत करते समय प्राप्त मान हैं।

उपयोगकर्ता द्वारा अधिकार जारी करने के बाद, निर्दिष्ट पुनर्निर्देशित_ पुनर्निर्देशित होता है:

 <HTTP / 1.1 302 मिला
 <स्थान: http://example.com/cb/123?code=DoRieb0y

कृपया ध्यान दें कि यदि आप OAuth का उपयोग करते हुए साइट पर लॉगिन को लागू करते हैं, तो CSRF हमलों (उदाहरण के लिए, यह 123) को रोकने के लिए redirect_uri में प्रत्येक उपयोगकर्ता के लिए एक विशिष्ट पहचानकर्ता जोड़ने की सिफारिश की जाती है। कोड प्राप्त होने पर, आपको यह जांचना होगा कि यह पहचानकर्ता परिवर्तित नहीं हुआ है और वर्तमान उपयोगकर्ता से मेल खाता है।

हम सर्वर से एक अनुरोध निष्पादित करके access_token प्राप्त करने के लिए प्राप्त कोड का उपयोग करते हैं:

 > POST / oauth / टोकन HTTP / 1.1
 > होस्ट: connect.mail.ru
 > सामग्री-प्रकार: आवेदन / x-www-form-urlencoded
 > 
 > अनुदान_प्रकार = प्राधिकरण_कोड और मुवक्किल_िद = ४६४११ ९ और मुवक्किल_सेक्रेट = डेडबीफ एंड कोड = डोरीबी ० एंड
   redirect_uri = http% 3A% 2F% 2Fexample.com% 2Fcb% 2F123

 <HTTP / 1.1 200 ठीक है
 <सामग्री-प्रकार: आवेदन / json
 <
 <{
 <"access_token": "SlAV32hkKG",
 <"टोकन_टाइप": "बियरर",
 <"expires_in": 86400,
 <"ताज़ा_टोकन": "8xLOxBtZp8",
 <}

कृपया ध्यान दें कि अंतिम अनुरोध client_secret का उपयोग करता है, जो इस मामले में एप्लिकेशन सर्वर पर संग्रहीत है, और पुष्टि करता है कि अनुरोध के साथ छेड़छाड़ नहीं की गई है।

अंतिम अनुरोध के परिणामस्वरूप, हम पहुंच कुंजी ( access_token ), इसके "लुप्त होती" ( expires_in ) का समय प्राप्त करते हैं, कुंजी का प्रकार जो यह निर्धारित करता है कि इसका उपयोग कैसे किया जाना चाहिए ( token_type ) और refresh_token , जिसके बारे में नीचे और अधिक विस्तार से चर्चा की जाएगी। इसके अलावा, प्राप्त डेटा का उपयोग संरक्षित संसाधनों तक पहुंचने के लिए किया जा सकता है, उदाहरण के लिए, Mail.Ru API:

 > GET /platform/api?oauth_token=SlAV32hkKG&client_id=464119&format=json&method=users.getInfo&
       sig = ... HTTP / 1.1
 > होस्ट: appsmail.ru

विवरण में विवरण

पूरी तरह से ग्राहक अनुप्रयोगों का प्राधिकरण

1. एक प्राधिकरण पृष्ठ के साथ अंतर्निहित ब्राउज़र खोलना
2. उपयोगकर्ता से अधिकारों के अनुदान की पुष्टि का अनुरोध किया जाता है
3. यदि उपयोगकर्ता सहमत हो जाता है, तो ब्राउज़र खंड में पृष्ठ (# के बाद) में स्टब पृष्ठ पर रीडायरेक्ट करेगा, जिसका URL टोकन तक पहुंच है
4. एप्लिकेशन एक रीडायरेक्ट को स्वीकार करता है और पेज एड्रेस से एक्सेस टोकन प्राप्त करता है

इस विकल्प को एप्लिकेशन में ब्राउज़र विंडो को ऊपर उठाने की आवश्यकता होती है, लेकिन सर्वर टोकन और एक्सेस टोकन के लिए प्राधिकरण कोड के आदान-प्रदान के लिए एक अतिरिक्त सर्वर-सर्वर कॉल की आवश्यकता नहीं होती है।

उदाहरण

एक प्राधिकरण पृष्ठ वाला एक ब्राउज़र खोलें:

 > GET / oauth / अधिकृत करें? Response_type = token & client_id = 464119 HTTP / 1.1
 > होस्ट: connect.mail.ru

उपयोगकर्ता के अधिकारों के बाद, मानक स्टब पृष्ठ पर पुनर्निर्देशित होता है, Mail.Ru के लिए, यह connect.mail.ru/oauth/success.html है :

 <HTTP / 1.1 302 मिला
 <स्थान: http://connect.mail.ru/oauth/success.html#access_token=FJQbwq9&token_type=bearer&
             expires_in = 86400 और रिफ्रेश_टोकन = yaeFa0gu

एप्लिकेशन को अंतिम रीडायरेक्ट को रोकना चाहिए, acess_token पते से प्राप्त करें और संरक्षित संसाधनों तक पहुंचने के लिए इसका उपयोग करें।

विवरण में विवरण

लॉगिन और पासवर्ड प्राधिकरण

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

उदाहरण

 > POST / oauth / टोकन HTTP / 1.1
 > होस्ट: connect.mail.ru
 > सामग्री-प्रकार: आवेदन / x-www-form-urlencoded
 > 
 > allow_type=password&client_id=31337&client_secret=deadbeef&username=api@corp.mail.ru&
   पासवर्ड = मात्रा

 <HTTP / 1.1 200 ठीक है
 <सामग्री-प्रकार: आवेदन / json
 <
 <{
 <"access_token": "SlAV32hkKG",
 <"टोकन_टाइप": "बियरर",
 <"expires_in": 86400,
 <"ताज़ा_टोकन": "8xLOxBtZp8",
 <}

विवरण में विवरण

पिछले प्राधिकरण को पुनर्स्थापित करें

आमतौर पर, एक्सेस टोकन में एक सीमित शैल्फ जीवन होता है। यह उपयोगी हो सकता है, उदाहरण के लिए, यदि यह खुले चैनलों पर प्रसारित होता है। उपयोगकर्ता को टोकन के समाप्ति के बाद प्रमाणित करने के लिए मजबूर नहीं करने के लिए, उपरोक्त सभी विकल्पों में, टोकन तक पहुँचने के अलावा, ताज़ा ताज़ा टोकन भी वापस किया जा सकता है। उस पर, आप लॉगिन और पासवर्ड द्वारा प्राधिकरण के समान, HTTP अनुरोध का उपयोग करके टोकन प्राप्त कर सकते हैं।

उदाहरण

 > POST / oauth / टोकन HTTP / 1.1
 > होस्ट: connect.mail.ru
 > सामग्री-प्रकार: आवेदन / x-www-form-urlencoded
 > 
 > अनुदान_प्रकार = ताज़ा_टोकन और मुवक्किल_द = ३१३३ client और ग्राहक_सेक्रेट = डेडबीफ और रिफ्रेश_टोकेन = xxLOxBtZp8

 <HTTP / 1.1 200 ठीक है
 <सामग्री-प्रकार: आवेदन / json
 <
 <{
 <"access_token": "Uu8oor1i",
 <"टोकन_टाइप": "बियरर",
 <"expires_in": 86400,
 <"ताज़ा_तोकेन": "ओहोवोहोह्र",
 <}

विवरण में विवरण

OAuth 2.0 का विपक्ष

इस सब सुंदरता में मरहम में एक मक्खी है, इसके बिना कहां?

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

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

निष्कर्ष

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

हमारे भाग के लिए, हमने Mail.Ru API में OAuth 2.0 को लागू किया है और अब आप Mail.Ru के साथ एकीकृत किसी भी क्लाइंट और सेवाओं को लागू करने के लिए प्रोटोकॉल सुविधाओं का उपयोग कर सकते हैं।

संदर्भ

• ड्राफ्ट मानक OAuth 2.0 का वर्तमान संस्करण
• आधिकारिक OAuth वेबसाइट
• मानक कार्य समूह ( अभिलेखागार )
• OAuth 2.0 Mail.Ru में कार्यान्वयन प्रलेखन

दिमित्री बिटमैन - प्लेटफ़ॉर्म मैनेजर Mail.Ru