Google डेटा प्रोटोकॉल में पुष्टि करना और अनुमति देना

चेतावनी: यह पेज, Google के पुराने एपीआई, Google Data API के बारे में है. यह सिर्फ़ उन एपीआई के लिए काम का है जो Google Data API डायरेक्ट्री में शामिल हैं. इनमें से कई एपीआई को नए एपीआई से बदल दिया गया है. किसी नए एपीआई के बारे में जानकारी पाने के लिए, उस एपीआई का दस्तावेज़ देखें. नए एपीआई की मदद से अनुरोधों को अनुमति देने के बारे में जानकारी पाने के लिए, Google खातों के लिए पुष्टि करने और अनुमति देने की सुविधा लेख पढ़ें.

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

पुष्टि करने वाली सेवाओं की मदद से, उपयोगकर्ता Google खाते का इस्तेमाल करके आपके ऐप्लिकेशन में साइन इन कर सकते हैं.

अनुमति देने वाली सेवाओं की मदद से, लोग आपके ऐप्लिकेशन को Google ऐप्लिकेशन में सेव किए गए डेटा का ऐक्सेस दे सकते हैं. Google, निजता को गंभीरता से लेता है. इसलिए, किसी भी ऐप्लिकेशन को उपयोगकर्ता के डेटा का ऐक्सेस पाने के लिए, उपयोगकर्ता से अनुमति लेनी होगी.

पुष्टि करने और अनुमति देने वाली सेवाओं को अक्सर एक साथ auth कहा जाता है.

Google API के लिए पुष्टि करने और अनुमति देने की सुविधा की मदद से, तीसरे पक्ष के ऐप्लिकेशन को किसी उपयोगकर्ता के Google खाते का सीमित ऐक्सेस मिलता है. इससे वे कुछ तरह की गतिविधियां कर पाते हैं. इस दस्तावेज़ में, पुष्टि करने के लिए उपलब्ध तरीकों के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि इनमें से हर तरीका, आपके ऐप्लिकेशन के लिए क्या-क्या उपलब्ध कराता है.

Google साइन-इन की सुविधा, लोगों को अपनी साइट पर साइन इन करने के लिए, Google क्रेडेंशियल इस्तेमाल करने का आसान तरीका उपलब्ध कराती है. इसमें टूल का एक सेट शामिल होता है, जिसे अलग-अलग डिवाइसों पर आसानी से इंटिग्रेट किया जा सकता है.
OAuth 2.0, सभी Google API के लिए ऑथराइज़ेशन प्रोटोकॉल है. OAuth 2.0, सुरक्षा के लिए SSL पर निर्भर करता है. इसके लिए, आपके ऐप्लिकेशन को सीधे तौर पर क्रिप्टोग्राफ़िक हस्ताक्षर करने की ज़रूरत नहीं होती. इस प्रोटोकॉल की मदद से, आपका ऐप्लिकेशन किसी उपयोगकर्ता के Google खाते से जुड़े डेटा को ऐक्सेस करने का अनुरोध कर सकता है.
OAuth 2.0 की मदद से लॉगिन करें (OpenID Connect) सुविधा, उपयोगकर्ताओं को उनके Google खातों से लॉगिन करने की अनुमति देकर उनकी पुष्टि करती है. यह OpenID की जगह इस्तेमाल किया जा सकता है. OpenID का इस्तेमाल करने वाले लोगों को, OAuth 2.0 की मदद से लॉगिन करने की सुविधा पर माइग्रेट करने की योजना बनानी चाहिए.

अगर आपका ऐप्लिकेशन कोई गैजेट है (iGoogle या अन्य OpenSocial कंटेनर में इस्तेमाल के लिए), तो गैजेट के लिए पुष्टि करने की सुविधा सेक्शन देखें.

ध्यान दें: इस दस्तावेज़ का मकसद, पुष्टि करने के हर तरीके के बारे में खास जानकारी देना है. हर तरीके के बारे में ज़्यादा जानकारी पाने के लिए, Google खाते की पुष्टि करने वाले एपीआई का पूरा दस्तावेज़ देखें.

Google खातों से जुड़े एपीआई इस्तेमाल करने के बारे में चर्चा करने के लिए, Google Accounts API Group भी देखें.

OAuth - वेब और इंस्टॉल किए गए ऐप्लिकेशन के लिए अनुमति

Google की कई सेवाएं, तीसरे पक्ष को यूज़र जनरेटेड डेटा का ऐक्सेस देती हैं. जैसे, Calendar या Documents का डेटा. हालांकि, ऐसा तब तक ही किया जाता है, जब तक उपयोगकर्ता ने ऐक्सेस करने की अनुमति न दी हो. इस सुविधा की मदद से, उपयोगकर्ता अपने Google ऐप्लिकेशन और तीसरे पक्ष के ऐप्लिकेशन के बीच डेटा शेयर और ट्रांसफ़र कर सकते हैं. ऐसा कई कामों के लिए किया जा सकता है.

Google, किसी उपयोगकर्ता के Google डेटा का ऐक्सेस पाने के लिए, OAuth के दो वर्शन का इस्तेमाल करता है: OAuth 1.0 और OAuth 2.0. ये दोनों वर्शन, वेब ऐप्लिकेशन और इंस्टॉल किए गए ऐप्लिकेशन, दोनों का ऐक्सेस देते हैं.

वेब और इंस्टॉल किए गए ऐप्लिकेशन के लिए OAuth 2.0

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

वेब ऐप्लिकेशन के लिए OAuth 1.0

जिन वेब ऐप्लिकेशन को Google खाते या Google Apps खाते से जुड़े डेटा को ऐक्सेस करने की अनुमति चाहिए वे OAuth API के Google वर्शन का इस्तेमाल कर सकते हैं. वेब पर काम करने वाले ऐप्लिकेशन के लिए OAuth लागू करने के बारे में पूरी जानकारी पाने के लिए, वेब ऐप्लिकेशन के लिए OAuth गाइड देखें. इसमें उदाहरण भी शामिल हैं. इसके अलावा, इस दस्तावेज़ में खास जानकारी देखें.

इंस्टॉल किए गए ऐप्लिकेशन के लिए OAuth 1.0

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

वेब ऐप्लिकेशन के साथ OAuth का इस्तेमाल करना

सभी Google Data API, OAuth के साथ काम करते हैं. यह एक ओपन स्टैंडर्ड है. इसका इस्तेमाल, वेब ऐप्लिकेशन में डेटा के इस्तेमाल को अनुमति देने के लिए किया जाता है. OAuth अनुरोध करने वाले सभी वेब ऐप्लिकेशन को सुरक्षा सर्टिफ़िकेट अपलोड करना होगा. साथ ही, उन्हें Google के साथ रजिस्टर करना होगा. ज़्यादा जानकारी के लिए, वेब पर आधारित ऐप्लिकेशन के लिए रजिस्ट्रेशन देखें.

Google Data APIs की क्लाइंट लाइब्रेरी, आपके वेब ऐप्लिकेशन में OAuth का इस्तेमाल करने के तरीके बताती हैं. खास तौर पर, अनुरोध टोकन बनाने, अनुरोध टोकन को अनुमति देने, और अनुमति वाले अनुरोध टोकन को ऐक्सेस टोकन के लिए बदलने के तरीके हैं. Google की डेटा सेवा से अनुरोध करते समय, ये लाइब्रेरी ज़रूरी हस्ताक्षर करने वाले एल्गोरिदम को भी मैनेज करती हैं. Google Data API क्लाइंट लाइब्रेरी के साथ OAuth का इस्तेमाल करने के बारे में ज़्यादा जानकारी के लिए,Google Data API क्लाइंट लाइब्रेरी के साथ OAuth का इस्तेमाल करना लेख पढ़ें.

