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

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

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

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

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

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

प्रॉडक्शन में इस्तेमाल किए जाने वाले 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 की नीतियों का पालन करने के बाद, पुष्टि करने की प्रोसेस के बारे में जानने के लिए, ब्रैंड की पुष्टि के लिए सबमिट करें लेख पढ़ें.