पाबंदी वाले दायरे की पुष्टि

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

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

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

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

पाबंदी वाले दायरों के बारे में जानकारी

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

दायरे के इस्तेमाल के बारे में जानकारी

  • उन दायरों की समीक्षा करें जिनका इस्तेमाल आपका ऐप्लिकेशन करता है या जिनका इस्तेमाल करना है. दायरे के मौजूदा इस्तेमाल के बारे में जानने के लिए, अपने ऐप्लिकेशन के सोर्स कोड की जांच करें. देखें कि अनुमति के अनुरोधों के साथ कोई दायरा भेजा गया है या नहीं.
  • पक्का करें कि अनुरोध किया गया हर दायरा, आपके ऐप्लिकेशन की सुविधा के लिए ज़रूरी है. साथ ही, यह भी पक्का करें कि सुविधा देने के लिए, कम से कम ज़रूरी अधिकार का इस्तेमाल किया गया हो. आम तौर पर, Google API के एंडपॉइंट के लिए, प्रॉडक्ट के Google डेवलपर पेज पर रेफ़रंस दस्तावेज़ मौजूद होता है. इसमें, एंडपॉइंट या उसकी खास प्रॉपर्टी को कॉल करने के लिए ज़रूरी दायरे की जानकारी शामिल होती है. आपके ऐप्लिकेशन के कॉल किए गए एपीआई एंडपॉइंट के लिए, ऐक्सेस के ज़रूरी दायरों के बारे में ज़्यादा जानकारी पाने के लिए, उन एंडपॉइंट के रेफ़रंस दस्तावेज़ पढ़ें. For example, for an app that only uses Gmail APIs to occasionally send emails on a user's behalf, don't request the scope that provides full access to the user's email data.
  • Google API से मिले डेटा का इस्तेमाल सिर्फ़ एपीआई की नीतियों के मुताबिक किया जाना चाहिए. साथ ही, इसका इस्तेमाल उसी तरीके से किया जाना चाहिए जैसा कि आपने अपने ऐप्लिकेशन की कार्रवाइयों और निजता नीति में अपने उपयोगकर्ताओं को बताया है.
  • हर दायरे के बारे में ज़्यादा जानने के लिए, एपीआई के दस्तावेज़ देखें. इसमें, दायरे की संभावित स्थिति भी शामिल है.
  • Cloud Console के डेटा ऐक्सेस पेज पर, अपने ऐप्लिकेशन के इस्तेमाल किए गए सभी दायरों की जानकारी दें. आपके बताए गए दायरों को संवेदनशील या पाबंदी वाली कैटगरी में बांटा जाता है, ताकि पुष्टि की किसी भी अतिरिक्त ज़रूरत को हाइलाइट किया जा सके.
  • अपने इंटिग्रेशन के इस्तेमाल किए गए डेटा से मेल खाने वाला सबसे सही दायरा ढूंढें. साथ ही, उसके इस्तेमाल के बारे में जानें. पुष्टि करें कि टेस्टिंग एनवायरमेंट में सब कुछ अब भी काम कर रहा है. फिर, पुष्टि के लिए सबमिट करने की तैयारी करें.

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

अनुमति वाले ऐप्लिकेशन के टाइप

कुछ टाइप के ऐप्लिकेशन, हर प्रॉडक्ट के लिए पाबंदी वाले दायरों को ऐक्सेस कर सकते हैं. ऐप्लिकेशन के टाइप, प्रॉडक्ट के हिसाब से Google डेवलपर पेज पर देखे जा सकते हैं. उदाहरण के लिए, Gmail API की नीति.

अपने ऐप्लिकेशन के टाइप को समझना और तय करना आपकी ज़िम्मेदारी है. हालांकि, अगर आपको अपने ऐप्लिकेशन के टाइप के बारे में पक्का नहीं पता है, तो पुष्टि के लिए ऐप्लिकेशन सबमिट करते समय, किन सुविधाओं का इस्तेमाल किया जाएगा? सवाल के लिए कोई विकल्प न चुनें. इसके बाद, Google API की पुष्टि करने वाली टीम, ऐप्लिकेशन का टाइप तय करेगी.

