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

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

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

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

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

यहां दिए गए डायग्राम में, 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 क्लाइंट आईडी
उपयोगकर्ता के मालिकाना हक वाले डेटा को ऐक्सेस करने का अनुरोध करने के लिए इस्तेमाल किया गया क्रेडेंशियल. यह मुख्य क्रेडेंशियल है. इसका इस्तेमाल, 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 को कॉल करने के लिए सेवा खाते की पहचान का इस्तेमाल करता है, ताकि उपयोगकर्ताओं को सीधे तौर पर शामिल न किया जाए. सेवा खातों का इस्तेमाल, उपयोगकर्ता का डेटा ऐक्सेस करने के लिए नहीं किया जा सकता. आम तौर पर, Workspace API का इस्तेमाल करके डेटा ऐक्सेस किया जाता है. हालांकि, सेवा खाता, डोमेन-वाइड डेलिगेशन ऑफ़ अथॉरिटी को लागू करके, उपयोगकर्ता के डेटा को ऐक्सेस कर सकता है. ज़्यादा जानकारी के लिए, सेवा खातों के बारे में जानकारी लेख पढ़ें.

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

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

अगला चरण

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