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

इस गाइड में बताया गया है कि ऐप्लिकेशन को प्रोडक्शन के लिए तैयार करते समय, डेवलपर को आम तौर पर होने वाली समस्याओं को कैसे हल किया जा सकता है.

खास जानकारी

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

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

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

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

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

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

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

प्रोजेक्ट से जुड़े संपर्कों की सूची बनाएं

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

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

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

अपनी पहचान के बारे में सटीक जानकारी देना

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

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

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

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

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

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

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

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

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

हमारा सुझाव है कि आपका ऐप्लिकेशन, साइन इन बटन को जोड़ने के लिए, ब्रैंडिंग के आधिकारिक दिशा-निर्देशों का पालन करे.

सिर्फ़ उन डोमेन का इस्तेमाल करें जिन पर आपका मालिकाना हक है

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

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

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

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

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

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

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

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

अगले चरण

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