OAuth 2.0 की नीतियों का पालन करना

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

टेस्टिंग और प्रोडक्शन के लिए अलग-अलग प्रोजेक्ट का इस्तेमाल करना

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

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

  2. इस प्रोजेक्ट में उन OAuth क्लाइंट की समीक्षा करें जो आपके टेस्टिंग टीयर से जुड़े हो सकते हैं. अगर लागू हो, तो अपने प्रोडक्शन प्रोजेक्ट में मौजूद प्रोडक्शन क्लाइंट के लिए, मिलते-जुलते OAuth क्लाइंट बनाएं.
  3. अपने क्लाइंट के इस्तेमाल में, किसी भी एपीआई को चालू करें.
  4. के में, नए प्रोजेक्ट के लिए OAuth की सहमति वाली स्क्रीन के कॉन्फ़िगरेशन की समीक्षा करें
    5. .

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

  • अलग-अलग डेवलपर के टेस्ट सर्वर
  • अपने ऐप्लिकेशन के टेस्ट वर्शन या रिलीज़ से पहले के वर्शन की जांच करना

प्रोजेक्ट के लिए काम के संपर्कों की सूची बनाए रखना

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

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

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

Google API का ऐक्सेस हटाया जा सकता है.

अपनी पहचान को सही तरीके से पेश करना

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

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

Google, अपनी पहचान गलत तरीके से पेश करने या लोगों को धोखा देने की कोशिश करने वाले ऐप्लिकेशन के लिए, Google API सेवाओं और Google के अन्य प्रॉडक्ट और सेवाओं का ऐक्सेस रद्द कर सकता है या निलंबित कर सकता है.

सिर्फ़ उन स्कोप के लिए अनुरोध करें जिनकी आपको ज़रूरत है

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

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

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

पुष्टि के लिए, संवेदनशील या प्रतिबंधित स्कोप का इस्तेमाल करने वाले प्रोडक्शन ऐप्लिकेशन सबमिट करना

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

सिर्फ़ अपने मालिकाना हक वाले डोमेन का इस्तेमाल करें

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

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

प्रोडक्शन ऐप्लिकेशन के लिए होम पेज होस्ट करना

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

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

सुरक्षित रीडायरेक्ट के लिए यूआरआई और JavaScript ऑरिजिन का इस्तेमाल करना

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

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

अगले चरण

इस पेज पर मौजूद OAuth 2.0 की नीतियों का पालन करने के बाद, पुष्टि की प्रोसेस के बारे में जानने के लिए, ब्रैंड की पुष्टि के लिए सबमिट करें लेख पढ़ें.