OAuth की अनुमति देने की प्रोसेस

OAuth ऑथराइज़ेशन प्रोसेस में, आपके वेब ऐप्लिकेशन, Google के ऑथराइज़ेशन सर्वर, और असली उपयोगकर्ता के बीच कई तरह की बातचीत होती है.

बेसिक लेवल पर, यह प्रोसेस इस तरह होती है:

आपका ऐप्लिकेशन, ऐक्सेस करने का अनुरोध करता है. साथ ही, Google के ऑथराइज़ेशन सर्वर से बिना अनुमति वाला अनुरोध टोकन पाता है.
Google, उपयोगकर्ता से ज़रूरी डेटा को ऐक्सेस करने की अनुमति मांगता है.
आपके ऐप्लिकेशन को ऑथराइज़ेशन सर्वर से, अनुमति वाला अनुरोध टोकन मिलता है.
आपको ऑथराइज़ किए गए अनुरोध टोकन के बदले ऐक्सेस टोकन मिलता है.
Google की सेवा के ऐक्सेस सर्वर से डेटा का अनुरोध करने के लिए, ऐक्सेस टोकन का इस्तेमाल किया जाता है.

जब आपका ऐप्लिकेशन पहली बार किसी उपयोगकर्ता के डेटा को ऐक्सेस करने का अनुरोध करता है, तब Google आपके ऐप्लिकेशन को एक अनधिकृत अनुरोध टोकन जारी करता है.

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

अगर उपयोगकर्ता, आपके ऐप्लिकेशन के ऐक्सेस के अनुरोध को स्वीकार करता है, तो Google एक मान्य अनुरोध टोकन जारी करता है. हर अनुरोध टोकन सिर्फ़ एक घंटे के लिए मान्य होता है. सिर्फ़ अनुमति वाले अनुरोध टोकन को ऐक्सेस टोकन के लिए बदला जा सकता है. साथ ही, अनुमति वाले हर अनुरोध टोकन के लिए, यह बदलाव सिर्फ़ एक बार किया जा सकता है.

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

OAuth के लिए तैयारी करना

OAuth के साथ Google की अनुमति देने वाली सेवा का इस्तेमाल करने के लिए, अपने ऐप्लिकेशन को सेट अप करने से पहले, आपको ये टास्क पूरे करने होंगे.

यह तय करना कि आपको अपने वेब ऐप्लिकेशन को रजिस्टर करना है या नहीं

अपने उपयोगकर्ताओं को उनके डेटा की सुरक्षा के बारे में ज़्यादा भरोसा दिलाने के लिए, अपने वेब ऐप्लिकेशन को Google के साथ रजिस्टर किया जा सकता है. साथ ही, रजिस्टर किए गए सुरक्षा सर्टिफ़िकेट से अपने अनुरोधों पर हस्ताक्षर किए जा सकते हैं. Google Data API के कुछ फ़ीड, सिर्फ़ रजिस्टर किए गए ऐप्लिकेशन के लिए उपलब्ध हैं. आपको जिस Google Data API के बारे में जानना है उसके दस्तावेज़ देखें. इससे यह पता चलेगा कि वह एपीआई सिर्फ़ रजिस्टर किए गए ऐप्लिकेशन के साथ काम करता है या नहीं.

आपके ऐप्लिकेशन को, OAuth के हर अनुरोध पर हस्ताक्षर करना होगा. अगर आपको अपने अनुरोधों पर हस्ताक्षर करने के लिए, RSA-SHA1 हस्ताक्षर का इस्तेमाल करना है, तो आपको रजिस्ट्रेशन की प्रोसेस के दौरान सुरक्षा सर्टिफ़िकेट अपलोड करना होगा.

इसके अलावा, अपने अनुरोधों पर हस्ताक्षर करने के लिए, एचएमएसी-एसएचए1 हस्ताक्षर का इस्तेमाल किया जा सकता है. HMAC-SHA1 सिग्नेचर के लिए, किसी सर्टिफ़िकेट की ज़रूरत नहीं होती. इसके बजाय, Google एक OAuth consumer secret वैल्यू जनरेट करता है. यह वैल्यू, रजिस्टर करने के बाद आपके डोमेन के रजिस्ट्रेशन पेज पर दिखती है.

रजिस्ट्रेशन की प्रोसेस के बारे में ज़्यादा जानने के लिए, वेब ऐप्लिकेशन के लिए रजिस्ट्रेशन लेख पढ़ें.

यह तय करना कि आपका ऐप्लिकेशन किस तरह का डेटा ऐक्सेस करेगा

Google की हर सेवा, Google Data API के ज़रिए ऐक्सेस करने की सीमाएं तय करती है. इस ऐक्सेस को स्कोप वैल्यू के तौर पर दिखाया जाता है. कुछ सेवाएं, स्कोप की अलग-अलग वैल्यू उपलब्ध कराती हैं. इससे उपयोगकर्ता यह चुन सकता है कि किन ऐप्लिकेशन के पास किस डेटा का ऐक्सेस होना चाहिए. आपको जिस Google सेवा को ऐक्सेस करना है उसके लिए, उपलब्ध स्कोप की वैल्यू के बारे में जानने के लिए, उस सेवा का दस्तावेज़ देखें.

आम तौर पर, आपको उस स्कोप के लिए टोकन का अनुरोध करना चाहिए जिसमें आपको ज़रूरी डेटा मिल जाए. उदाहरण के लिए, अगर आपके ऐप्लिकेशन को उपयोगकर्ता के "सभी कैलेंडर" फ़ीड को ऐक्सेस करने की ज़रूरत है, तो आपको http://www.google.com/calendar/feeds/default/allcalendars/full स्कोप के लिए टोकन का अनुरोध करना चाहिए.

OAuth टोकन मैनेज करने के लिए कोई तरीका सेट अप करना

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

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

अगर आपका ऐप्लिकेशन एक से ज़्यादा उपयोगकर्ता खातों के साथ काम करता है, तो आपको यह ट्रैक करना होगा कि हर टोकन किस खाते से जुड़ा है. हर OAuth टोकन, उस उपयोगकर्ता के लिए होता है जिसने ऐक्सेस की अनुमति दी है. आपका ऐप्लिकेशन, टोकन को सही उपयोगकर्ता से जोड़ सके. इसे मैनेज करने का एक तरीका यह है कि टोकन का अनुरोध करने से पहले, उपयोगकर्ता को कुकी जारी की जाए. जब उपयोगकर्ता, अनुरोध किए गए डेटा को ऐक्सेस करने की अनुमति देता है, तब Google एक मान्य अनुरोध टोकन भेजता है. साथ ही, उपयोगकर्ता को आपके ऐप्लिकेशन पर रीडायरेक्ट कर देता है. इसके बाद, अपने ऐप्लिकेशन की कुकी का इस्तेमाल करके, टोकन को सही उपयोगकर्ता से जोड़ा जा सकता है.

Google की किसी सेवा का ऐक्सेस पाने के लिए अनुरोध करने का तरीका सेट अप करना

