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