सुरक्षा का आकलन

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

सुरक्षा के आकलन को स्टैंडर्ड बनाने के लिए, हम App Defense Alliance और क्लाउड ऐप्लिकेशन की सुरक्षा के आकलन के फ़्रेमवर्क (CASA) का इस्तेमाल करते हैं.

जैसा कि पहले बताया गया है, पुष्टि किए गए पाबंदी वाले दायरों का ऐक्सेस बनाए रखने के लिए, ऐप्लिकेशन को हर 12 महीने में कम से कम एक बार, नियमों के मुताबिक होने की पुष्टि करानी होगी. साथ ही, सुरक्षा का आकलन पूरा करना होगा. यह आकलन, आकलनकर्ता के Letter of Assessment (LOA) की मंज़ूरी की तारीख के बाद कराना होगा. अगर आपका ऐप्लिकेशन, पाबंदी वाला कोई नया दायरा जोड़ता है, तो हो सकता है कि आपके ऐप्लिकेशन का फिर से आकलन करना पड़े. ऐसा तब होगा, जब नया दायरा, सुरक्षा के पिछले आकलन में शामिल न किया गया हो.

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

पुष्टि की प्रोसेस के लिए तैयारी करने का तरीका

डेटा को ऐक्सेस करने का अनुरोध करने के लिए, Google API का इस्तेमाल करने वाले सभी ऐप्लिकेशन को, ब्रैंड की पुष्टि की प्रोसेस पूरी करने के लिए यह तरीका अपनाना होगा:

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

ऐप्लिकेशन के होम पेज की ज़रूरी शर्तें

पक्का करें कि आपका होम पेज, इन ज़रूरी शर्तों को पूरा करता हो:

  • आपका होम पेज सार्वजनिक तौर पर ऐक्सेस किया जा सकता हो. ऐसा न हो कि इसे सिर्फ़ आपकी साइट के लॉग-इन किए हुए उपयोगकर्ता ही ऐक्सेस कर पाएं.
  • समीक्षा के लिए सबमिट किए गए ऐप्लिकेशन के लिए, आपका होम पेज काम का होना चाहिए.
  • Google Play Store पर आपके ऐप्लिकेशन की लिस्टिंग या उसके Facebook पेज के लिंक को, ऐप्लिकेशन के मान्य होम पेज नहीं माना जाता.

ऐप्लिकेशन की निजता नीति के लिंक की ज़रूरी शर्तें

पक्का करें कि आपके ऐप्लिकेशन की निजता नीति, इन ज़रूरी शर्तों को पूरा करती हो:

  • निजता नीति, उपयोगकर्ताओं को दिखनी चाहिए. साथ ही, यह आपके ऐप्लिकेशन के होम पेज वाले डोमेन में ही होस्ट की जानी चाहिए. इसके अलावा, इसे Google API Console की OAuth सहमति स्क्रीन से लिंक किया जाना चाहिए. ध्यान दें कि होम पेज में, ऐप्लिकेशन के फ़ंक्शन के बारे में जानकारी के साथ-साथ, निजता नीति और सेवा की वैकल्पिक शर्तों के लिंक भी शामिल होने चाहिए.
  • निजता नीति में, इस बारे में जानकारी होनी चाहिए कि आपका ऐप्लिकेशन, Google के उपयोगकर्ता डेटा को कैसे ऐक्सेस करता है, उसका इस्तेमाल करता है, उसे सेव करता है या शेयर करता है. The privacy policy must comply with the Google API Services User Data Policy and the Limited Use requirements for restricted scopes. आपको Google के उपयोगकर्ता डेटा का इस्तेमाल, सिर्फ़ उन तरीकों से करना होगा जिनके बारे में आपकी पब्लिश की गई निजता नीति में बताया गया है.
  • Review example cases of privacy policies that don't meet the Limited Use requirements.