Google की किसी भी सेवा के लिए किए गए हर अनुरोध पर हस्ताक्षर होना चाहिए. साथ ही, उसमें मान्य OAuth ऐक्सेस टोकन शामिल होना चाहिए. आम तौर पर, हर अनुरोध को एचटीटीपी GET अनुरोध के तौर पर किया जाता है. इसमें हेडर में ऐक्सेस टोकन और हस्ताक्षर शामिल होता है. नया डेटा लिखने वाले अनुरोधों के लिए, एचटीटीपी पोस्ट का इस्तेमाल करना चाहिए.

हर Google Data API के लिए, अनुरोध के सही फ़ॉर्मैट के बारे में ज़्यादा जानने के लिए, उस एपीआई से जुड़ा दस्तावेज़ देखें.

OpenID लागू करना (ज़रूरी नहीं)

अगर आपको उपयोगकर्ता की पुष्टि करने के लिए OpenID लागू करना है, तो दोनों प्रोसेस को एक साथ करने के लिए हाइब्रिड प्रोटोकॉल का इस्तेमाल करें. OpenID+OAuth की मदद से, अनुरोध टोकन पाने और उसे अनुमति देने के टास्क को OpenID अनुरोध के तौर पर हैंडल किया जाता है. इसमें OAuth एक्सटेंशन का इस्तेमाल किया जाता है. OAuthGetRequestToken की तरह, इन एक्सटेंशन का इस्तेमाल, उन Google सेवाओं की पहचान करने के लिए किया जाता है जिन्हें ऐक्सेस करना है. OpenID के अनुरोध के पूरा होने पर, जवाब में अनुमति दिया गया अनुरोध टोकन शामिल होता है. यह टोकन मिलने के बाद, इसे ऐक्सेस टोकन के लिए बदलने के लिए OAuthGetAccessToken का इस्तेमाल करें.

OAuth टोकन का इस्तेमाल करना

OAuth का इस्तेमाल करने के लिए, आपके ऐप्लिकेशन को सही फ़ॉर्मैट में हस्ताक्षर किए गए टोकन के अनुरोध वाले कॉल जनरेट करने होंगे. साथ ही, इस क्रम के लिए जवाबों को मैनेज करना होगा:

बिना अनुमति वाला अनुरोध टोकन (OAuthGetRequestToken) पाना
अनुरोध टोकन (OAuthAuthorizeToken) को अनुमति दें
अनुमति वाले अनुरोध टोकन को ऐक्सेस टोकन (OAuthGetAccessToken) के लिए एक्सचेंज करना

सभी OAuth अनुरोधों पर हस्ताक्षर होना ज़रूरी है. भले ही, आपका ऐप्लिकेशन रजिस्टर किया गया हो या नहीं. ज़्यादा जानकारी के लिए, OAuth अनुरोधों पर हस्ताक्षर करना लेख पढ़ें.

OAuth Playground में, अनुमति देने वाले टोकन का अनुरोध करने और उन्हें पाने का तरीका आज़माया जा सकता है.

ज़्यादा जानकारी के लिए, OAuth API का रेफ़रंस देखें.

कॉलबैक यूआरएल सेट करना

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

उदाहरण के लिए, एक से ज़्यादा भाषाओं के लिए सहायता उपलब्ध कराते समय, क्वेरी पैरामीटर शामिल किया जा सकता है. इससे यह पता चलता है कि उपयोगकर्ता ऐप्लिकेशन का कौनसा वर्शन देख रहा है. oauth_callback की वैल्यू "http://www.yoursite.com/Retrievetoken?Lang=de" होने पर, रीडायरेक्ट "http://www.yoursite.com/Retrievetoken?Lang=de&oauth_token=DQAADKEDE" पर होगा. टोकन और भाषा के पैरामीटर को पार्स करने से यह पक्का किया जाता है कि उपयोगकर्ता को साइट के सही वर्शन पर वापस रीडायरेक्ट किया गया है.

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

उपयोगकर्ताओं को अपने ऐप्लिकेशन की पहचान बताना

आम तौर पर, Google उपयोगकर्ता से ऐक्सेस करने की सहमति मांगते समय, ऐप्लिकेशन का नाम दिखाता है (उदाहरण देखें).

अगर आपका ऐप्लिकेशन रजिस्टर नहीं है, तो अपने OAuthGetRequestToken अनुरोध में xoauth_displayname पैरामीटर का इस्तेमाल करके, अपने ऐप्लिकेशन का नाम बताएं. अगर इस पैरामीटर की वैल्यू नहीं दी जाती है, तो Google, oauth_callback पैरामीटर से मिले यूआरएल का डोमेन नेम दिखाता है. अगर कोई कॉलबैक यूआरएल नहीं दिया जाता है, तो Google "anonymous" स्ट्रिंग दिखाता है.

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

ध्यान दें: OAuth Playground में xoauth_displayname पैरामीटर सेट करने के लिए, अनुरोध टोकन फ़ेच करने से पहले "ऐडवांस" बॉक्स पर सही का निशान लगाएं.

Google Apps डोमेन के साथ काम करना

अगर आपका ऐप्लिकेशन, Google के होस्ट किए गए खातों के डोमेन पर मौजूद उपयोगकर्ताओं के लिए डिज़ाइन किया गया है, तो टोकन को अनुमति देते समय hd पैरामीटर का इस्तेमाल करें. hd पैरामीटर के बारे में ज़्यादा जानने के लिए, एक से ज़्यादा खातों वाले लोगों को मैनेज करना लेख पढ़ें.

OAuth के बारे में ज़्यादा जानकारी

Google के OAuth को लागू करने के तरीके के बारे में ज़्यादा जानकारी के लिए, ये अतिरिक्त संसाधन देखें. इनमें, ऐप्लिकेशन रजिस्टर करने और OAuth के ज़रूरी पैरामीटर बनाने का तरीका भी शामिल है:

Google Data APIs क्लाइंट लाइब्रेरी के साथ OAuth का इस्तेमाल करना
लेख: Google Data API के साथ OAuth का इस्तेमाल करना. इसमें OAuth Playground के बारे में जानकारी भी शामिल है. यह OAuth को आज़माने के लिए एक इंटरैक्टिव टूल है.
वेब ऐप्लिकेशन के लिए OAuth (पूरा दस्तावेज़)
वेब पर काम करने वाले ऐप्लिकेशन के लिए रजिस्ट्रेशन
कुंजियां और सर्टिफ़िकेट जनरेट करना
OAuth स्पेसिफ़िकेशन

वापस सबसे ऊपर जाएं

इंस्टॉल किए गए ऐप्लिकेशन के साथ OAuth का इस्तेमाल करना

सभी Google Data API, OAuth के साथ काम करते हैं. यह एक ओपन स्टैंडर्ड है. इसका इस्तेमाल, ऐप्लिकेशन में डेटा के इस्तेमाल की अनुमति देने के लिए किया जाता है. OAuth का इस्तेमाल करने के लिए, इंस्टॉल किए गए ऐप्लिकेशन को Google के साथ रजिस्टर करने की ज़रूरत नहीं होती.

OAuth की अनुमति देने की प्रोसेस

OAuth ऑथराइज़ेशन प्रोसेस में, आपके ऐप्लिकेशन, Google के ऑथराइज़ेशन सर्वर, और असली उपयोगकर्ता के बीच कई तरह की कार्रवाइयां शामिल होती हैं.

बेसिक लेवल पर, यह प्रोसेस इस तरह होती है:

