पुष्टि करने और अनुमति देने के बारे में जानें

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

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

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

ध्यान दें: इस खास जानकारी में, Google Workspace API के लिए पुष्टि करने और अनुमति देने पर फ़ोकस किया गया है. इस दस्तावेज़ में दी गई कुछ जानकारी, अन्य Google API से जुड़ी नहीं हो सकती.

प्रोसेस से जुड़ी खास जानकारी

यहां दिए गए डायग्राम में, Google Workspace API के लिए पुष्टि करने और अनुमति देने के मुख्य चरण दिखाए गए हैं:

पहली इमेज. पुष्टि करने और अनुमति देने की सुविधा लागू करने के मुख्य चरण

1. अपने Google Cloud प्रोजेक्ट और ऐप्लिकेशन को कॉन्फ़िगर करें: डेवलपमेंट के दौरान, Google Cloud Console में अपना ऐप्लिकेशन रजिस्टर करें. साथ ही, अनुमति के स्कोप और ऐक्सेस क्रेडेंशियल तय करें, ताकि एपीआई कुंजी, असली उपयोगकर्ता के क्रेडेंशियल या सेवा खाते के क्रेडेंशियल की मदद से, अपने ऐप्लिकेशन की पुष्टि की जा सके.

2. ऐक्सेस करने के लिए अपने ऐप्लिकेशन की पुष्टि करें: जब आपका ऐप्लिकेशन चलता है, तब रजिस्टर किए गए ऐक्सेस क्रेडेंशियल का आकलन किया जाता है. अगर आपका ऐप्लिकेशन, असली उपयोगकर्ता के तौर पर पुष्टि कर रहा है, तो आपको साइन इन करने का प्रॉम्प्ट दिख सकता है.

3. संसाधनों का अनुरोध करना: जब आपके ऐप्लिकेशन को Google के संसाधनों को ऐक्सेस करने की ज़रूरत होती है, तब वह Google से अनुरोध करता है. इसके लिए, वह ऐक्सेस के उन स्कोप का इस्तेमाल करता है जिन्हें आपने पहले रजिस्टर किया था.

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

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

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

7. अनुरोध किए गए संसाधनों को ऐक्सेस करना: आपका ऐप्लिकेशन, Google से मिले ऐक्सेस टोकन का इस्तेमाल करके, काम के एपीआई को कॉल करता है और संसाधनों को ऐक्सेस करता है.

8. रीफ़्रेश टोकन पाएं (ज़रूरी नहीं): अगर आपके ऐप्लिकेशन को एक ऐक्सेस टोकन की समयसीमा के बाद भी Google API को ऐक्सेस करने की ज़रूरत है, तो वह रीफ़्रेश टोकन पा सकता है.

9. ज़्यादा संसाधनों का अनुरोध करना: अगर ज़्यादा ऐक्सेस की ज़रूरत होती है, तो आपका ऐप्लिकेशन उपयोगकर्ता से ऐक्सेस के नए स्कोप देने के लिए कहता है. इससे ऐक्सेस टोकन पाने के लिए एक नया अनुरोध किया जाता है (तीसरे से छठे चरण तक).

अहम शब्दावली

यहां दी गई सूची में, पुष्टि करने और अनुमति देने से जुड़े शब्दों के बारे में बताया गया है:

पुष्टि करना

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

उपयोगकर्ता की पुष्टि करना

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

ऐप्लिकेशन की पुष्टि करना

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

अनुमति

डेटा ऐक्सेस करने या कार्रवाइयां करने के लिए, प्रिंसिपल के पास मौजूद अनुमतियां या "अधिकार". आपका ऐप्लिकेशन, उपयोगकर्ता को यह सूचना देकर अनुमति का अनुरोध करता है कि ऐप्लिकेशन उसकी ओर से कार्रवाई करना चाहता है. अगर उपयोगकर्ता अनुरोध को स्वीकार करता है, तो ऐप्लिकेशन अपने यूनीक क्रेडेंशियल का इस्तेमाल करके Google से ऐक्सेस टोकन हासिल करता है.

क्रेडेंशियल

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

एपीआई पासकोड

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

OAuth 2 क्लाइंट आईडी

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

क्लाइंट सीक्रेट

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

सेवा खाते की कुंजियां

इसका इस्तेमाल सेवा खाते करते हैं, ताकि Google की किसी सेवा को ऐक्सेस करने की अनुमति मिल सके.

सेवा खाता

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

स्कोप

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

अनुमति देने वाला सर्वर

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

ऑथराइज़ेशन कोड

यह ऑथराइज़ेशन सर्वर से भेजा गया कोड होता है. इसका इस्तेमाल ऐक्सेस टोकन पाने के लिए किया जाता है. कोड की ज़रूरत सिर्फ़ तब होती है, जब आपके ऐप्लिकेशन का टाइप वेब सर्वर ऐप्लिकेशन या इंस्टॉल किया गया ऐप्लिकेशन हो.

