OAuth 2.0 के बारे में जानकारी

यह Apigee Edge के दस्तावेज़ हैं.
पर जाएं Apigee X के दस्तावेज़ों. info

OAuth होम: OAuth के बारे में हमारी गाइडेंस की खास जानकारी के लिए, OAuth का होम पेज देखें .

इस विषय में, Apigee Edge पर OAuth 2.0 की खास जानकारी दी गई है.

OAuth 2.0 क्या है?

OAuth 2.0 के बारे में कई किताबें, ब्लॉग, और साइटें मौजूद हैं. हमारा सुझाव है कि आप IETF OAuth 2.0 की खास जानकारी से शुरुआत करें. यहां OAuth 2.0 IETF की खास जानकारी में, OAuth 2.0 की परिभाषा दी गई है:

OAuth 2.0 ऑथराइज़ेशन फ़्रेमवर्क की मदद से, तीसरे पक्ष का कोई ऐप्लिकेशन, एचटीटीपी सेवा का सीमित ऐक्सेस पा सकता है. इसके लिए, वह संसाधन के मालिक की ओर से, एचटीटीपी सेवा और संसाधन के मालिक के बीच अनुमति के लिए इंटरैक्शन को ऑर्केस्ट्रेट करता है. इसके अलावा, तीसरे पक्ष का ऐप्लिकेशन अपने लिए भी ऐक्सेस पा सकता है.

आपको यह जानना ज़रूरी है कि OAuth 2.0 की मदद से, ऐप्लिकेशन को उपयोगकर्ता के सुरक्षित संसाधनों का सीमित ऐक्सेस मिलता है. जैसे, बैंक खाता या कोई अन्य संवेदनशील जानकारी जिसे उपयोगकर्ता किसी ऐप्लिकेशन से ऐक्सेस करना चाहता है. इसके लिए, उपयोगकर्ता को अपने लॉगिन क्रेडेंशियल, ऐप्लिकेशन के साथ शेयर करने की ज़रूरत नहीं होती.

OAuth 2.0 फ़्लो

यहां OAuth 2.0 सुरक्षा फ़्रेमवर्क का सामान्य फ़्लो दिया गया है. हम इस विषय में इस फ़्लो के बारे में ज़्यादा जानकारी देंगे. इसके लिए, हम एक डायग्राम से शुरुआत करेंगे. इससे OAuth 2.0 के काम करने के तरीके के बारे में काफ़ी जानकारी मिलती है. अगर आपको इस डायग्राम में इस्तेमाल किए गए शब्दों के बारे में जानकारी नहीं है, तो खास जानकारी के लिए यह सेक्शन पढ़ें

ये शब्द आपको पता होने चाहिए

