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

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

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

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

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

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

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

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

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

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

Google खाता API के उपयोग पर चर्चा करने के लिए Google खाता API समूह भी देखें.

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 खाते से संबद्ध डेटा तक प्राधिकृत पहुंच की आवश्यकता वाले वेब ऐप्स Google के OAuth API के क्रियान्वयन का उपयोग कर सकते हैं. वेब आधारित ऐप्लिकेशन के लिए OAuth लागू करने के बारे में ज़्यादा जानकारी पाने के लिए, वेब ऐप्लिकेशन के लिए OAuth गाइड देखें या इस दस्तावेज़ में खास जानकारी देखें.

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

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

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

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

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

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

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

मूल स्तर पर, प्रक्रिया इस प्रकार है:

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

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

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

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

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

OAuth के लिए तैयार हो रहा है

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

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

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

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

इसके अलावा, अपने अनुरोधों पर हस्ताक्षर करने के लिए, HMAC-SHA1 हस्ताक्षर का इस्तेमाल किया जा सकता है. 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 अनुरोध के रूप में किया जाता है. इसमें हेडर में ऐक्सेस टोकन और हस्ताक्षर शामिल होता है. नया डेटा लिखने के अनुरोधों में एचटीटीपी POST का इस्तेमाल करना चाहिए.

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

OpenSSL लागू करना (वैकल्पिक)

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

OAuth टोकन के साथ काम करना

OAuth का इस्तेमाल करने के लिए, आपके ऐप्लिकेशन में सही तरीके से बनाए गए टोकन टोकन जनरेट होने चाहिए और नीचे दिए गए क्रम के मुताबिक रिस्पॉन्स को हैंडल करना चाहिए:

  1. बिना मंज़ूरी वाला अनुरोध टोकन पाएं (OAuthGetRequestToken)
  2. अनुरोध टोकन को अनुमति दें (OAuthAuthorizeToken)
  3. ऐक्सेस टोकन (OAuthGetAccessToken) के लिए, अनुरोध वाले टोकन को ट्रांसफ़र करें

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

आपके पास, OAuth प्लेग्राउंड में अनुमति वाले टोकन पाने और पाने का विकल्प है.

ज़्यादा जानकारी वाले दस्तावेज़ के लिए, OAuth एपीआई का रेफ़रंस देखें.

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

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

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

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

उपयोगकर्ताओं को आपके ऐप्लिकेशन के बारे में बताना

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

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

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

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

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

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

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

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

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

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

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

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

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

मूल स्तर पर, प्रक्रिया इस प्रकार है:

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

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

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

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

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

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

OAuth के लिए तैयार हो रहा है

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

आपका ऐप्लिकेशन जिस डेटा का इस्तेमाल करेगा उसका दायरा तय करना

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

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

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

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

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

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

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

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

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

OAuth टोकन के साथ काम करना

OAuth का इस्तेमाल करने के लिए, आपके ऐप्लिकेशन में सही तरीके से बनाए गए टोकन टोकन जनरेट होने चाहिए और नीचे दिए गए क्रम के मुताबिक रिस्पॉन्स को हैंडल करना चाहिए:

  1. बिना मंज़ूरी वाला अनुरोध टोकन पाएं (OAuthGetRequestToken)
  2. अनुरोध टोकन को अनुमति दें (OAuthAuthorizeToken)
  3. ऐक्सेस टोकन (OAuthGetAccessToken) के लिए, अनुरोध वाले टोकन को ट्रांसफ़र करें

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

आपके पास, OAuth प्लेग्राउंड में अनुमति वाले टोकन पाने और पाने का विकल्प है.

ज़्यादा जानकारी वाले दस्तावेज़ के लिए, OAuth एपीआई का रेफ़रंस देखें.

उपयोगकर्ताओं को आपके ऐप्लिकेशन के बारे में बताना

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

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

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

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

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

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

अपने-आप पता लगाने वाला मोड

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

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

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

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

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

डिवाइस मोड

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

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

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

यह मोड सिर्फ़ किसी ऐप्लिकेशन के शुरुआती डेवलपमेंट के दौरान इस्तेमाल करने के लिए सुझाया गया है.

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

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

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

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

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

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

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

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

पुष्टि करने की AuthSub प्रक्रिया

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