ब्रैंड की पुष्टि के लिए, अपने ऐप्लिकेशन को सबमिट करने का तरीका

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

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

पुष्टि के लिए सबमिट करने के लिए, यह तरीका अपनाएं:

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

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

    https://console.developers.google.com/auth/branding?project=[PROJECT_ID]

    [PROJECT_ID] की जगह, वह प्रोजेक्ट आईडी डालें जिसका इस्तेमाल करना है.

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

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

  11. अपने ऐप्लिकेशन के अनुरोध किए गए सभी दायरों की जानकारी देने के लिए, दायरे जोड़ें या हटाएं बटन का इस्तेमाल करें. Google साइन-इन के लिए ज़रूरी दायरों का शुरुआती सेट संवेदनशील नहीं हैं सेक्शन में पहले से भरा होता है. जोड़े गए दायरों को संवेदनशील नहीं हैं, <a href="/identity/protocols/oauth2/production-readiness/sensitive-scope-verification"

    sensitive, or restricted.

  12. अपने ऐप्लिकेशन में, संबंधित सुविधाओं के लिए काम के किसी भी दस्तावेज़ के ज़्यादा से ज़्यादा तीन लिंक दें.

  13. इसके बाद के चरणों में, अपने ऐप्लिकेशन के बारे में अनुरोध की गई कोई भी अतिरिक्त जानकारी दें.

    1. Ensure your app complies with the Additional requirements for specific API scopes, which includes undergoing an annual security assessment if your app accesses restricted scope Google users' data from or through a third-party server.
    2. Ensure your app is one of the allowed types specified in the Limited Use section of the Additional requirements for specific API scopes page.
    3. If your app is a task automation platform, your demonstration video must showcase how multiple API workflows are created and automated, and in which directions user data flows.

    4. Prepare a video that fully demonstrates how a user initiates and grants access to the requested scopes and shows, in detail, the usage of the granted sensitive and restricted scopes in the app. Upload the video to YouTube Studio and set Visibility as Unlisted. You need to provide a link to the demonstration video in the YouTube link field.

      1. Show the OAuth grant process that users will experience, in English. This includes the consent flow and, if you use Google Sign-In, the sign-in flow.
      2. Show that the OAuth consent screen correctly displays the App Name.
      3. Show that the browser address bar of the OAuth consent screen correctly includes your app's OAuth client ID.
      4. To show how the data will be used, demonstrate the functionality that's enabled by each sensitive and restricted scope that you request.
      5. If you use multiple clients, and therefore have multiple OAuth client IDs, show how the data is accessed on each OAuth client.
    5. Select your permitted application type from the "What features will you use?" list.
    6. Describe how you will use the restricted scopes in your app and why more limited scopes aren't sufficient.

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

पुष्टि की ज़रूरी शर्तों के अपवाद

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

निजी इस्तेमाल के लिए

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

डेवलपमेंट, टेस्टिंग या स्टेजिंग टियर में इस्तेमाल किए गए प्रोजेक्ट

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

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

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

सिर्फ़ सेवा के मालिकाना हक वाला डेटा

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

सेवा खातों के बारे में जानने के लिए, Google Cloud के दस्तावेज़ में सेवा खाते देखें. सेवा खाते का इस्तेमाल करने के निर्देशों के लिए, सर्वर से सर्वर ऐप्लिकेशन के लिए OAuth 2.0 का इस्तेमाल करना देखें.

केवल आंतरि‍क उपयोग के लि‍ए

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

पूरे डोमेन में इंस्टॉलेशन

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

अक्सर पूछे जाने वाले सवालों में, अपने ऐप्लिकेशन को पूरे डोमेन में इंस्टॉल करने का तरीका जानें. इसके लिए, मेरे ऐप्लिकेशन के उपयोगकर्ताओं के पास दूसरे Google Workspace डोमेन के एंटरप्राइज़ खाते हैं सवाल देखें.