• क्लाइंट: इसे "ऐप्लिकेशन" भी कहा जाता है. यह किसी मोबाइल डिवाइस पर चलने वाला ऐप्लिकेशन या कोई सामान्य वेब ऐप्लिकेशन हो सकता है. ऐप्लिकेशन, संसाधन के मालिक की ओर से, सुरक्षित ऐसेट के लिए संसाधन सर्वर को अनुरोध भेजता है. संसाधन के मालिक को, सुरक्षित संसाधनों को ऐक्सेस करने की अनुमति ऐप्लिकेशन को देनी होगी.
• संसाधन का मालिक: इसे "असली उपयोगकर्ता" भी कहा जाता है. आम तौर पर, यह वह व्यक्ति (या अन्य इकाई) होती है जो सुरक्षित संसाधन को ऐक्सेस करने की अनुमति दे सकती है. उदाहरण के लिए, अगर किसी ऐप्लिकेशन को आपकी सोशल मीडिया साइटों में से किसी एक का डेटा इस्तेमाल करना है, तो आप संसाधन के मालिक हैं. सिर्फ़ आपके पास, ऐप्लिकेशन को अपना डेटा ऐक्सेस करने की अनुमति देने का विकल्प है.
• संसाधन सर्वर: संसाधन सर्वर को Facebook, Google या Twitter जैसी सेवा के तौर पर समझें. इसके अलावा, यह आपके इंटर्नेट पर मौजूद एचआर सेवा या आपके B2B एक्सट्रानेट पर मौजूद पार्टनर सेवा भी हो सकती है. Apigee Edge, एक संसाधन सर्वर है. ऐसा तब होता है, जब एपीआई के अनुरोधों को प्रोसेस करने के लिए, OAuth टोकन की पुष्टि करना ज़रूरी हो. संसाधन सर्वर को, ऐप्लिकेशन को सुरक्षित संसाधन उपलब्ध कराने से पहले, किसी तरह की अनुमति की ज़रूरत होती है.
• ऑथराइज़ेशन सर्वर: ऑथराइज़ेशन सर्वर, OAuth 2.0 की खास जानकारी के मुताबिक लागू किया जाता है. यह अनुमति देने के लिए मिले अनुरोधों की पुष्टि करता है और ऐक्सेस टोकन जारी करता है. इन टोकन की मदद से, ऐप्लिकेशन को संसाधन सर्वर पर मौजूद उपयोगकर्ता के डेटा का ऐक्सेस मिलता है. Apigee Edge पर "टोकन एंडपॉइंट" कॉन्फ़िगर किए जा सकते हैं. ऐसे में, Edge, ऑथराइज़ेशन सर्वर की भूमिका निभाता है.
• अनुमति देने के लिए मिला अनुरोध: इसकी मदद से, ऐप्लिकेशन को असली उपयोगकर्ता की ओर से ऐक्सेस टोकन पाने की अनुमति मिलती है. OAuth 2.0 में, "अनुमति देने के लिए मिले अनुरोध के टाइप" के तौर पर चार खास टाइप तय किए गए हैं. नीचे "OAuth 2.0 के तहत, अनुमति देने के लिए मिले अनुरोध के टाइप कौनसे हैं" देखें.
• ऐक्सेस टोकन: यह वर्णों की एक लंबी स्ट्रिंग होती है. इसका इस्तेमाल, सुरक्षित संसाधनों को ऐक्सेस करने के लिए क्रेडेंशियल के तौर पर किया जाता है. नीचे "ऐक्सेस टोकन क्या है?" भी देखें.
• सुरक्षित संसाधन: संसाधन के मालिक का डेटा. उदाहरण के लिए, उपयोगकर्ता की संपर्क सूची, खाते की जानकारी या अन्य संवेदनशील डेटा.

Apigee Edge कहां फ़िट होता है

Apigee Edge के ज़रिए प्रॉक्सी किए गए किसी भी एपीआई को OAuth 2.0 की मदद से सुरक्षित किया जा सकता है. Edge में, ऑथराइज़ेशन सर्वर को लागू करने की सुविधा शामिल है. इसलिए, यह ऐक्सेस टोकन जनरेट और उनकी पुष्टि कर सकता है. डेवलपर, Apigee Edge के साथ अपने ऐप्लिकेशन रजिस्टर करके शुरुआत करते हैं. रजिस्टर किए गए ऐप्लिकेशन, अनुमति देने के लिए मिले अनुरोध के चार grant टाइप में से किसी के भी ज़रिए, ऐक्सेस टोकन का अनुरोध कर सकते हैं.

Apigee, OAuthV2 की एक ऐसी नीति उपलब्ध कराता है जिसमें अनुमति देने के लिए मिले अनुरोध के हर टाइप की जानकारी शामिल होती है. इससे Apigee Edge पर OAuth सेट अप करना आसान हो जाता है. उदाहरण के लिए, ऐसी नीति कॉन्फ़िगर की जा सकती है जो ऐक्सेस टोकन के लिए मिले अनुरोध को स्वीकार करती है, ज़रूरी सभी क्रेडेंशियल की पुष्टि करती है, और अगर क्रेडेंशियल मान्य हैं, तो ऐक्सेस टोकन वापस भेजती है.

ध्यान दें कि आपके सुरक्षित एपीआई प्रॉक्सी से कॉल करने वाले सभी संसाधन सर्वर, फ़ायरवॉल के पीछे होने चाहिए इसका मतलब है कि संसाधनों को, एपीआई प्रॉक्सी या किसी अन्य सुरक्षित एपीआई के अलावा किसी और तरीके से ऐक्सेस नहीं किया जाना चाहिए.