आपका ऐप्लिकेशन, ऐक्सेस करने का अनुरोध करता है. साथ ही, Google के ऑथराइज़ेशन सर्वर से बिना अनुमति वाला अनुरोध टोकन पाता है.
Google, उपयोगकर्ता से ज़रूरी डेटा को ऐक्सेस करने की अनुमति मांगता है.
आपके ऐप्लिकेशन को ऑथराइज़ेशन सर्वर से, अनुमति वाला अनुरोध टोकन मिलता है.
आपको ऑथराइज़ किए गए अनुरोध टोकन के बदले ऐक्सेस टोकन मिलता है.
Google की सेवा के ऐक्सेस सर्वर से डेटा का अनुरोध करने के लिए, ऐक्सेस टोकन का इस्तेमाल किया जाता है.

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

OAuth के लिए तैयारी करना

यह तय करना कि आपका ऐप्लिकेशन किस तरह का डेटा ऐक्सेस करेगा

OAuth टोकन मैनेज करने के लिए कोई तरीका सेट अप करना

आपके ऐप्लिकेशन को टोकन स्टोरेज को सुरक्षित तरीके से मैनेज करना चाहिए. इसमें यह ट्रैक करना भी शामिल है कि हर टोकन, Google की किस सेवा के लिए मान्य है.

अगर आपका ऐप्लिकेशन एक से ज़्यादा उपयोगकर्ता खातों के साथ काम करता है, तो आपको यह ट्रैक करना होगा कि हर टोकन किस खाते से जुड़ा है.

Google की किसी सेवा का ऐक्सेस पाने के लिए अनुरोध करने का तरीका सेट अप करना

OAuth टोकन का इस्तेमाल करना

बिना अनुमति वाला अनुरोध टोकन (OAuthGetRequestToken) पाना
अनुरोध टोकन (OAuthAuthorizeToken) को अनुमति दें
अनुमति वाले अनुरोध टोकन को ऐक्सेस टोकन (OAuthGetAccessToken) के लिए एक्सचेंज करना

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

ज़्यादा जानकारी के लिए, OAuth API का रेफ़रंस देखें.

उपयोगकर्ताओं को अपने ऐप्लिकेशन की पहचान बताना

अपने ऐप्लिकेशन का नाम बताने के लिए, OAuthGetRequestToken अनुरोध में xoauth_displayname पैरामीटर का इस्तेमाल करें. अगर इस पैरामीटर की वैल्यू नहीं दी जाती है, तो Google, oauth_callback पैरामीटर से मिले यूआरएल का डोमेन नेम दिखाता है. अगर कोई कॉलबैक यूआरएल नहीं दिया जाता है, तो Google "anonymous" स्ट्रिंग दिखाता है.

वेब ब्राउज़र लॉन्च करना

OAuth ऑथराइज़ेशन की प्रोसेस के तहत, आपके ऐप्लिकेशन को OAuthAuthorizeToken अनुरोध करना होगा. इसके बाद, उपयोगकर्ता को Google के वेब पेज पर लॉग इन करना होगा. साथ ही, आपके ऐप्लिकेशन के ऐक्सेस के अनुरोध को अनुमति देनी होगी.

ज़्यादातर ऐप्लिकेशन के लिए, AutoDetect मोड का इस्तेमाल किया जाना चाहिए
डिवाइस मोड का इस्तेमाल उन ऐप्लिकेशन के लिए किया जाना चाहिए जो फ़ुल वेब ब्राउज़र लॉन्च नहीं कर सकते.
डेवलपमेंट मोड का इस्तेमाल सिर्फ़ शुरुआती डेवलपमेंट के दौरान किया जाना चाहिए.

AutoDetect मोड

अगर हो सके, तो आपका ऐप्लिकेशन एक ब्राउज़र विंडो लॉन्च करे और Google पेज खोलने के लिए OAuthAuthorizeToken अनुरोध करे. जब Google, अनुमति वाला टोकन वापस भेजता है, तो आपके ऐप्लिकेशन को इसका पता चलना चाहिए. साथ ही, उसे वेब ब्राउज़र से फ़ोकस वापस मिल जाना चाहिए.

इस मोड के लिए, आपको एक कॉलबैक यूआरएल देना होगा. इस यूआरएल पर उपयोगकर्ता को रीडायरेक्ट किया जाता है. ऐसा तब होता है, जब वह ऐक्सेस के आपके अनुरोध को अनुमति दे देता है. यह यूआरएल, OAuthGetRequestToken अनुरोध के oauth_callback पैरामीटर के तौर पर और OAuthGetAccessToken अनुरोध के verifier पैरामीटर के तौर पर दिया जाना चाहिए.

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

ज़्यादा जानकारी और सबसे सही तरीकों के लिए, अपने-आप मंज़ूरी का पता लगाने की सुविधा देखें.

अगर आपका ऐप्लिकेशन, उपयोगकर्ता को कॉलबैक यूआरएल पर रीडायरेक्ट किए जाने का पता अपने-आप नहीं लगा पाता है या फ़ोरग्राउंड में नहीं आ पाता है, तो कॉलबैक यूआरएल को एक ऐसा पेज दिखाना चाहिए जिसमें यह बताया गया हो कि आपके ऐप्लिकेशन को फ़ोरग्राउंड में कैसे लाया जाए. साथ ही, आपके ऐप्लिकेशन से OAuthGetAccessToken अनुरोध कैसे शुरू किया जाए.

डिवाइस मोड

अगर आपका ऐप्लिकेशन, वेब ब्राउज़र को पूरी तरह से लॉन्च नहीं कर सकता, तो रिच-क्लाइंट डिवाइसों के लिए वेब ब्राउज़र के बिना भी पुष्टि करना मुमकिन है.

इस मोड की मदद से डेवलपर, ऐसी वेबसाइट सेट अप कर सकता है जहां उपयोगकर्ता, ऐक्सेस के अनुरोध को अनुमति दे सकता है. अनुमति मिलने के बाद, उपयोगकर्ता को Google की ओर से जनरेट किया गया कोड दिया जाता है. साथ ही, उसे डेवलपर की साइट पर रीडायरेक्ट कर दिया जाता है. इस साइट पर, उपयोगकर्ता को यह बताया जाना चाहिए कि पुष्टि करने की प्रोसेस पूरी करने के लिए, उसे अपने डिवाइस में कोड कैसे डालना है.

डेवलपमेंट मोड

इस मोड का इस्तेमाल, सिर्फ़ ऐप्लिकेशन को शुरुआती तौर पर डेवलप करने के दौरान किया जाना चाहिए.

AutoDetect मोड की तरह ही, आपके ऐप्लिकेशन को ब्राउज़र लॉन्च करना होगा. साथ ही, उपयोगकर्ता को आपके अनुरोध को अनुमति देनी होगी. हालांकि, कॉलबैक यूआरएल के लिए वेबपेज बनाने के बजाय, oauth_callback पैरामीटर की वैल्यू को "oob" (आउट ऑफ़ बैंड) पर सेट किया जा सकता है.

ऐसे में, जब उपयोगकर्ता आपके अनुरोध को अनुमति दे देता है, तो Google उसे Google खातों वाले पेज पर भेज देता है. इस पेज पर पुष्टि करने वाला नंबर दिखता है (उदाहरण देखें).

OAuthGetAccessToken का अनुरोध करने से पहले, उपयोगकर्ता को आपके ऐप्लिकेशन पर वापस जाना होगा और पुष्टि करने वाला नंबर डालना होगा.