ऐक्सेस टोकन

यह एक ऐसा टोकन होता है जो Google Workspace API का ऐक्सेस देता है. एक ऐक्सेस टोकन, कई एपीआई को अलग-अलग लेवल का ऐक्सेस दे सकता है. इसे स्कोप कहा जाता है. आपके ऐप्लिकेशन का ऑथराइज़ेशन कोड, ऐक्सेस टोकन का अनुरोध करता है. साथ ही, इनका इस्तेमाल Google Workspace API को चालू करने के लिए करता है.

संसाधन सर्वर

वह सर्वर जो आपके ऐप्लिकेशन को कॉल करने के लिए एपीआई को होस्ट करता है.

OAuth 2.0 फ़्रेमवर्क

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

मूल रकम

यह एक इकाई होती है. इसे पहचान भी कहा जाता है. इसे किसी संसाधन का ऐक्सेस दिया जा सकता है. Google Workspace API, दो तरह के प्रिंसिपल के साथ काम करते हैं: उपयोगकर्ता खाते और सेवा खाते. ज़्यादा जानकारी के लिए, प्रिंसिपल देखें.

डेटा टाइप

पुष्टि करने और अनुमति देने के संदर्भ में, डेटा टाइप का मतलब उस इकाई से है जिसके पास वह डेटा है जिसे आपका ऐप्लिकेशन ऐक्सेस करने की कोशिश कर रहा है. डेटा टाइप तीन तरह के होते हैं:

सार्वजनिक डोमेन में उपलब्ध डेटा

ऐसा डेटा जिसे कोई भी ऐक्सेस कर सकता है. जैसे, Google Maps का कुछ डेटा. इस डेटा को आम तौर पर, एपीआई पासकोड का इस्तेमाल करके ऐक्सेस किया जाता है.

असली उपयोगकर्ता का डेटा

किसी असली उपयोगकर्ता या ग्रुप का डेटा. जैसे, किसी उपयोगकर्ता की Google Drive फ़ाइलें. इस डेटा टाइप को आम तौर पर, OAuth 2 क्लाइंट आईडी या सेवा खाते का इस्तेमाल करके ऐक्सेस किया जाता है.

क्लाउड डेटा

Google Cloud प्रोजेक्ट के मालिकाना हक वाला डेटा. आम तौर पर, इस डेटा टाइप को कोई सेवा खाता ऐक्सेस करता है.

उपयोगकर्ता की सहमति

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

ऐप्लिकेशन टाइप

आपको किस तरह का ऐप्लिकेशन बनाना है. Google Cloud Console का इस्तेमाल करके क्रेडेंशियल बनाते समय, आपसे ऐप्लिकेशन टाइप चुनने के लिए कहा जाता है. ऐप्लिकेशन के टाइप में ये शामिल हैं: वेब ऐप्लिकेशन (JavaScript), Android, Chrome ऐप्लिकेशन, iOS, टीवी और सीमित इनपुट वाले डिवाइस, डेस्कटॉप ऐप्लिकेशन (इसे "इंस्टॉल किया गया ऐप्लिकेशन" भी कहा जाता है), और यूनिवर्सल विंडोज़ प्लैटफ़ॉर्म (यूडब्ल्यूपी).

सेवा खाता

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

पूरे डोमेन के लिए, सौंपे जाने की सुविधा

यह एडमिन से जुड़ी एक सुविधा है. इसकी मदद से, किसी ऐप्लिकेशन को Google Workspace संगठन के उपयोगकर्ताओं की ओर से, उनका डेटा ऐक्सेस करने की अनुमति दी जा सकती है. डोमेन-वाइड डेलिगेशन का इस्तेमाल, उपयोगकर्ता के डेटा पर एडमिन से जुड़े टास्क करने के लिए किया जा सकता है. इस तरह से अधिकार सौंपने के लिए, Google Workspace एडमिन OAuth 2.0 के साथ सेवा खातों का इस्तेमाल करते हैं. इस सुविधा के असरदार होने की वजह से, सिर्फ़ सुपर एडमिन के पास डोमेन-वाइड डेलिगेशन ऑफ़ अथॉरिटी की सुविधा चालू करने का विकल्प होता है. ज़्यादा जानकारी के लिए, किसी सेवा खाते को पूरे डोमेन का अधिकार सौंपना लेख पढ़ें.

अगला चरण

अपने ऐप्लिकेशन की उस स्क्रीन को कॉन्फ़िगर करें जहां OAuth के लिए सहमति दी जाती है. इससे यह पक्का किया जा सकेगा कि उपयोगकर्ताओं को यह समझ में आ जाए कि आपके ऐप्लिकेशन के पास उनके डेटा का कौनसा ऐक्सेस है और वे उसे स्वीकार कर सकें.