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

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

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

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

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

  1. Go to the Google API Console. Click Create project, enter a name, and click Create.
  2. इस प्रोजेक्ट में मौजूद OAuth क्लाइंट की समीक्षा करें. हो सकता है कि ये आपके टेस्टिंग टियर से जुड़े हों. अगर लागू हो, तो अपने प्रोडक्शन प्रोजेक्ट में प्रोडक्शन क्लाइंट के लिए मिलते-जुलते OAuth क्लाइंट बनाएं.
  3. ऐसे एपीआई चालू करें जिनका इस्तेमाल आपके क्लाइंट कर रहे हों.
  4. नए प्रोजेक्ट में, OAuth की सहमति वाली स्क्रीन के कॉन्फ़िगरेशन की समीक्षा करें.

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

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

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

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

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

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

अपनी पहचान को सटीक तरीके से दिखाना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगले चरण

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