OAuth के बारे में ज़्यादा जानकारी

Google Data APIs क्लाइंट लाइब्रेरी के साथ OAuth का इस्तेमाल करना
लेख: Google Data API के साथ OAuth का इस्तेमाल करना. इसमें OAuth Playground के बारे में जानकारी भी शामिल है. यह OAuth को आज़माने के लिए एक इंटरैक्टिव टूल है.
इंस्टॉल किए गए ऐप्लिकेशन के लिए OAuth (पूरा दस्तावेज़)
कुंजियां और सर्टिफ़िकेट जनरेट करना
OAuth स्पेसिफ़िकेशन

वापस सबसे ऊपर जाएं

अनुमति देने के लिए AuthSub का इस्तेमाल करना

AuthSub, Google का मालिकाना हक वाला एक ऑथराइज़ेशन एपीआई है. यह ज़्यादातर Google API के लिए, OAuth के विकल्प के तौर पर उपलब्ध है. अगर हो सके, तो आपको AuthSub का इस्तेमाल नहीं करना चाहिए. अगर आपके पास पहले से ऐसे ऐप्लिकेशन हैं जो AuthSub का इस्तेमाल करते हैं, तो आपको OAuth या हाइब्रिड प्रोटोकॉल पर माइग्रेट करना चाहिए.

AuthSub की अनुमति देने की प्रोसेस

AuthSub के साथ अनुमति देने की प्रोसेस में, तीन इकाइयों के बीच इंटरैक्शन की एक सीरीज़ शामिल होती है: वेब ऐप्लिकेशन, Google की सेवाएं, और उपयोगकर्ता. इस डायग्राम में क्रम दिखाया गया है:

पुष्टि करने की प्रोसेस

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

AuthSub का इस्तेमाल करना

अपने वेब ऐप्लिकेशन में AuthSub को शामिल करने के लिए, ये काम करने होंगे:

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

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

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

इसके अलावा, टोकन रद्द करने का तरीका सेट अप करने पर, आपको नियमित तौर पर नए टोकन मिल सकते हैं. किसी दूसरे टोकन का अनुरोध करने से पहले, आपके ऐप्लिकेशन को मौजूदा टोकन रद्द करना होगा. इस स्थिति में, उपयोगकर्ता को हर बार लॉग इन करना होगा और नया टोकन पाने के लिए ऐक्सेस देना होगा.
यह तय करें कि Google की सेवा को ऐक्सेस करने के लिए, किस स्कोप की ज़रूरत है.
Google की हर सेवा यह तय करती है कि वह कितना और किस तरह का ऐक्सेस देगी. इस ऐक्सेस को स्कोप वैल्यू के तौर पर दिखाया जाता है. किसी सेवा का स्कोप, पूरी सेवा की पहचान करने वाला एक सामान्य यूआरएल हो सकता है. इसके अलावा, यह ज़्यादा प्रतिबंधित ऐक्सेस के बारे में भी बता सकता है. कुछ सेवाएं, ऐक्सेस को काफ़ी हद तक सीमित कर देती हैं. जैसे, सीमित जानकारी को सिर्फ़ पढ़ने का ऐक्सेस देना. आपको जिस Google सेवा को ऐक्सेस करना है उसके लिए अनुमति वाले स्कोप पाने के लिए, उस सेवा के दस्तावेज़ देखें. आपको सबसे कम स्कोप वाले टोकन का अनुरोध करना चाहिए. उदाहरण के लिए, अगर Gmail की ऐटम फ़ीड सुविधा को ऐक्सेस करने की कोशिश की जा रही है, तो "http://www.google.com/calendar/" के बजाय "http://www.google.com/calendar/feeds/" स्कोप का इस्तेमाल करें. Google की सेवाएं, बड़े स्कोप वाले अनुरोधों के लिए ज़्यादा पाबंदियां लगाती हैं.
अनुमति टोकन का अनुरोध करने और उसे पाने के लिए, एक सिस्टम सेट अप करें.
इस तरीके से, सही फ़ॉर्मैट में AuthSubRequest कॉल जनरेट होना चाहिए. इसमें next और scope यूआरएल की सही वैल्यू (तीसरे चरण में तय की गई) शामिल होनी चाहिए. अगर सुरक्षित टोकन का इस्तेमाल किया जा रहा है और/या सेशन टोकन मैनेज किए जा रहे हैं, तो अनुरोध में इन वैरिएबल की वैल्यू भी शामिल होनी चाहिए.

अगले यूआरएल में क्वेरी पैरामीटर शामिल किए जा सकते हैं. उदाहरण के लिए, एक से ज़्यादा भाषाओं के लिए सहायता उपलब्ध कराते समय, एक क्वेरी पैरामीटर शामिल करें. इससे यह पता चलता है कि उपयोगकर्ता वेब ऐप्लिकेशन का कौनसा वर्शन देख रहा है. next एट्रिब्यूट की वैल्यू http://www.yoursite.com/Retrievetoken?Lang=de होने पर, रीडायरेक्ट http://www.yoursite.com/Retrievetoken?Lang=de&token=DQAADKEDE होगा. टोकन और Lang पैरामीटर को पार्स करने से यह पक्का होता है कि उपयोगकर्ता को साइट के सही वर्शन पर वापस रीडायरेक्ट किया गया है.

कुछ मामलों में, hd पैरामीटर का इस्तेमाल करने से, उपयोगकर्ताओं को Google खातों की साइट पर ऐक्सेस देने के लिए कहा जाने पर, उन्हें बेहतर अनुभव मिल सकता है. ज़्यादातर मामलों में, उन्हें सिर्फ़ अपने खाते में लॉग इन करना होता है. इसके बाद, वे यह चुन सकते हैं कि ऐक्सेस देना है या नहीं. हालांकि, जिन लोगों के पास एक से ज़्यादा Google खाते हैं (जैसे, सामान्य Gmail खाता और/या एक या उससे ज़्यादा Google Apps होस्ट किए गए खाते), उन्हें "यूनिवर्सल लॉगिन" की अतिरिक्त प्रोसेस पूरी करनी पड़ सकती है. इससे यह तय किया जा सकेगा कि उन्हें किस खाते से ऐक्सेस करना है. अगर आपका ऐप्लिकेशन किसी एक मैनेज किए जा रहे डोमेन के लिए डिज़ाइन किया गया है, तो उस डोमेन की पहचान करने के लिए इस पैरामीटर का इस्तेमाल करें. इससे आपको ये अतिरिक्त चरण पूरे नहीं करने पड़ेंगे. अगर आपका ऐप्लिकेशन, होस्ट किए गए खातों पर उपलब्ध न होने वाली सेवाओं को ऐक्सेस करता है, तो hd पैरामीटर का इस्तेमाल भी किया जा सकता है. इसकी वैल्यू को 'default' पर सेट करने से, अनुमति सिर्फ़ सामान्य खातों को मिलेगी. hd वैल्यू सेट होने पर, Google पुष्टि करने के लिए सही खाते को अपने-आप चुन लेगा.

