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

Apigee Edge दस्तावेज़ देखा जा रहा है.
Apigee X दस्तावेज़ पर जाएं.
जानकारी

OAuth का होम पेज: हमने OAuth के लिए दिशा-निर्देश उपलब्ध कराए हैं, उन्हें टॉप-लेवल पर देखने के लिए, OAuth होम पेज देखें.

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

OAuth 2.0 क्या है?

OAuth 2.0 के लिए कई किताबें, ब्लॉग, और साइटें इस्तेमाल की जा रही हैं. हमारा सुझाव है कि आप आईईटीएफ़ 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 जैसी सेवा या अपने इंट्रानेट पर HR सेवा; या अपने 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 के साथ अपने ऐप्लिकेशन रजिस्टर करके शुरू करते हैं. रजिस्टर किए गए ऐप्लिकेशन, चार मंज़ूरी टाइप में से किसी भी इंटरैक्शन के ज़रिए, ऐक्सेस टोकन का अनुरोध कर सकते हैं.

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

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

OAuth 2.0 के तहत मिले अनुदान के टाइप क्या हैं?

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

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

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

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

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

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

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

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

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

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

स्कोप के ज़रिए सीमित ऐक्सेस देना

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

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

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

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

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

इस्तेमाल का उदाहरण विश्वसनीयता सुझाए गए OAuth 2.0 ऑथराइज़ेशन अनुदान टाइप ब्यौरा
B2B (अतिरिक्त), इंट्रानेट, अन्य

बेहद भरोसेमंद ऐप्लिकेशन, जिन्हें इंटरनल डेवलपर या डेवलपर ने तैयार किया हो. साथ ही, एपीआई की सेवा देने वाली कंपनी के साथ उनका कारोबारी संबंध हो.

ऐसे ऐप्लिकेशन जिन्हें अपनी ओर से संसाधन ऐक्सेस करने की ज़रूरत होती है.

  • क्लाइंट के क्रेडेंशियल
  • आम तौर पर, ऐप्लिकेशन, संसाधन का मालिक भी होता है
  • Client-ID और क्लाइंट सीक्रेट कुंजियां ज़रूरी हैं
  • ऐप्लिकेशन को सेवा देने वाली कंपनी के साथ रजिस्टर होना ज़रूरी है
इंट्रानेट साइटें, पोर्टल

ऐसे ऐप्लिकेशन जिन्हें इंटरनल या भरोसेमंद तीसरे पक्ष के डेवलपर ने तैयार किया हो.

इसका एक अच्छा उदाहरण यह है कि बीमा के विकल्प चुनने, समीक्षाएं सबमिट करने या निजी जानकारी बदलने के लिए, अपनी कंपनी की HR साइट में लॉग इन करें.

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

OAuth 2.0 बनाम एपीआई पासकोड सुरक्षा

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

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

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

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

टेक्स्ट पढ़े जाने से जुड़े कंट्रोल

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