जब आप अपने ऐप्लिकेशन के उपयोगकर्ताओं के लिए, डेवलपमेंट एनवायरमेंट के अलावा अन्य तरीकों से लागू किया गया समाधान डिप्लॉय करने के लिए तैयार हों, तब आपको Google की OAuth 2.0 की नीतियों का पालन करने के लिए, कुछ और कदम उठाने पड़ सकते हैं. इस गाइड में, हमने यह बताया है कि अपने ऐप्लिकेशन को प्रोडक्शन के लिए तैयार करते समय, डेवलपर को होने वाली सबसे आम समस्याओं को कैसे हल किया जा सकता है. इससे आपको सीमित गड़बड़ियों के साथ ऑडियंस की ज़्यादा से ज़्यादा संख्या तक पहुंचने में मदद मिलती है.
- टेस्ट और प्रोडक्शन के लिए अलग-अलग प्रोजेक्ट इस्तेमाल करें
- प्रोजेक्ट के हिसाब से काम के संपर्कों की सूची बनाए रखना
- अपनी पहचान से जुड़ी सही जानकारी दें
- सिर्फ़ उन दायरों के लिए अनुरोध करें जिनकी आपको ज़रूरत है
- ऐसे प्रोडक्शन ऐप्लिकेशन सबमिट करें जो पुष्टि करने के लिए, संवेदनशील या पाबंदी वाले दायरों का इस्तेमाल करते हैं
- सिर्फ़ अपने मालिकाना हक वाले डोमेन का इस्तेमाल करें
- प्रोडक्शन ऐप्लिकेशन के लिए होम पेज होस्ट करना
- सुरक्षित रीडायरेक्ट यूआरआई और JavaScript ऑरिजिन का इस्तेमाल करना
टेस्टिंग और प्रोडक्शन के लिए अलग-अलग प्रोजेक्ट इस्तेमाल करें
Google की OAuth नीतियों के मुताबिक, जांच और प्रोडक्शन के लिए अलग-अलग प्रोजेक्ट की ज़रूरत होती है. कुछ नीतियां और ज़रूरी शर्तें सिर्फ़ प्रोडक्शन ऐप्लिकेशन पर लागू होती हैं. आपको एक अलग प्रोजेक्ट बनाने और उसे कॉन्फ़िगर करने की ज़रूरत पड़ सकती है. इसमें ऐसे OAuth क्लाइंट शामिल हैं जो सभी Google खातों के लिए उपलब्ध आपके ऐप्लिकेशन के प्रोडक्शन वर्शन से मेल खाते हों.
प्रोडक्शन में इस्तेमाल किए जाने वाले Google OAuth क्लाइंट, ऐसे OAuth क्लाइंट के मुकाबले ज़्यादा स्थिर, अनुमान लगाने वाला, और सुरक्षित डेटा इकट्ठा करने और सेव करने के लिए इस्तेमाल करते हैं जो उसी ऐप्लिकेशन की जांच या डीबग करते हैं. आपके प्रोडक्शन प्रोजेक्ट को पुष्टि के लिए सबमिट किया जा सकता है. इसलिए, इस पर एपीआई के खास दायरे के लिए अन्य ज़रूरी शर्तें लागू होंगी. इनमें, तीसरे पक्ष की सुरक्षा का आकलन भी शामिल हो सकता है.
- Go to the Google API Console. Click Create project, enter a name, and click Create.
- इस प्रोजेक्ट में उन OAuth क्लाइंट की समीक्षा करें जो आपके टेस्टिंग टीयर से जुड़े हो सकते हैं. अगर लागू हो, तो अपने प्रोडक्शन प्रोजेक्ट में प्रोडक्शन क्लाइंट के लिए, मिलते-जुलते OAuth क्लाइंट बनाएं.
- ऐसे सभी एपीआई चालू करें जिनका इस्तेमाल आपके क्लाइंट करते हैं.
- नए प्रोजेक्ट में, 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 नीतियों का पालन करता है, तब पुष्टि की प्रक्रिया के बारे में ज़्यादा जानने के लिए ब्रैंड की पुष्टि के लिए सबमिट करना देखें.