टोकन की पुष्टि करने वाले सिस्टम में, Google से मिले रीडायरेक्ट को पार्स करने की सुविधा होनी चाहिए. इसमें एक बार इस्तेमाल किया जा सकने वाला टोकन होता है. साथ ही, इस टोकन के साथ कार्रवाई करने की सुविधा भी होनी चाहिए. अनुमति देने वाले टोकन, किसी उपयोगकर्ता के लिए खास होते हैं. इसलिए, आपके ऐप्लिकेशन को किसी टोकन को उसके उपयोगकर्ता से जोड़ने में सक्षम होना चाहिए. हमारा सुझाव है कि टोकन का अनुरोध करने से पहले, उपयोगकर्ता को कुकी जारी की जाए. इसके बाद, जब Google, उपयोगकर्ता को आपकी साइट पर वापस रीडायरेक्ट करता है और उसमें एक टोकन जोड़ता है, तो आपका ऐप्लिकेशन कुकी को पढ़ सकता है. साथ ही, टोकन को उपयोगकर्ता की सही पहचान से जोड़ सकता है.
सेशन टोकन का अनुरोध करने और उन्हें सेव करने या रद्द करने के लिए, ज़रूरी मेकेनिज़्म सेट अप करें.
दूसरे चरण में, टोकन मैनेज करने के लिए लिए गए फ़ैसलों के आधार पर, आपको सेशन टोकन (AuthSubSessionToken और AuthSubRevokeToken) पाने और रद्द करने के लिए, तरीके बनाने पड़ सकते हैं. सेशन और रद्द करने के तरीकों की जांच करने के लिए, AuthSubTokenInfo का इस्तेमाल करें. इससे पता चलता है कि दिया गया टोकन मान्य है या नहीं. अगर टोकन सेव किए जा रहे हैं, तो ऐप्लिकेशन को उपयोगकर्ता आईडी और टोकन के दायरे में आने वाली सेवा, दोनों को ट्रैक करना होगा.
Google की किसी सेवा का ऐक्सेस पाने के लिए अनुरोध करने का तरीका सेट अप करें.
अनुरोध के सही फ़ॉर्मैट के बारे में जानने के लिए, Google की सेवा से जुड़ा दस्तावेज़ देखें. Google की किसी सेवा को भेजे गए सभी अनुरोधों में, अनुमति वाला मान्य टोकन होना ज़रूरी है. आम तौर पर, Google की किसी सेवा के लिए किया गया अनुरोध, एचटीटीपी GET के तौर पर होता है. अगर नया डेटा लिखना है, तो यह POST के तौर पर होता है. इसमें अनुरोध हेडर में टोकन का रेफ़रंस दिया जाता है.

अनुरोध हेडर इस फ़ॉर्मैट में होना चाहिए:
```
Authorization: AuthSub token="token"
```
यहां token, ऑथराइज़ेशन टोकन है. यह एक बार इस्तेमाल किया जा सकता है या सेशन के लिए इस्तेमाल किया जा सकता है. यह Google से, AuthSub अनुरोध के जवाब में मिलता है. अगर टोकन सुरक्षित है, तो उसके साथ डिजिटल हस्ताक्षर होना चाहिए. निर्देशों और उदाहरणों के लिए, "हस्ताक्षर के अनुरोध" देखें.

यहां दिए गए उदाहरण में, Google Calendar फ़ीड सेवा को कॉल करने के लिए अनुरोध हेडर दिखाया गया है. इस अनुरोध में एक असुरक्षित टोकन शामिल है:
```
GET /calendar/feeds/default/private/full HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: AuthSub token="GD32CMCL25aZ-v____8B"
User-Agent: Java/1.5.0_06
Host: www.google.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
```

AuthSub के बारे में ज़्यादा जानकारी

AuthSub के बारे में जानकारी के लिए, ये अतिरिक्त संसाधन देखें. इनमें Google के साथ अपने ऐप्लिकेशन को रजिस्टर करने और एक बार इस्तेमाल किया जा सकने वाले टोकन को सेशन टोकन के लिए एक्सचेंज करने के बारे में पूरी जानकारी शामिल है:

वेब ऐप्लिकेशन के लिए AuthSub की मदद से पुष्टि करना (पूरा दस्तावेज़)
Google Data APIs क्लाइंट लाइब्रेरी के साथ AuthSub का इस्तेमाल करना
कुंजियां और सर्टिफ़िकेट जनरेट करना (सुरक्षित AuthSub)
AuthSub की मदद से अनुरोधों पर हस्ताक्षर करना (सुरक्षित AuthSub)
वेब पर काम करने वाले ऐप्लिकेशन के लिए रजिस्ट्रेशन

वापस सबसे ऊपर जाएं

अनुमति देने के लिए ClientLogin का इस्तेमाल करना

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

इंस्टॉल किए गए ऐप्लिकेशन के लिए पुष्टि करने की सुविधा: ClientLogin

ClientLogin की मदद से, आपके ऐप्लिकेशन के उपयोगकर्ता अपने Google खाते में लॉग इन कर सकते हैं. इसके बाद, ऐप्लिकेशन लॉगिन डेटा के साथ Google से संपर्क करता है और किसी खास Google Data API को ऐक्सेस करने का अनुरोध करता है. लॉगिन की जानकारी की पुष्टि हो जाने के बाद, Google एक टोकन दिखाता है. आपका ऐप्लिकेशन, उपयोगकर्ता के खाते को ऐक्सेस करने का अनुरोध करते समय इस टोकन का इस्तेमाल करेगा. जैसे, डेटा पाने या पोस्ट करने के लिए. यह टोकन, तय समय तक मान्य रहता है. यह समय, उस Google सेवा के हिसाब से तय होता है जिसका इस्तेमाल किया जा रहा है.

ध्यान दें: Google Data APIs की क्लाइंट लाइब्रेरी, ऐसे तरीके उपलब्ध कराती हैं जिनकी मदद से, इंस्टॉल किए गए ऐप्लिकेशन में ClientLogin का इस्तेमाल किया जा सकता है. खास तौर पर, पुष्टि करने वाले टोकन को पाने, कैप्चा चुनौतियों को मैनेज करने, बाद में इस्तेमाल करने के लिए पुष्टि करने वाले टोकन को वापस पाने, और हर अनुरोध के साथ सही Authorization हेडर भेजने के तरीके हैं. अगर इनमें से किसी लाइब्रेरी का इस्तेमाल किया जा रहा है, तो Google Data APIs क्लाइंट लाइब्रेरी के साथ ClientLogin का इस्तेमाल करना लेख पढ़ें.

ClientLogin की अनुमति देने की प्रोसेस

ClientLogin के ज़रिए अनुमति देने की प्रोसेस में, तीन इकाइयां शामिल होती हैं: इंस्टॉल किया गया ऐप्लिकेशन, Google की सेवाएं, और उपयोगकर्ता. इस डायग्राम में क्रम दिखाया गया है:

पुष्टि करने की प्रोसेस

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

ClientLogin का इस्तेमाल करना

इस इंटरफ़ेस का इस्तेमाल, इंस्टॉल किए गए ऐप्लिकेशन में किया जाता है. इससे प्रोग्राम के ज़रिए किसी उपयोगकर्ता के Google खाते को ऐक्सेस किया जा सकता है. उपयोगकर्ता से लॉगिन की जानकारी इकट्ठा करने के बाद, ClientLogin को कॉल करें. इससे उपयोगकर्ता के खाते को ऐक्सेस करने का अनुरोध किया जा सकेगा. जब लॉगिन की जानकारी की पुष्टि हो जाती है, तो Google एक टोकन दिखाता है. आपका ऐप्लिकेशन, उपयोगकर्ता के खाते को ऐक्सेस करने का अनुरोध करते समय हर बार इस टोकन का इस्तेमाल करेगा. यह टोकन, तय समय तक मान्य रहता है. यह समयसीमा, उस Google सेवा के हिसाब से तय होती है जिसका इस्तेमाल किया जा रहा है.

