उपयोगकर्ता की अनुमति का मॉडल चुनें

इस गाइड से आपको यह चुनने में मदद मिलती है कि उपयोगकर्ता को अनुमति देने के लिए, Google Identity Services लाइब्रेरी का इस्तेमाल किया जाए या अपनी JavaScript लाइब्रेरी लागू की जाए. इससे आपको यह तय करने में मदद मिलती है कि आपके वेब ऐप्लिकेशन के लिए, OAuth 2.0 का कौनसा ऑथराइज़ेशन फ़्लो सबसे अच्छा है.

इस गाइड को पढ़ने से पहले, यह माना जाता है कि आपको खास जानकारी में बताए गए शब्दों और सिद्धांतों के बारे में पता है. साथ ही, उपयोगकर्ता की अनुमति के काम करने का तरीका गाइड आपको भी पता है.

उपयोगकर्ता के डिवाइस पर GIS लाइब्रेरी काम करने वाले इन ब्राउज़र में चलती है. इसका इस्तेमाल Node.js जैसे सर्वर साइड JavaScript फ़्रेमवर्क के साथ नहीं करने के लिए किया जाना चाहिए. इसके बजाय, Google की Node.js क्लाइंट लाइब्रेरी का इस्तेमाल करें.

इस गाइड में, सिर्फ़ अनुमति देने और डेटा शेयर करने से जुड़े विषयों के बारे में बताया गया है. यह टूल, उपयोगकर्ता की पुष्टि करने की प्रक्रिया की समीक्षा नहीं करता है. इसके बजाय, Google से साइन इन करें और उपयोगकर्ता के साइन अप और साइन इन करने के लिए, 'Google साइन-इन' से डेटा दूसरी जगह भेजने वाली गाइड देखें.

तय करना कि GIS लाइब्रेरी आपके लिए सही है या नहीं

आपको चुनना होगा कि Google की लाइब्रेरी का इस्तेमाल किया जा रहा है या अपनी ज़रूरत के हिसाब से बेहतरीन लाइब्रेरी बनाई जा रही है. सुविधाओं और फ़ंक्शन के बारे में खास जानकारी:

• Google की पहचान सेवाओं की JavaScript लाइब्रेरी में ये चीज़ें लागू होती हैं:
  • रीडायरेक्ट को कम करने के लिए, पॉप-अप पर आधारित सहमति फ़्लो. इस तरह अनुमति देने की प्रोसेस के दौरान, उपयोगकर्ता आपकी साइट पर बने रहते हैं.
  • सुरक्षा से जुड़ी सुविधाएं, जैसे कि क्रॉस-साइट अनुरोध जालसाज़ी (CRSF).
  • अलग-अलग दायरों का अनुरोध करने और उपयोगकर्ता की सहमति की पुष्टि करने के तरीके.
  • डेवलपमेंट के दौरान इंजीनियर और बाद में आपकी साइट पर आने वाले लोगों के इस्तेमाल के लिए, मैन्युअल गड़बड़ियों को ठीक करने के तरीके और दस्तावेज़ों के लिंक.
• पहचान सेवाओं की लाइब्रेरी के बिना लागू करते समय इन चीज़ों के लिए आप ज़िम्मेदार हैं:
  • Google के OAuth 2.0 एंडपॉइंट की मदद से अनुरोध और रिस्पॉन्स मैनेज करना. इनमें रीडायरेक्ट भी शामिल हैं.
  • उपयोगकर्ता अनुभव को ऑप्टिमाइज़ करना.
  • अनुरोधों, जवाबों की पुष्टि करने और सीएसआरएफ़ को रोकने के लिए, सुरक्षा से जुड़ी सुविधाओं को लागू करना.
  • उपयोगकर्ता ने अनुरोध किए गए सभी दायरे के लिए सहमति दे दी है, इसकी पुष्टि करने के तरीके.
  • OAuth 2.0 वाले गड़बड़ी कोड मैनेज करना, लोगों की मदद के लिए ऐसे मैसेज बनाना जो पढ़ने में आसान हों, और उपयोगकर्ताओं की मदद के लिए लिंक मुहैया कराना.

खास जानकारी में, Google आपको GIS लाइब्रेरी उपलब्ध कराता है, ताकि आप OAuth 2.0 क्लाइंट को तेज़ी से और सुरक्षित तरीके से लागू करने में मदद कर सकें. साथ ही, उपयोगकर्ता की अनुमति देने के अनुभव को बेहतर बना सकें.

ऑथराइज़ेशन फ़्लो चुनना

आपको OAuth 2.0 के ऑथराइज़ेशन फ़्लो में से किसी एक को चुनना होगा: इंप्लिसिट या ऑथराइज़ेशन कोड -- भले ही, आपने Google Identity Services की JavaScript लाइब्रेरी का इस्तेमाल करने या अपनी लाइब्रेरी बनाने का फ़ैसला किया हो.

दोनों फ़्लो से एक ऐक्सेस टोकन मिलता है. इसका इस्तेमाल Google API को कॉल करने के लिए किया जा सकता है.

दोनों फ़्लो के बीच के मुख्य अंतर ये हैं:

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

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

अहम जानकारी: ऑथराइज़ेशन कोड फ़्लो का सुझाव दिया जाता है, क्योंकि यह ज़्यादा सुरक्षित फ़्लो देता है.

OAuth 2.0 फ़्लो की तुलना

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