पुष्टि और अनुमति, ऐसे तरीके हैं जिनका इस्तेमाल पहचान की पुष्टि करने और संसाधनों को ऐक्सेस करने के लिए किया जाता है. इस दस्तावेज़ में उन मुख्य शब्दों के बारे में बताया गया है जिनके बारे में आपको अपने ऐप्लिकेशन में पुष्टि करने और अनुमति देने की सुविधा लागू करने से पहले पता होना चाहिए.
पुष्टि करने से पता चलता है कि अनुरोध किस ने किया है. अनुमति से यह पता चलता है कि अनुरोध करने वाला व्यक्ति कौनसे संसाधन ऐक्सेस कर सकता है और उसके पास किस लेवल का ऐक्सेस है. अनुमति पाने के लिए, पुष्टि करना ज़रूरी है. अनुरोध करने वाले व्यक्ति की पहचान की पुष्टि किए बिना, यह तय नहीं किया जा सकता कि कौनसे संसाधन ऐक्सेस करने हैं. ज़्यादा जानकारी के लिए, ज़रूरी शब्दावली वाला सेक्शन देखें.
होटल बुक करने के इस आसान उदाहरण पर ध्यान दें. होटल पहुंचने पर, फ़्रंट डेस्क क्लर्क आपसे आईडी मांगता है, ताकि आपके बुकिंग की पुष्टि की जा सके. आपके आईडी से होटल में आपकी पुष्टि की जाती है. फ़्रंट डेस्क क्लर्क आपको होटल का कमरा कार्ड देता है. इस पासकोड से, आपको होटल के कुछ संसाधनों का ऐक्सेस मिलता है. जैसे, आपका होटल का कमरा, जिम, और बिज़नेस सेंटर. होटल की चाबी से, आपको उन संसाधनों को ऐक्सेस करने की अनुमति मिलती है.
प्रोसेस से जुड़ी खास जानकारी
नीचे दिए गए डायग्राम में, Google Workspace के एपीआई के लिए पुष्टि करने और अनुमति देने के हाई-लेवल चरण दिखाए गए हैं:
अपना Google Cloud प्रोजेक्ट और ऐप्लिकेशन कॉन्फ़िगर करना: डेवलपमेंट के दौरान, आपको Google Cloud Console में अपना ऐप्लिकेशन रजिस्टर करना होता है. साथ ही, अनुमति के दायरे और ऐक्सेस क्रेडेंशियल तय करने होते हैं, ताकि आपके ऐप्लिकेशन की पुष्टि, एपीआई पासकोड, असली उपयोगकर्ता के क्रेडेंशियल या सेवा खाते के क्रेडेंशियल से की जा सके.
ऐक्सेस के लिए अपने ऐप्लिकेशन की पुष्टि करना: जब आपका ऐप्लिकेशन चलता है, तो ऐक्सेस के लिए रजिस्टर किए गए क्रेडेंशियल का आकलन किया जाता है. अगर आपका ऐप्लिकेशन, असली उपयोगकर्ता के तौर पर पुष्टि कर रहा है, तो आपको साइन इन करने का प्रॉम्प्ट दिख सकता है.
संसाधनों का अनुरोध करना: जब आपके ऐप्लिकेशन को Google के संसाधनों का ऐक्सेस चाहिए होता है, तब वह आपके ऐप्लिकेशन के लिए पहले से रजिस्टर किए गए ऐक्सेस के दायरे का इस्तेमाल करके, Google से अनुरोध करता है.
उपयोगकर्ता की सहमति मांगना: अगर आपका ऐप्लिकेशन असली उपयोगकर्ता के तौर पर पुष्टि कर रहा है, तो Google, OAuth सहमति वाली स्क्रीन दिखाता है, ताकि उपयोगकर्ता यह तय कर सके कि आपके ऐप्लिकेशन को अनुरोध किए गए डेटा का ऐक्सेस दिया जाए या नहीं.
संसाधनों के लिए अनुमति वाला अनुरोध भेजना: अगर उपयोगकर्ता, ऐक्सेस के दायरों के लिए सहमति देता है, तो आपका ऐप्लिकेशन क्रेडेंशियल और उपयोगकर्ता की अनुमति वाले ऐक्सेस के दायरों को एक अनुरोध में बंडल करता है. ऐक्सेस टोकन पाने के लिए, अनुरोध Google के ऑथराइज़ेशन सर्वर को भेजा जाता है.
Google, ऐक्सेस टोकन दिखाता है: ऐक्सेस टोकन में, ऐक्सेस के लिए दिए गए स्कोप की सूची होती है. अगर ऐक्सेस के लिए अनुरोध किए गए स्कोप की तुलना में, ऐक्सेस के लिए मिले स्कोप की सूची ज़्यादा सीमित है, तो आपका ऐप्लिकेशन टोकन से सीमित की गई सभी सुविधाओं को बंद कर देता है.
ऐसे संसाधनों को ऐक्सेस करना जिनका अनुरोध किया गया है: आपका ऐप्लिकेशन, काम के एपीआई को ट्रिगर करने और संसाधनों को ऐक्सेस करने के लिए, Google के ऐक्सेस टोकन का इस्तेमाल करता है.
रीफ़्रेश टोकन पाना (ज़रूरी नहीं): अगर आपके ऐप्लिकेशन को किसी ऐक्सेस टोकन के लाइफ़टाइम के बाद भी Google API का ऐक्सेस चाहिए, तो वह रीफ़्रेश टोकन पा सकता है.
ज़्यादा संसाधनों का अनुरोध करना: अगर ज़्यादा ऐक्सेस की ज़रूरत है, तो आपका ऐप्लिकेशन उपयोगकर्ता से ऐक्सेस के नए स्कोप देने के लिए कहता है. इससे, ऐक्सेस टोकन पाने के लिए नया अनुरोध किया जाता है (तीसरा से छठा चरण).
ज़रूरी शब्दावली
पुष्टि और अनुमति से जुड़े शब्दों की सूची यहां दी गई है:
- पुष्टि करना
यह पक्का करना कि प्रिंसिपल, जो उपयोगकर्ता या उपयोगकर्ता की ओर से काम करने वाला ऐप्लिकेशन हो सकता है, वह वही है जो वह दावा करता है. Google Workspace के ऐप्लिकेशन लिखते समय, आपको पुष्टि करने के इन तरीकों के बारे में पता होना चाहिए:
- उपयोगकर्ता की पुष्टि करना
- उपयोगकर्ता के आपके ऐप्लिकेशन में पुष्टि करने (साइन इन करने) की प्रोसेस. उपयोगकर्ता की पुष्टि आम तौर पर साइन इन करने की प्रोसेस के ज़रिए की जाती है. इसमें उपयोगकर्ता, ऐप्लिकेशन में अपनी पहचान की पुष्टि करने के लिए, उपयोगकर्ता नाम और पासवर्ड के कॉम्बिनेशन का इस्तेमाल करता है. उपयोगकर्ता की पुष्टि करने की सुविधा को ऐप्लिकेशन में शामिल करने के लिए, Google से साइन इन करें का इस्तेमाल किया जा सकता है.
- ऐप्लिकेशन की पुष्टि करना
- ऐप्लिकेशन को चलाने वाले उपयोगकर्ता की ओर से, ऐप्लिकेशन के सीधे Google की सेवाओं की पुष्टि करने की प्रोसेस. आम तौर पर, ऐप्लिकेशन की पुष्टि करने के लिए, आपके ऐप्लिकेशन के कोड में पहले से बनाए गए क्रेडेंशियल का इस्तेमाल किया जाता है.
- अनुमति
प्रिंसिपल के पास डेटा ऐक्सेस करने या कार्रवाइयां करने के लिए, अनुमतियां या "अधिकार" होते हैं. अनुमति देने की प्रोसेस, आपके ऐप्लिकेशन में लिखे गए कोड की मदद से पूरी की जाती है. यह कोड उपयोगकर्ता को बताता है कि ऐप्लिकेशन उसकी ओर से कार्रवाई करना चाहता है. अगर अनुमति मिल जाती है, तो Google से ऐक्सेस टोकन पाने के लिए, आपके ऐप्लिकेशन के यूनीक क्रेडेंशियल का इस्तेमाल किया जाता है. इस टोकन का इस्तेमाल, डेटा ऐक्सेस करने या कार्रवाइयां करने के लिए किया जाता है.
- क्रेडेंशियल
सॉफ़्टवेयर की सुरक्षा में इस्तेमाल होने वाला पहचान फ़ॉर्म. पुष्टि करने के मामले में, क्रेडेंशियल अक्सर उपयोगकर्ता नाम और पासवर्ड का कॉम्बिनेशन होता है. Google Workspace के एपीआई के लिए अनुमति देने के मामले में, क्रेडेंशियल आम तौर पर पहचान का कोई तरीका होता है. जैसे, एक यूनीक सीक्रेट स्ट्रिंग, जिसकी जानकारी सिर्फ़ ऐप्लिकेशन डेवलपर और पुष्टि करने वाले सर्वर के पास होती है. Google, पुष्टि करने के लिए इन क्रेडेंशियल का इस्तेमाल करता है: एपीआई पासकोड, OAuth 2.0 क्लाइंट आईडी, और सेवा खाते.
- एपीआई पासकोड
- सार्वजनिक डेटा का ऐक्सेस पाने के लिए इस्तेमाल किया जाने वाला क्रेडेंशियल. जैसे, Maps API का इस्तेमाल करके उपलब्ध कराया गया डेटा या Google Workspace की शेयर करने की सेटिंग में "इंटरनेट पर मौजूद कोई भी व्यक्ति जिसे यह लिंक मिला है" सेटिंग का इस्तेमाल करके शेयर की गई Google Workspace फ़ाइलें.
- OAuth 2 क्लाइंट आईडी
- उपयोगकर्ता के मालिकाना हक वाले डेटा को ऐक्सेस करने का अनुरोध करने के लिए इस्तेमाल किया जाने वाला क्रेडेंशियल. यह मुख्य क्रेडेंशियल होता है. इसका इस्तेमाल, Google Workspace के एपीआई का इस्तेमाल करके डेटा ऐक्सेस करने का अनुरोध करते समय किया जाता है. इस क्रेडेंशियल के लिए, उपयोगकर्ता की सहमति ज़रूरी है.
- क्लाइंट सीक्रेट
- वर्ण की एक स्ट्रिंग, जिसे सिर्फ़ आपके ऐप्लिकेशन और अनुमति देने वाले सर्वर को पता होना चाहिए. क्लाइंट सीक्रेट, अनुरोध करने वाले सिर्फ़ उन लोगों को टोकन देकर, उपयोगकर्ता के डेटा को सुरक्षित रखता है जिनके पास अनुमति है. आपको अपने ऐप्लिकेशन में, एन्क्रिप्ट (सुरक्षित) नहीं किया गया क्लाइंट सीक्रेट कभी शामिल नहीं करना चाहिए. हमारा सुझाव है कि आप क्लाइंट सीक्रेट को सुरक्षित तरीके से सेव करें. ज़्यादा जानकारी के लिए, क्लाइंट क्रेडेंशियल को सुरक्षित तरीके से मैनेज करना लेख पढ़ें.
- सेवा खाते की कुंजियां
- Google की किसी सेवा के लिए अनुमति पाने के लिए, सेवा खातों का इस्तेमाल किया जाता है.
- सेवा खाता
- यह एक क्रेडेंशियल है, जिसका इस्तेमाल सर्वर-टू-सर्वर इंटरैक्शन के लिए किया जाता है. जैसे, कोई ऐसा ऐप्लिकेशन जो किसी डेटा को ऐक्सेस करने या कोई कार्रवाई करने के लिए प्रोसेस के तौर पर काम करता है. सेवा खातों का इस्तेमाल, आम तौर पर क्लाउड-आधारित डेटा और ऑपरेशन ऐक्सेस करने के लिए किया जाता है. हालांकि, डोमेन के लिए ऐक्सेस देने की सुविधा के साथ इस्तेमाल करने पर, इनका इस्तेमाल उपयोगकर्ता के डेटा को ऐक्सेस करने के लिए किया जा सकता है.
- स्कोप
OAuth 2.0 यूआरआई स्ट्रिंग, जो किसी ऐप्लिकेशन को दिए गए संसाधनों या कार्रवाइयों के ऐक्सेस लेवल के बारे में बताती है. Google Workspace के लिए, अनुमति के दायरे वाले यूआरआई में Google Workspace ऐप्लिकेशन का नाम, वह किस तरह का डेटा ऐक्सेस करता है, और ऐक्सेस का लेवल शामिल होता है. आपके ऐप्लिकेशन के उपयोगकर्ता, अनुरोध किए गए स्कोप की समीक्षा कर सकते हैं और यह चुन सकते हैं कि कौनसा ऐक्सेस दिया जाए. इसके बाद, Google का पुष्टि करने वाला सर्वर, ऐक्सेस टोकन में आपके ऐप्लिकेशन को अनुमति वाले स्कोप दिखाता है. ज़्यादा जानकारी के लिए, अपने ऐप्लिकेशन के लिए स्कोप चुनने का तरीका लेख पढ़ें.
- अनुमति देने वाला सर्वर
Google का सर्वर, जो ऐप्लिकेशन के अनुरोध किए गए डेटा और ऑपरेशन को ऐक्सेस करने के लिए, ऐक्सेस टोकन का इस्तेमाल करता है.
- अनुमति कोड
ऑथराइज़ेशन सर्वर से भेजा गया कोड, जिसका इस्तेमाल ऐक्सेस टोकन पाने के लिए किया जाता है. कोड की ज़रूरत सिर्फ़ तब होती है, जब आपका ऐप्लिकेशन टाइप वेब सर्वर ऐप्लिकेशन या इंस्टॉल किया गया ऐप्लिकेशन हो.
- ऐक्सेस टोकन
Google Workspace API का ऐक्सेस देने वाला टोकन. एक ऐक्सेस टोकन, कई एपीआई को अलग-अलग लेवल का ऐक्सेस दे सकता है. इन लेवल को दायरे कहा जाता है. आपके ऐप्लिकेशन का अनुमति कोड, ऐक्सेस टोकन का अनुरोध करता है और Google Workspace के एपीआई को कॉल करने के लिए उनका इस्तेमाल करता है.
- रिसॉर्स सर्वर
वह सर्वर जो उस एपीआई को होस्ट कर रहा है जिसे आपके ऐप्लिकेशन को कॉल करना है.
- OAuth 2.0 फ़्रेमवर्क
यह एक ऐसा स्टैंडर्ड है जिसका इस्तेमाल करके, आपके ऐप्लिकेशन को “अन्य को दिया गया सुरक्षित ऐक्सेस” या ऐप्लिकेशन के उपयोगकर्ता की ओर से डेटा और ऑपरेशन का ऐक्सेस दिया जा सकता है. आपके ऐप्लिकेशन में पुष्टि करने और अनुमति देने के लिए इस्तेमाल किए गए तरीके से पता चलता है कि आपने OAuth 2.0 फ़्रेमवर्क को कैसे लागू किया है.
- प्रिंसिपल
वह इकाई जिसे किसी संसाधन का ऐक्सेस दिया जा सकता है. इसे पहचान भी कहा जाता है. Google Workspace के एपीआई, दो तरह के प्रिंसिपल के साथ काम करते हैं: उपयोगकर्ता खाते और सेवा खाते. ज़्यादा जानकारी के लिए, प्रिंसिपल देखें.
- डेटा टाइप
पुष्टि और अनुमति के संदर्भ में, डेटा टाइप से उस इकाई का मतलब है जिसके पास उस डेटा का मालिकाना हक है जिसे आपका ऐप्लिकेशन ऐक्सेस करने की कोशिश कर रहा है. डेटा टाइप तीन तरह के होते हैं:
- सार्वजनिक डोमेन का डेटा
- ऐसा डेटा जिसे कोई भी ऐक्सेस कर सकता है. जैसे, Google Maps का कुछ डेटा. आम तौर पर, इस डेटा को एपीआई पासकोड का इस्तेमाल करके ऐक्सेस किया जाता है.
- असली उपयोगकर्ता का डेटा
- किसी खास असली उपयोगकर्ता या ग्रुप का डेटा, जैसे कि किसी उपयोगकर्ता की Google Drive फ़ाइलें. आम तौर पर, इस डेटा टाइप को OAuth 2 क्लाइंट आईडी या सेवा खाते का इस्तेमाल करके ऐक्सेस किया जाता है.
- क्लाउड डेटा
- Google Cloud प्रोजेक्ट का मालिकाना हक वाला डेटा. आम तौर पर, इस डेटा टाइप को सेवा खाते से ऐक्सेस किया जाता है.
- उपयोगकर्ता की सहमति
अनुमति देने का एक चरण, जिसमें आपके ऐप्लिकेशन के उपयोगकर्ता को ऐप्लिकेशन को डेटा ऐक्सेस करने और उपयोगकर्ता की ओर से कार्रवाइयां करने की अनुमति देनी होती है.
- ऐप्लिकेशन का टाइप
आपको किस तरह का ऐप्लिकेशन बनाना है. Google Cloud कंसोल का इस्तेमाल करके क्रेडेंशियल बनाते समय, आपसे ऐप्लिकेशन का टाइप चुनने के लिए कहा जाता है. ऐप्लिकेशन के टाइप: वेब ऐप्लिकेशन (JavaScript), Android, Chrome ऐप्लिकेशन, iOS, टीवी और सीमित इनपुट वाले डिवाइस, डेस्कटॉप ऐप्लिकेशन (इसे "इंस्टॉल किया गया ऐप्लिकेशन" भी कहा जाता है), और यूनिवर्सल Windows प्लैटफ़ॉर्म (UWP).
- सेवा खाता
यह एक खास तरह का Google खाता होता है. इसका मकसद किसी ऐसे गैर-मानव उपयोगकर्ता का प्रतिनिधित्व करना होता है जिसकी पुष्टि करना है और जिसके पास डेटा ऐक्सेस करने की अनुमति हो. आपका ऐप्लिकेशन, Google API को कॉल करने के लिए सेवा खाते की पहचान का इस्तेमाल करता है, ताकि उपयोगकर्ता सीधे तौर पर शामिल न हों. सेवा खातों का इस्तेमाल, उपयोगकर्ता का डेटा ऐक्सेस करने के लिए नहीं किया जा सकता. आम तौर पर, डेटा को Workspace API का इस्तेमाल करके ऐक्सेस किया जाता है. हालांकि, सेवा खाता, डोमेन के लिए अधिकार देने की सुविधा को लागू करके, उपयोगकर्ता का डेटा ऐक्सेस कर सकता है. ज़्यादा जानकारी के लिए, सेवा खातों को समझना लेख पढ़ें.
- डोमेन के सभी उपयोगकर्ताओं को ऐक्सेस देना
एडमिन के पास यह सुविधा होती है कि वह किसी ऐप्लिकेशन को Google Workspace के संगठन में मौजूद उपयोगकर्ताओं की ओर से, उपयोगकर्ता का डेटा ऐक्सेस करने की अनुमति दे सकता है. डोमेन के लिए, ऐक्सेस देने की सुविधा का इस्तेमाल करके, उपयोगकर्ता के डेटा पर एडमिन से जुड़े टास्क पूरे किए जा सकते हैं. इस तरह से अनुमति देने के लिए, Google Workspace एडमिन, OAuth 2.0 के साथ सेवा खातों का इस्तेमाल करते हैं. इस सुविधा की वजह से, सिर्फ़ सुपर एडमिन ही पूरे डोमेन के लिए, अधिकार सौंपने की सुविधा चालू कर सकते हैं. ज़्यादा जानकारी के लिए, सेवा खाते को डोमेन के लिए अधिकार देना लेख पढ़ें.
अगला चरण
अपने ऐप्लिकेशन की OAuth सहमति वाली स्क्रीन को कॉन्फ़िगर करें, ताकि उपयोगकर्ता यह समझ सकें और अनुमति दे सकें कि आपके ऐप्लिकेशन के पास उनके डेटा का क्या ऐक्सेस है.