Google ने ऐप्लिकेशन के ऐक्सेस को कंट्रोल करने की सेटिंग लॉन्च की हैं. इससे Google Workspace for Education के एडमिन को यह कंट्रोल करने में आसानी होगी कि तीसरे पक्ष के ऐप्लिकेशन, उनके संगठन के Google डेटा को कैसे ऐक्सेस करें. ऐसा तब होगा, जब उपयोगकर्ता अपने Google Workspace for Education खातों से साइन इन करेंगे. तीसरे पक्ष के ऐप्लिकेशन डेवलपर को कोई कार्रवाई करने की ज़रूरत नहीं है. हालांकि, यहां कुछ सबसे सही तरीके दिए गए हैं. अन्य डेवलपर को ये तरीके मददगार लगे हैं.
इंक्रीमेंटल OAuth का इस्तेमाल करना
इंक्रीमेंटल ऑथराइज़ेशन का इस्तेमाल करके, शुरुआत में सिर्फ़ उन स्कोप का अनुरोध किया जा सकता है जिनकी ज़रूरत ऐप्लिकेशन को शुरू करने के लिए होती है. इसके बाद, नई अनुमतियों की ज़रूरत पड़ने पर, अतिरिक्त स्कोप का अनुरोध किया जा सकता है. इसके बाद, ऐप्लिकेशन कॉन्टेक्स्ट से उपयोगकर्ता को अनुरोध की वजह पता चलती है.
साइन इन करने के दौरान, आपका ऐप्लिकेशन बुनियादी स्कोप का अनुरोध करता है. जैसे, साइन इन स्कोप प्रोफ़ाइल और अन्य शुरुआती स्कोप, जिनकी ज़रूरत आपके ऐप्लिकेशन को काम करने के लिए होती है. बाद में, जब उपयोगकर्ता को कोई ऐसी कार्रवाई करनी होती है जिसके लिए अतिरिक्त स्कोप की ज़रूरत होती है, तो आपका ऐप्लिकेशन उन अतिरिक्त स्कोप का अनुरोध करता है. इसके बाद, उपयोगकर्ता सहमति वाली स्क्रीन से सिर्फ़ नए स्कोप को अनुमति देता है.
Google Classroom का ऐड-ऑन बनाते समय, आपको Google Workspace Marketplace की गाइडलाइन का पालन करना चाहिए. इसके तहत, आपको OAuth स्कोप की पूरी सूची देनी होगी, जिनकी आपके ऐप्लिकेशन को ज़रूरत है. यह इसलिए ज़रूरी है, ताकि एडमिन को यह पता चल सके कि डोमेन के किसी उपयोगकर्ता से किन स्कोप के लिए सहमति मांगी गई है.
पक्का करें कि सभी ऐप्लिकेशन की OAuth से पुष्टि की गई हो
Google API का इस्तेमाल करने वाले सभी ऐप्लिकेशन को यह पुष्टि करनी होगी कि वे Google API सेवाओं की उपयोगकर्ता के डेटा से जुड़ी नीति में बताई गई अपनी पहचान और मकसद को सटीक तरीके से दिखाते हैं. अगर 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 क्लाइंट आईडी का इस्तेमाल किया जा रहा है. एडमिन को यह समझने में मदद करने के लिए कि किन OAuth क्लाइंट आईडी को कॉन्फ़िगर करना है, टेस्टिंग और प्रोडक्शन के लिए दो अलग-अलग Google Cloud प्रोजेक्ट का इस्तेमाल करें. अपने प्रोडक्शन प्रोजेक्ट से, बंद किए गए या पुराने क्लाइंट आईडी मिटाएं.
CSV फ़ाइल अपलोड करें
अगर आपके पास कई क्लाइंट आईडी हैं, तो हमारा सुझाव है कि आप CSV फ़ाइल एक साथ कई फ़ाइलें अपलोड करने का विकल्प इस्तेमाल करें. इससे एडमिन, आपके सभी ऐप्लिकेशन को तुरंत कॉन्फ़िगर कर पाएंगे.
ये फ़ील्ड हैं:
| फ़ील्ड | ज़रूरी है | नोट |
|---|---|---|
| ऐप्लिकेशन का नाम | नहीं | ऐप्लिकेशन का नाम डालें. CSV फ़ाइल में ऐप्लिकेशन के नाम में किए गए बदलाव, Admin console में अपडेट नहीं होते. |
| टाइप | हां | वेब ऐप्लिकेशन, 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 साल से कम उम्र के उपयोगकर्ताओं के लिए बनाए गए तीसरे पक्ष के उन ऐप्लिकेशन का ऐक्सेस मैनेज कर सकते हैं जिन्हें कॉन्फ़िगर नहीं किया गया है. अगर किसी उपयोगकर्ता को "ऐक्सेस ब्लॉक किया गया: आपके संस्थान के एडमिन को [ऐप्लिकेशन का नाम] की समीक्षा करनी होगी" वाली गड़बड़ी का मैसेज मिलता है, तो उसे गड़बड़ी के मैसेज में जाकर ऐक्सेस का अनुरोध करना होगा. इससे एडमिन, तीसरे पक्ष के ऐप्लिकेशन की समीक्षा कर सकता है. एडमिन यह तय कर सकते हैं कि तीसरे पक्ष के ऐप्लिकेशन को अनुमति देनी है या उन्हें ब्लॉक करना है.