अनुमति देने की प्रक्रिया

  1. जब वेब ऐप्लिकेशन को किसी उपयोगकर्ता की Google सेवा का ऐक्सेस चाहिए, तो वह Google की ऑथराइज़ेशन प्रॉक्सी सेवा को AuthSub कॉल करता है.
  2. अनुमति देने का काम, ऐक्सेस के अनुरोध वाले पेज पर दिखाया जाता है. Google की ओर से मैनेज होने वाले इस पेज पर, उपयोगकर्ता को Google की सेवा का ऐक्सेस देने या न देने की सूचना दी जाती है. उपयोगकर्ता से पहले उसके खाते में लॉग इन करने के लिए कहा जा सकता है.
  3. उपयोगकर्ता यह तय करता है कि उसे वेब ऐप्लिकेशन का ऐक्सेस दिया जाए या नहीं. अगर उपयोगकर्ता ऐक्सेस देने से मना कर देता है, तो उसे वेब ऐप्लिकेशन पर वापस ले जाने के बजाय Google पेज पर भेज दिया जाता है.
  4. अगर उपयोगकर्ता को ऐक्सेस दिया जाता है, तो अनुमति देने वाली सेवा, उपयोगकर्ता को वेब ऐप्लिकेशन पर रीडायरेक्ट कर देती है. रीडायरेक्ट में, एक ऑथराइज़ेशन टोकन शामिल होता है, जिसका इस्तेमाल सिर्फ़ एक बार किया जा सकता है. इसे लंबे समय तक इस्तेमाल किए जाने वाले टोकन के साथ बदला जा सकता है.
  5. वेब ऐप्लिकेशन, ऑथराइज़ेशन टोकन का इस्तेमाल करके, Google की सेवा से संपर्क करता है और उपयोगकर्ता के एजेंट के तौर पर काम करता है.
  6. अगर Google की सेवाओं को टोकन मिलता है, तो वह मांगी गई जानकारी उपलब्ध कराता है.

AuthSub के साथ काम करना

AuthSub को अपने वेब ऐप्लिकेशन में शामिल करने के लिए इन कामों की ज़रूरत होती है:

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

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

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

  2. तय करें कि किस तरह के टोकन का इस्तेमाल करना है और उन्हें कैसे मैनेज करना है.

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

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

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

  3. Google सेवा के ऐक्सेस किए जाने वाले दायरे को तय करें.

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

  4. अनुरोध करने और ऑथराइज़ेशन टोकन पाने का तरीका सेट अप करें.

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

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

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

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

  5. सेशन के टोकन का अनुरोध करने के लिए, मैकेनिज़्म सेट अप करें और ज़रूरत पड़ने पर उन्हें इकट्ठा या निरस्त करें.

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

  6. Google सेवा के ऐक्सेस का अनुरोध करने का तरीका सेट अप करें.

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

    अनुरोध के हेडर में यह फ़ॉर्म दिखना चाहिए:

    Authorization: AuthSub token="token"

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

    नीचे दिए गए उदाहरण में, 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 के बारे में ज़्यादा जानकारी

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

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

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

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

इंस्टॉल किए गए ऐप्लिकेशन के लिए प्रमाणीकरण: ClientLogin

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

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

Clientलॉगिन की अनुमति देने की प्रोसेस

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

अनुमति देने की प्रक्रिया

  1. जब तीसरे पक्ष के ऐप्लिकेशन को उपयोगकर्ता की Google सेवा का ऐक्सेस चाहिए, तो वह उपयोगकर्ता के लॉगिन नाम और पासवर्ड को वापस लाता है.
  2. इसके बाद, तीसरे पक्ष का ऐप्लिकेशन Google की ऑथराइज़ेशन सेवा को ClientLogin कॉल करता है.
  3. अगर Google की अनुमति देने वाली सेवा अलग से जांच करवाने का फ़ैसला करती है, तो वह कैप्चा टोकन और चुनौती के साथ कैप्चा इमेज के लिए यूआरएल के रूप में गड़बड़ी का जवाब देती है.
  4. अगर कोई कैप्चा चुनौती मिलती है, तो तीसरे पक्ष का ऐप्लिकेशन, उपयोगकर्ता के लिए कैप्चा इमेज दिखाएगा और उपयोगकर्ता से जवाब मांगेगा.
  5. अनुरोध किए जाने पर, उपयोगकर्ता कैप्चा चुनौती का जवाब सबमिट करता है.
  6. तृतीय-पक्ष ऐप्लिकेशन इस बार एक नया ClientLogin कॉल करता है, जिसमें कैप्चा जवाब और टोकन शामिल है (जो विफल होने की प्रतिक्रिया के साथ मिला है).
  7. लॉगिन की कोशिश सफल होने पर (कैप्चा चुनौती के साथ या उसके बिना), Google की अनुमति सेवा ऐप्लिकेशन को टोकन देती है.
  8. ऐप्लिकेशन, Google की अनुमति देने वाली सेवा से मिले टोकन का रेफ़रंस देते हुए, डेटा ऐक्सेस के अनुरोध के साथ Google की सेवा से संपर्क करता है.
  9. अगर Google सेवा टोकन को पहचान लेती है, तो वह अनुरोध किए गए डेटा को ऐक्सेस कर देती है.