OAuth 2.0 के तहत, अनुमति देने के लिए मिले अनुरोध के टाइप कौनसे हैं?

अनुमति देने के लिए मिले अनुरोध के टाइप को, उन अलग-अलग पाथ या इंटरैक्शन के तौर पर समझें जिनका इस्तेमाल करके कोई ऐप्लिकेशन, ऐक्सेस टोकन पा सकता है. अनुमति देने के लिए मिला अनुरोध का हर टाइप, एक या उससे ज़्यादा इस्तेमाल के उदाहरणों को कवर करता है. आपको अपनी ज़रूरतों के हिसाब से, अनुमति देने के लिए मिले अनुरोध के टाइप चुनने होंगे. आम तौर पर, अनुमति देने के लिए मिले अनुरोध के हर टाइप के फ़ायदे और नुकसान होते हैं. आपको अपने कारोबार के इस्तेमाल के उदाहरणों के हिसाब से, इनके बीच समझौता करना होगा. एक अहम बात यह है कि आपके डेटा को ऐक्सेस करने वाले ऐप्लिकेशन कितने "भरोसेमंद" हैं. आम तौर पर, तीसरे पक्ष के ऐप्लिकेशन, किसी कंपनी में डेवलप और इस्तेमाल किए जाने वाले ऐप्लिकेशन की तुलना में कम भरोसेमंद होते हैं.

Apigee Edge, OAuth 2.0 के तहत, अनुमति देने के लिए मिले अनुरोध के चार मुख्य टाइप के साथ काम करता है:

• ऑथराइज़ेशन कोड -- इसे अनुमति देने के लिए मिले अनुरोध का सबसे सुरक्षित टाइप माना जाता है. ऑथराइज़ेशन सर्वर से ऐक्सेस टोकन जारी करने से पहले, ऐप्लिकेशन को संसाधन सर्धन सर्वर से ऑथराइज़ेशन कोड पाना होगा. आपने यह फ़्लो तब देखा होगा, जब आपका ऐप्लिकेशन, संसाधन सर्वर के लॉगिन पेज पर जाने के लिए कोई ब्राउज़र खोलता है और आपको अपने असली खाते में लॉग इन करने का न्योता देता है. जैसे, Facebook या Twitter.

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

• इंप्लिसिट -- इसे ऑथराइज़ेशन कोड का आसान वर्शन माना जाता है. आम तौर पर, अनुमति देने के लिए मिले अनुरोध के इस टाइप का इस्तेमाल तब किया जाता है, जब ऐप्लिकेशन, क्लाइंट पर मौजूद हो. उदाहरण के लिए, ऐप्लिकेशन का कोड, JavaScript या किसी अन्य स्क्रिप्टिंग भाषा का इस्तेमाल करके, ब्राउज़र में लागू किया जाता है. यह अलग वेब सर्वर पर मौजूद और रन नहीं होता. अनुमति देने के लिए मिले अनुरोध के इस टाइप के फ़्लो में, ऑथराइज़ेशन सर्वर, उपयोगकर्ता की पुष्टि होने पर, सीधे ऐक्सेस टोकन वापस भेजता है. इसके लिए, वह पहले ऑथराइज़ेशन कोड जारी नहीं करता. अनुमति देने के लिए मिले इंप्लिसिट अनुरोधों से, कुछ मामलों में ऐप्लिकेशन की परफ़ॉर्मेंस बेहतर हो सकती है. हालांकि, IETF की खास जानकारी में बताए गए सुरक्षा से जुड़े संभावित जोखिमों के हिसाब से, इस फ़ायदे का आकलन करना ज़रूरी है.
• संसाधन के मालिक के पासवर्ड क्रेडेंशियल -- इस फ़्लो में, क्लाइंट को ऐक्सेस टोकन तब जारी किया जाता है, जब ऑथराइज़ेशन सर्वर, उपयोगकर्ता के उपयोगकर्ता नाम/पासवर्ड की पुष्टि कर लेता है. अनुमति देने के लिए मिले अनुरोध के इस फ़्लो का सुझाव, उन ऐप्लिकेशन के लिए दिया जाता है जिन पर ज़्यादा भरोसा किया जा सकता है. उदाहरण के लिए, बुनियादी पुष्टि की तुलना में, अनुमति देने के लिए मिले अनुरोध के इस फ़्लो का एक फ़ायदा यह है कि उपयोगकर्ता को अपना उपयोगकर्ता नाम/पासवर्ड सिर्फ़ एक बार देना होता है. इसके बाद, ऐक्सेस टोकन का इस्तेमाल किया जाता है.
• क्लाइंट क्रेडेंशियल -- इसका इस्तेमाल उन स्थितियों के लिए करें जहां क्लाइंट ऐप्लिकेशन, अपनी ओर से काम कर रहा हो. इसका मतलब है कि क्लाइंट, संसाधन का मालिक भी है. आम तौर पर, अनुमति देने के लिए मिले अनुरोध के इस टाइप का इस्तेमाल तब किया जाता है, जब ऐप्लिकेशन को बैकएंड डेटा स्टोरेज सेवा को ऐक्सेस करना हो. उदाहरण के लिए. ऐप्लिकेशन को अपना काम करने के लिए, इस सेवा का इस्तेमाल करना होता है. साथ ही, असली उपयोगकर्ता के लिए यह सेवा ओपेक होती है. अनुमति देने के लिए मिले अनुरोध के इस टाइप की मदद से, कोई ऐप्लिकेशन, ऑथराइज़ेशन सर्वर को अपना क्लाइंट आईडी और क्लाइंट सीक्रेट पासकोड दिखाकर, ऐक्सेस टोकन पा सकता है. इसके लिए, किसी और चरण की ज़रूरत नहीं होती. Edge, क्लाइंट क्रेडेंशियल का एक ऐसा सलूशन उपलब्ध कराता है जिसे किसी भी एपीआई प्रॉक्सी के लिए आसानी से लागू किया जा सकता है.