अपने ऐप्लिकेशन में ClientLogin को शामिल करने के लिए, आपको ये काम करने होंगे:

उपयोगकर्ता से लॉगिन डेटा कैप्चर करने के लिए, यूज़र इंटरफ़ेस (यूआई) एलिमेंट बनाएं.
यूज़र इंटरफ़ेस (यूआई) को उपयोगकर्ता नाम (डोमेन वाला ईमेल पता) और पासवर्ड की ज़रूरत होती है. अगर ज़रूरी हो, तो यूज़र इंटरफ़ेस (यूआई) में Google से मिले यूआरएल का इस्तेमाल करके, CAPTCHA इमेज दिखाने की सुविधा भी होनी चाहिए. साथ ही, इसमें उपयोगकर्ता से सही जवाब मांगने की सुविधा भी होनी चाहिए. हमारा सुझाव है कि आपके यूज़र इंटरफ़ेस (यूआई) में, Google खातों के लॉगिन पेज ("https://www.google.com/accounts/Login") का लिंक शामिल हो. इससे उपयोगकर्ता, नए खाते के लिए साइन अप कर पाएंगे या खाते से जुड़ी अन्य कार्रवाइयां कर पाएंगे.
एचटीटीपीएस पोस्ट ClientLogin अनुरोध जनरेट करने और उसे ट्रांसमिट करने के लिए कोड लिखें.
इस कोड में, कैप्चा चैलेंज को हैंडल करने का लॉजिक होना चाहिए. साथ ही, इसमें logintoken और logincaptcha, दोनों पैरामीटर शामिल होने चाहिए. ऐप्लिकेशन को यह भी पता लगाना चाहिए कि उपयोगकर्ता ने ज़रूरी जानकारी नहीं दी है या लॉगिन नहीं हो पाने के बाद, गलत डेटा को दोहराया है. साथ ही, उसे बिना किसी अतिरिक्त अनुरोध के गड़बड़ी का मैसेज दिखाना चाहिए.
Google से मिले जवाबों को मैनेज करना.
लॉगिन के अनुरोध के चार संभावित जवाब हो सकते हैं:
- सफलता (एचटीटीपी 200)
- अनुरोध पूरा नहीं किया जा सका (एचटीटीपी 403) और गड़बड़ी का कोड दिया गया है
- अमान्य अनुरोध. आम तौर पर, यह गड़बड़ी तब होती है, जब अनुरोध ठीक से नहीं किया गया हो
- कैप्चा चैलेंज पूरा न हो पाने की वजह से
सफल जवाब में, "Auth" लेबल वाला एक अनुमति टोकन होता है. इस खाते के लिए, Google की सेवा से किए जाने वाले सभी अनुरोधों में यह टोकन शामिल होना चाहिए. अनुमति देने वाले टोकन को सुरक्षित रखना चाहिए. साथ ही, इन्हें किसी दूसरे ऐप्लिकेशन को नहीं देना चाहिए, क्योंकि ये उपयोगकर्ता के खाते को ऐक्सेस करने के लिए इस्तेमाल किए जाते हैं. टोकन के लिए समयसीमा, इस बात पर निर्भर करती है कि उसे किस सेवा ने जारी किया है.

गड़बड़ी वाले जवाब में, गड़बड़ी के एक या उससे ज़्यादा कोड और गड़बड़ी के मैसेज वाला यूआरएल शामिल होता है. इस मैसेज को उपयोगकर्ता को दिखाया जा सकता है. कृपया ध्यान दें कि ClientLogin, गलत पासवर्ड की वजह से हुई गड़बड़ी और ऐसे उपयोगकर्ता नाम की वजह से हुई गड़बड़ी के बीच अंतर नहीं करता जिसे पहचाना नहीं जा सका. उदाहरण के लिए, अगर उपयोगकर्ता ने अब तक किसी खाते के लिए साइन अप नहीं किया है. आपके ऐप्लिकेशन को, गड़बड़ी के सभी संभावित मैसेज को सही तरीके से हैंडल करना होगा.
अगर आपको कैप्चा चैलेंज के साथ जवाब नहीं मिलता है, तो इसका मतलब है कि Google ने किसी भी वजह से यह फ़ैसला लिया है कि सुरक्षा से जुड़े अतिरिक्त कदम उठाए जाने चाहिए. इस जवाब के साथ, कैप्चा इमेज का यूआरएल और एक टोकन भी होता है. यह टोकन, कैप्चा चैलेंज को दिखाता है.
Google से मिले कैप्चा चैलेंज को मैनेज करता है.
चैलेंज को पूरा करने के लिए, ऐप्लिकेशन को CAPTCHA इमेज दिखानी होगी और उपयोगकर्ता से जवाब मांगना होगा. कैप्चा इमेज दिखाने के लिए, फ़ेल होने पर मिले जवाब के साथ CaptchaUrl की वैल्यू का इस्तेमाल करें. इसके पहले, Google खातों का यूआरएल जोड़ें: "http://www.google.com/accounts/". जब उपयोगकर्ता जवाब दे देता है, तो ऐप्लिकेशन को लॉगिन करने का अनुरोध फिर से भेजना चाहिए. इस बार, इसमें CAPTCHA टोकन (logintoken) और उपयोगकर्ता का जवाब (logincaptcha) शामिल होना चाहिए. Google, खाते का ऐक्सेस देने से पहले, उपयोगकर्ता के जवाब की पुष्टि करता है.

ऐसे डेवलपर के लिए एक विकल्प उपलब्ध है जो उपयोगकर्ता के CAPTCHA के जवाब को पाने और उसे ट्रांसमिट करने की प्रोसेस को मैनेज नहीं करना चाहते. CAPTCHA चैलेंज के जवाब में, ऐप्लिकेशन उपयोगकर्ता को Google के होस्ट किए गए इस पेज पर रीडायरेक्ट कर सकता है: "https://www.google.com/accounts/DisplayUnlockCaptcha". जब उपयोगकर्ता चुनौती का जवाब दे देता है, तब Google सर्वर उस कंप्यूटर पर भरोसा करता है जिसका इस्तेमाल किया जा रहा है. इसके बाद, ऐप्लिकेशन अनुमति टोकन पाने के लिए, लॉगिन करने का ओरिजनल अनुरोध फिर से भेज सकता है.

ध्यान दें: Google, CAPTCHA चैलेंज जारी करने से पहले, लॉगिन करने की कोशिश की पुष्टि नहीं करता है. इसका मतलब है कि कैप्चा चैलेंज के बाद भी, लॉगिन करने की कोशिश पूरी नहीं हो सकती.

* CAPTCHA, कार्नेगी मेलन यूनिवर्सिटी का ट्रेडमार्क है

वापस सबसे ऊपर जाएं

गैजेट के लिए पुष्टि करने की सुविधा

OAuth प्रॉक्सी