ClientLogin का उपयोग

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

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

  1. उपयोगकर्ता का लॉगिन डेटा कैप्चर करने के लिए, यूज़र इंटरफ़ेस (यूआई) एलिमेंट बनाएं.

    यूज़र इंटरफ़ेस (यूआई) को उपयोगकर्ता नाम (डोमेन सहित ईमेल पते) और पासवर्ड मांगने की ज़रूरत है. अगर ज़रूरी हो, तो यूज़र इंटरफ़ेस (यूआई), Google से मिले यूआरएल का इस्तेमाल करके, कैप्चा इमेज दिखा सकता है. साथ ही, उपयोगकर्ता से सही जवाब मांग सकता है. आम तौर पर, आपके यूज़र इंटरफ़ेस (यूआई) में उपयोगकर्ता के नए खाते के लिए साइन अप करने या खाते के दूसरे रखरखाव के लिए, Google खातों के लॉगिन पेज ("https://www.google.com/accounts/Login") का लिंक शामिल होता है.

  2. एचटीटीपीएस पोस्ट ClientLogin का अनुरोध जनरेट करने और उसे ट्रांसमिट करने के लिए कोड लिखें.

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

  3. Google से मिलने वाले जवाबों को मैनेज करना.

    लॉगिन के अनुरोध के चार संभावित जवाब होते हैं:

    • हो गया (एचटीटीपी 200)
    • पूरी जानकारी देने वाले गड़बड़ी के कोड वाली गड़बड़ी (एचटीटीपी 403)
    • अमान्य अनुरोध, आम तौर पर किसी गलत अनुरोध की वजह से
    • कैप्चा चुनौती में असफलता

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

    अगर उपयोगकर्ता किसी गड़बड़ी का जवाब देता है, तो एक या उससे ज़्यादा गड़बड़ी कोड के साथ-साथ गड़बड़ी के मैसेज का एक यूआरएल भी दिया जाता है, जिसे उपयोगकर्ता को दिखाया जा सकता है. कृपया ध्यान दें कि ClientLogin और गलत पासवर्ड आपके ऐप्लिकेशन को सभी संभव गड़बड़ी संदेशों को उचित रूप से प्रबंधित करना होगा.

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

  4. Google की ओर से कैप्चा चुनौती हैंडल करें.

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

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

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

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

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

गैजेट के लिए प्रमाणीकरण

OAuth प्रॉक्सी

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

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

पुष्टि करने का तरीका

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

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

गैजेट सेटअप

एक या ज़्यादा Google Data API ऐक्सेस करने के लिए आपको पहले अपने गैजेट को पुष्टि करने के तरीके के रूप में OAuth का इस्तेमाल करना होगा. अपने गैजेट के एक्सएमएल के <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 के डेटा को ऐक्सेस कर सकता है. इस उदाहरण में, गैजेट ब्लॉगर और कैलेंडर डेटा तक पहुंच सकता है. गैजेट एक उदाहरण या कई दायरों के लिए डेटा का अनुरोध कर सकता है, जैसा कि इस उदाहरण में किया गया है.
oauth_callback
अनुमति यूआरएल में एक वैकल्पिक पैरामीटर. जब उपयोगकर्ता डेटा को ऐक्सेस करने की अनुमति दे देता है, तब OAuth मंज़ूरी वाला पेज इस यूआरएल पर रीडायरेक्ट करता है. आपको इस पैरामीटर को http://oauth.gmodules.com/gadgets/oauthcallback पर सेट करना चाहिए, ताकि उपयोगकर्ताओं के आपके गैजेट को इंस्टॉल कर सकें. वह पेज JavaScript का स्निपेट देता है जो पॉप-अप विंडो को अपने-आप बंद कर देता है. इसके अलावा, इस पैरामीटर को "स्वीकार किए गए" पेज पर सेट किया जा सकता है या पैरामीटर को खाली छोड़ा जा सकता है.

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

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

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

OAuth प्रॉक्सी, आरंभ करने के तरीके पर एक लेख, और gadgets.* विशिष्टताओं सहित, Google डेटा API गैजेट बनाने पर पूर्ण जानकारी के लिए, ये अतिरिक्त संसाधन देखें:

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