ऐक्सेस टोकन क्या है?

ऐक्सेस टोकन, वर्णों की एक लंबी स्ट्रिंग होती है. इसका इस्तेमाल, सुरक्षित संसाधनों को ऐक्सेस करने के लिए क्रेडेंशियल के तौर पर किया जाता है. संसाधन टोकन (इन्हें बेयरर टोकन भी कहा जाता है) को, ऑथराइज़ेशन हेडर में इस तरह पास किया जाता है:

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

संसाधन सर्वर समझता है कि ऐक्सेस टोकन, उपयोगकर्ता नाम और पासवर्ड जैसे क्रेडेंशियल के "बदले" इस्तेमाल किया जाता है. इसके अलावा, ऐक्सेस टोकन को पाबंदियों के साथ जारी किया जा सकता है, ताकि, उदाहरण के लिए, ऐप्लिकेशन, संसाधन सर्वर पर डेटा पढ़ सके, लेकिन उसे लिख या मिटा न सके. ध्यान दें कि ऐक्सेस टोकन को रद्द किया जा सकता है. उदाहरण के लिए, अगर ऐप्लिकेशन से समझौता किया गया हो. ऐसे में, ऐप्लिकेशन का इस्तेमाल जारी रखने के लिए, आपको नया ऐक्सेस टोकन पाना होगा. हालांकि, आपको सुरक्षित संसाधनों वाले सर्वर (उदाहरण के लिए, Facebook या Twitter) पर अपना उपयोगकर्ता नाम या पासवर्ड बदलने की ज़रूरत नहीं होगी.

आम तौर पर, ऐक्सेस टोकन की समयसीमा खत्म हो जाती है. ऐसा सुरक्षा की वजहों से होता है. अनुमति देने के लिए मिले अनुरोध के कुछ टाइप में, ऑथराइज़ेशन सर्वर, रीफ़्रेश टोकन जारी कर सकता है. इससे ऐप्लिकेशन को, पुराने टोकन की समयसीमा खत्म होने पर, नया ऐक्सेस टोकन पाने में मदद मिलती है. ऐक्सेस और रीफ़्रेश टोकन के बारे में ज़्यादा जानकारी के लिए, IETF OAuth 2.0 की खास जानकारी देखें.

दायरे के ज़रिए सीमित ऐक्सेस

