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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगले चरण

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