Google ने ऐप्लिकेशन के ऐक्सेस कंट्रोल की सेटिंग लॉन्च की है. इससे Google Workspace for Education के एडमिन, यह कंट्रोल कर पाएंगे कि जब उपयोगकर्ता अपने Google Workspace for Education खातों से साइन-इन करेंगे, तो तीसरे पक्ष के ऐप्लिकेशन उनके संगठन के Google डेटा को कैसे ऐक्सेस करेंगे. तीसरे पक्ष के ऐप्लिकेशन डेवलपर को कुछ भी करने की ज़रूरत नहीं है. हालांकि, नीचे कुछ सबसे सही तरीके दिए गए हैं. इनसे अन्य डेवलपर को मदद मिली है.
इंक्रीमेंटल OAuth का इस्तेमाल करें
शुरुआत में, सिर्फ़ उन दायरों का अनुरोध करने के लिए इंक्रीमेंटल ऑथराइज़ेशन का इस्तेमाल किया जा सकता है जो आपका ऐप्लिकेशन शुरू करने के लिए ज़रूरी हैं. इसके बाद, नई अनुमतियों की ज़रूरत पड़ने पर अतिरिक्त दायरों का अनुरोध किया जा सकता है. इसके बाद, ऐप्लिकेशन कॉन्टेक्स्ट, उपयोगकर्ता को अनुरोध की वजह बताता है.
साइन-इन करते समय, आपका ऐप्लिकेशन बुनियादी दायरों का अनुरोध करता है, जैसे कि साइन-इन के दायरे वाली प्रोफ़ाइल और आपके ऐप्लिकेशन को इस्तेमाल करने के लिए ज़रूरी दूसरे शुरुआती दायरे. बाद में, जब उपयोगकर्ता किसी ऐसी कार्रवाई को करना चाहता है जिसके लिए ज़्यादा स्कोप की ज़रूरत होती है, तो आपका ऐप्लिकेशन उन ज़्यादा स्कोप का अनुरोध करता है. साथ ही, उपयोगकर्ता सहमति वाली स्क्रीन से सिर्फ़ नए स्कोप को अनुमति देता है.
Google Classroom के लिए ऐड-ऑन बनाते समय, आपको Google Workspace Marketplace के दिशा-निर्देशों का पालन करना चाहिए. इनमें, उन OAuth स्कोप की पूरी सूची देना शामिल है जिनकी आपके ऐप्लिकेशन को ज़रूरत है. ऐसा इसलिए ज़रूरी है, ताकि एडमिन यह समझ सके कि डोमेन के उपयोगकर्ता से किन स्कोप के लिए सहमति मांगी जा रही है.
पक्का करें कि सभी ऐप्लिकेशन की पुष्टि OAuth की मदद से की गई हो
Google API को ऐक्सेस करने वाले सभी ऐप्लिकेशन को यह पुष्टि करनी होगी कि वे Google की एपीआई सेवाओं की उपयोगकर्ता के डेटा से जुड़ी नीति में बताए गए मकसद के मुताबिक, अपनी पहचान और मकसद को सही तरीके से दिखाते हैं. अगर आपके पास Google API का इस्तेमाल करने वाले कई ऐप्लिकेशन हैं, तो पक्का करें कि हर ऐप्लिकेशन की पुष्टि की जा चुकी हो. एडमिन, पुष्टि किए गए आपके ब्रैंड से जुड़े सभी OAuth क्लाइंट आईडी देख सकते हैं. एडमिन को गलत OAuth क्लाइंट आईडी कॉन्फ़िगर करने से रोकने के लिए, टेस्टिंग और प्रोडक्शन के लिए अलग-अलग Google Cloud प्रोजेक्ट का इस्तेमाल करें. साथ ही, उन सभी OAuth क्लाइंट आईडी को मिटाएं जिनका इस्तेमाल नहीं किया जा रहा है.
OAuth API की पुष्टि करने की प्रोसेस का इस्तेमाल, Google Cloud Platform यह पक्का करने के लिए करता है कि संवेदनशील या पाबंदी वाले स्कोप का अनुरोध करने वाले ऐप्लिकेशन सुरक्षित हों और नियमों का पालन करते हों. पुष्टि करने की प्रोसेस से, Google Cloud के उपयोगकर्ताओं और डेटा को बिना अनुमति के ऐक्सेस होने से बचाने में मदद मिलती है.
संवेदनशील या पाबंदी वाले दायरों का अनुरोध करने वाले ऐप्लिकेशन को, Google API सेवाओं के उपयोगकर्ता के डेटा से जुड़ी नीति का पालन करना होगा. इस नीति के तहत, ऐप्लिकेशन को उपयोगकर्ता के डेटा को सुरक्षित रखना होता है. साथ ही, डेटा का इस्तेमाल सिर्फ़ उन कामों के लिए करना होता है जिनके लिए उपयोगकर्ता ने अनुमति दी है. ऐप्लिकेशन को सुरक्षा से जुड़ी स्वतंत्र जांच से भी गुज़रना पड़ सकता है. इससे यह पुष्टि की जा सकेगी कि वे Google Cloud की सुरक्षा से जुड़ी ज़रूरी शर्तों को पूरा करते हैं.
ध्यान दें, OAuth API की पुष्टि की प्रोसेस पूरी होने में कई हफ़्ते लग सकते हैं. आपके ऐप्लिकेशन की पुष्टि होने के बाद, आपके पास संवेदनशील या पाबंदी वाले उन स्कोप के लिए अनुरोध करने का विकल्प होता है जिनकी आपको ज़रूरत है.
ज़्यादा जानकारी के लिए, OAuth API की पुष्टि से जुड़े अक्सर पूछे जाने वाले सवाल देखें.
एक से ज़्यादा OAuth क्लाइंट आईडी मैनेज करना
किसी Google Cloud प्रोजेक्ट में कई OAuth क्लाइंट आईडी हो सकते हैं. ऐसे में, डोमेन एडमिन को आपके ऐक्सेस को कई बार कॉन्फ़िगर करना पड़ सकता है.
पक्का करना कि OAuth क्लाइंट आईडी सही हों
Google OAuth के साथ इंटिग्रेट करने के लिए, किन OAuth क्लाइंट आईडी का इस्तेमाल किया जा रहा है, यह जानने के लिए अपनी डेवलपमेंट टीम से संपर्क करें. टेस्टिंग और प्रोडक्शन के लिए, दो अलग-अलग Google Cloud प्रोजेक्ट का इस्तेमाल करें. इससे एडमिन को यह समझने में मदद मिलेगी कि किन OAuth क्लाइंट आईडी को कॉन्फ़िगर करना है. अपने प्रोडक्शन प्रोजेक्ट से, ऐसे सभी क्लाइंट आईडी मिटाएं जो अब काम नहीं करते या पुराने हो चुके हैं.
CSV फ़ाइल अपलोड करें
अगर आपके पास एक से ज़्यादा क्लाइंट आईडी हैं, तो हमारा सुझाव है कि आप CSV फ़ाइल में एक साथ कई फ़ाइलें अपलोड करने के विकल्प का इस्तेमाल करें. इससे एडमिन, आपके सभी ऐप्लिकेशन को तुरंत कॉन्फ़िगर कर पाएंगे.
ये फ़ील्ड हैं:
| फ़ील्ड | ज़रूरी है | नोट |
|---|---|---|
| ऐप्लिकेशन का नाम | नहीं | ऐप्लिकेशन का नाम डालें. CSV फ़ाइल में ऐप्लिकेशन के नाम में किए गए बदलाव, एडमिन कंसोले में अपडेट नहीं होते. |
| टाइप | हां | वेब ऐप्लिकेशन, Android या iOS में से कोई एक. |
| आईडी | हां | वेब ऐप्लिकेशन के लिए, ऐप्लिकेशन को जारी किया गया OAuth क्लाइंट आईडी डालें. Android और iOS ऐप्लिकेशन के लिए, OAuth क्लाइंट आईडी या वह पैकेज या बंडल आईडी डालें जिसे ऐप्लिकेशन, Google Play या Apple App Store में इस्तेमाल करता है. |
| संगठन इकाई | हां | इसे ग्राहक भरता है. अपने पूरे डोमेन पर ऐप्लिकेशन ऐक्सेस सेटिंग लागू करने के लिए, फ़ॉरवर्ड स्लैश ('/') डालें. संगठन की चुनिंदा इकाइयों पर ऐक्सेस सेटिंग लागू करने के लिए, हर इकाई के लिए स्प्रेडशीट में एक लाइन जोड़ें. साथ ही, ऐप्लिकेशन का नाम, टाइप, और आईडी दोहराएं. उदाहरण के लिए, '/org_unit_1/sub_unit_1'. |
| ऐक्सेस | हां | इनमें से कोई एक भरोसेमंद, ब्लॉक किया गया या सीमित. |
OAuth से जुड़ी गड़बड़ियां
इन नए एडमिन कंट्रोल की मदद से, गड़बड़ी के दो मैसेज जोड़े गए हैं.
- गड़बड़ी 400: access_not_configured - यह गड़बड़ी तब दिखती है, जब आपके ऐप्लिकेशन को कॉन्फ़िगर न किए जाने की वजह से, OAuth कनेक्शन अस्वीकार कर दिया जाता है.
- गड़बड़ी 400: admin_policy_enforced - यह गड़बड़ी तब दिखती है, जब एडमिन ने आपके ऐप्लिकेशन को ब्लॉक कर दिया हो और इसलिए OAuth कनेक्शन अस्वीकार कर दिया गया हो.
जिन उपयोगकर्ताओं की उम्र 18 साल से कम के तौर पर अपडेट की गई है
एडमिन, 18 साल से कम उम्र के उपयोगकर्ताओं के लिए, तीसरे पक्ष के कॉन्फ़िगर नहीं किए गए ऐप्लिकेशन का ऐक्सेस मैनेज कर सकते हैं. अगर किसी उपयोगकर्ता को "ऐक्सेस ब्लॉक किया गया: आपके संस्थान के एडमिन को [ऐप्लिकेशन का नाम] की समीक्षा करनी होगी" गड़बड़ी का मैसेज मिलता है, तो उसे गड़बड़ी के मैसेज में जाकर ऐक्सेस का अनुरोध करना होगा. इससे उनके एडमिन को तीसरे पक्ष के ऐप्लिकेशन की समीक्षा करने में मदद मिलती है. एडमिन यह तय कर सकते हैं कि तीसरे पक्ष के ऐप्लिकेशन को अनुमति देनी है या ब्लॉक करना है.