OAuth 2.0, दायरों के मैकेनिज़्म के ज़रिए, किसी ऐप्लिकेशन को सुरक्षित संसाधनों का सीमित ऐक्सेस दे सकता है. उदाहरण के लिए, किसी ऐप्लिकेशन के पास सिर्फ़ खास संसाधनों का ऐक्सेस हो सकता है, वह संसाधनों को अपडेट कर सकता है या उसे सिर्फ़ रीड-ओनली ऐक्सेस दिया जा सकता है. तथाकथित "तीन चरणों वाले" OAuth फ़्लो में, उपयोगकर्ता आम तौर पर सहमति वाले पेज के ज़रिए, ऐक्सेस का लेवल तय करता है. उदाहरण के लिए, कोई वेब पेज जहां उपयोगकर्ता, चेकबॉक्स या अन्य मैकेनिज़्म की मदद से दायरा चुनता है.

किसी ऐप्लिकेशन को रजिस्टर करना

सभी क्लाइंट (ऐप्लिकेशन) को, OAuth 2.0 ऑथराइज़ेशन सर्वर के साथ रजिस्टर करना होगा. ये ऐप्लिकेशन, इस सर्वर से ऐक्सेस टोकन का अनुरोध करते हैं. किसी ऐप्लिकेशन को रजिस्टर करने पर, आपको पासकोड का एक सेट मिलता है. इनमें से एक, सार्वजनिक पासकोड होता है. इसे क्लाइंट आइडेंटिफ़ायर कहा जाता है. दूसरा, सीक्रेट पासकोड होता है. इसे क्लाइंट सीक्रेट कहा जाता है. इन पासकोड के बिना, कोई ऐप्लिकेशन, ऑथराइज़ेशन सर्वर को ऑथराइज़ेशन कोड या ऐक्सेस टोकन के लिए अनुरोध नहीं भेज सकता. ध्यान दें कि IETF OAuth की खास जानकारी में इन पासकोड को क्लाइंट आईडी और क्लाइंट सीक्रेट कहा जाता है. वहीं, Apigee Edge के यूज़र इंटरफ़ेस (यूआई) में इन्हें कंज्यूमर आईडी और कंज्यूमर सीक्रेट कहा जाता है. ये दोनों एक ही हैं.

OAuth 2.0 के इस्तेमाल के उदाहरणों की खास जानकारी

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

OAuth 2.0 की तुलना में, एपीआई पासकोड की सुरक्षा

एपीआई पासकोड की पुष्टि करने के लिए, किसी ऐप्लिकेशन को Edge पर एक पासकोड भेजना होता है. यह कुंजी, Apigee Edge के उस डेवलपर ऐप्लिकेशन की मान्य उपयोगकर्ता कुंजी होनी चाहिए जो एपीआई प्रॉक्सी से जुड़ा है. अगर किसी वजह से, आपको क्लाइंट ऐप्लिकेशन को प्रॉक्सी पर कॉल करने की अनुमति रद्द करनी है, तो आपको उस उपयोगकर्ता कुंजी को रद्द करना होगा. उस पासकोड का इस्तेमाल करने वाले सभी क्लाइंट ऐप्लिकेशन भी, एपीआई प्रॉक्सी को ऐक्सेस नहीं कर पाएंगे. दूसरी ओर, OAuth टोकन को किसी भी समय रद्द किया जा सकता है. इसके लिए, ऐप्लिकेशन के पासकोड रद्द करने की ज़रूरत नहीं होती. ऐप्लिकेशन उपयोगकर्ता की ओर से नया टोकन पाने का अनुरोध कर सकता है. अगर टोकन दिया जाता है, तो ऐप्लिकेशन एपीआई प्रॉक्सी का इस्तेमाल जारी रख सकता है.

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

एपीआई पासकोड की पुष्टि करने के बारे में ज़्यादा जानकारी के लिए, एपीआई पासकोड देखें. OAuth टोकन के साथ कस्टम एट्रिब्यूट इस्तेमाल करने के बारे में जानकारी के लिए, टोकन और ऑथराइज़ेशन कोड को पसंद के मुताबिक बनाना देखें.

सुझाए गए संसाधन

रीडिंग

OAuth 2.0 के बारे में जानें देखें.