अगर आपको स्टैंडर्ड Gadgets API का इस्तेमाल करके कोई गैजेट बनाना है, तो Google Data API को ऐक्सेस करने के लिए, गैजेट प्लैटफ़ॉर्म की OAuth प्रॉक्सी सुविधा का इस्तेमाल किया जा सकता है. OAuth (ऊपर बताया गया है) पुष्टि करने का एक स्टैंडर्ड है. इससे लोगों को iGoogle, MySpace या Orkut जैसी गैजेट होस्टिंग सेवा में अपने निजी डेटा को ऐक्सेस करने की अनुमति मिलती है. इसके अलावा, वे अपने डेटा को किसी दूसरी वेबसाइट या गैजेट के साथ शेयर कर सकते हैं. OAuth प्रॉक्सी को इस तरह से डिज़ाइन किया गया है कि यह गैजेट डेवलपर के लिए डेवलपमेंट को आसान बना सके. इसके लिए, यह OAuth की पुष्टि करने से जुड़ी कई जानकारी को छिपा देता है. प्रॉक्सी, Shindig नाम के ओपन-सोर्स प्रोजेक्ट पर आधारित है. यह गैजेट स्पेसिफ़िकेशन को लागू करता है.

ध्यान दें: OAuth प्रॉक्सी की सुविधा सिर्फ़ उन गैजेट के लिए काम करती है जो gadgets.* API का इस्तेमाल करते हैं और OpenSocial कंटेनर में चलते हैं. यह लेगसी गैजेट एपीआई के साथ काम नहीं करता.

पुष्टि करने की प्रोसेस

आपके गैजेट को किसी उपयोगकर्ता का डेटा ऐक्सेस करने से पहले, OAuth टोकन हासिल करना होगा. OAuth प्रॉक्सी, आपके लिए पुष्टि करने के फ़्लो को मैनेज करती है. जब कोई उपयोगकर्ता पहली बार आपका गैजेट इंस्टॉल करता है, तो यह प्रोसेस होती है:

आपका गैजेट पहली बार लोड होता है और Google Data API में से किसी एक का इस्तेमाल करके, उपयोगकर्ता के डेटा को ऐक्सेस करने की कोशिश करता है.
उपयोगकर्ता ने ऐक्सेस नहीं दिया है. इसलिए, अनुरोध पूरा नहीं हो सका. जवाब वाले ऑब्जेक्ट में, OAuth की अनुमति वाले पेज के लिए यूआरएल (response.oauthApprovalUrl में) होता है. आपके गैजेट में, उस यूआरएल के साथ नई विंडो लॉन्च करने का तरीका होना चाहिए.
मंज़ूरी वाले पेज पर, उपयोगकर्ता आपके गैजेट को ऐक्सेस करने की अनुमति देता है या नहीं देता है. अगर यह प्रोसेस पूरी हो जाती है, तो उपयोगकर्ता को आपकी ओर से तय किए गए oauth_callback पेज पर ले जाया जाता है. उपयोगकर्ताओं को बेहतर अनुभव देने के लिए, http://oauth.gmodules.com/gadgets/oauthcallback का इस्तेमाल करें.
इसके बाद, उपयोगकर्ता पॉप-अप विंडो को बंद कर देता है. उपयोगकर्ता ने अनुमति दे दी है, इसकी सूचना अपने गैजेट को देने के लिए, पॉप-अप हैंडलर का इस्तेमाल करके, अनुमति वाली विंडो के बंद होने का पता लगाया जा सकता है. इसके अलावा, आपका गैजेट उपयोगकर्ता को एक लिंक (जैसे, "मैंने ऐक्सेस को मंज़ूरी दे दी है") दिखा सकता है. इस विंडो के बंद होने के बाद, उपयोगकर्ता इस लिंक पर क्लिक कर सकता है.
आपका गैजेट, उपयोगकर्ता के डेटा का फिर से अनुरोध करके, Google Data API को दूसरी बार ऐक्सेस करने की कोशिश करता है. यह कोशिश सफल रही.
आपके गैजेट की पुष्टि हो गई है और अब यह सामान्य रूप से काम कर सकता है.

गैजेट सेटअप करना

Google Data API में से किसी एक या उससे ज़्यादा को ऐक्सेस करने के लिए, आपको सबसे पहले अपने गैजेट को यह बताना होगा कि पुष्टि करने के तरीके के तौर पर OAuth का इस्तेमाल किया जाए. अपने गैजेट के XML के <ModulePrefs> सेक्शन में, <OAuth> एलिमेंट जोड़ें:

<ModulePrefs>
...
<OAuth>
  <Service name="google">
    <Access url="https://www.google.com/accounts/OAuthGetAccessToken" method="GET" />
    <Request url="https://www.google.com/accounts/OAuthGetRequestToken?
                  scope=http://www.blogger.com/feeds/%20http://www.google.com/calendar/feeds/" method="GET" />
    <Authorization url="https://www.google.com/accounts/OAuthAuthorizeToken?
                        oauth_callback=http://oauth.gmodules.com/gadgets/oauthcallback" />
  </Service>
</OAuth>
...
</ModulePrefs>

इस सेक्शन में, सिर्फ़ इन क्वेरी पैरामीटर को बदलें:

scope: अनुरोध यूआरएल में मौजूद ज़रूरी पैरामीटर. आपका गैजेट, इस पैरामीटर में इस्तेमाल किए गए scope से डेटा ऐक्सेस कर सकता है. इस उदाहरण में, गैजेट Blogger और Calendar का डेटा ऐक्सेस कर सकता है. कोई गैजेट, एक या एक से ज़्यादा स्कोप के लिए डेटा का अनुरोध कर सकता है. इस उदाहरण में ऐसा ही किया गया है.
oauth_callback: यह अनुमति देने वाले यूआरएल में मौजूद एक वैकल्पिक पैरामीटर है. उपयोगकर्ता के डेटा का ऐक्सेस देने की मंज़ूरी मिलने के बाद, OAuth की मंज़ूरी देने वाला पेज इस यूआरएल पर रीडायरेक्ट हो जाता है. आपको इस पैरामीटर को http://oauth.gmodules.com/gadgets/oauthcallback पर सेट करना चाहिए, ताकि उपयोगकर्ता जब आपका गैजेट इंस्टॉल करें, तो उन्हें बेहतर अनुभव मिल सके. उस पेज पर JavaScript का एक स्निपेट दिया गया है. इससे पॉप-अप विंडो अपने-आप बंद हो जाती है. इसके अलावा, इस पैरामीटर को अपने "स्वीकार किया गया" पेज पर रीडायरेक्ट करने के लिए सेट किया जा सकता है. इसके अलावा, इस पैरामीटर को खाली भी छोड़ा जा सकता है.

पुष्टि किए गए Google Data API फ़ीड को ऐक्सेस करना

जब आपका गैजेट उपयोगकर्ता की पुष्टि कर लेता है, तब Google Data APIs JavaScript क्लाइंट लाइब्रेरी की मदद से, Google Data API को आसानी से ऐक्सेस किया जा सकता है. OAuth प्रॉक्सी में लाइब्रेरी का इस्तेमाल करने के बारे में जानने के लिए, JavaScript Client Library का इस्तेमाल करना लेख पढ़ें.

गैजेट के बारे में ज़्यादा जानकारी

Google Data API गैजेट बनाने के बारे में पूरी जानकारी के लिए, इन अतिरिक्त संसाधनों को देखें. इनमें OAuth प्रॉक्सी के बारे में जानकारी, शुरू करने के तरीके के बारे में लेख, और gadgets.* स्पेसिफ़िकेशन शामिल हैं:

JavaScript क्लाइंट लाइब्रेरी का इस्तेमाल करना
Google Data APIs गैजेट बनाना (लेख)
OAuth गैजेट लिखना (गैजेट का पूरा दस्तावेज़)
Gadgets API का दस्तावेज़

वापस सबसे ऊपर जाएं