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

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

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

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

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

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

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

  • Google की Identity Services JavaScript लाइब्रेरी, इन सुविधाओं को लागू करती है:
    • डायलॉग पर आधारित सहमति फ़्लो, रीडायरेक्ट को कम करने के लिए होता है. इससे उपयोगकर्ताओं को अनुमति देने की पूरी प्रोसेस के दौरान, आपकी साइट पर बने रहने में मदद मिलती है.
    • सुरक्षा से जुड़ी सुविधाएं, जैसे कि किसी दूसरी साइट से किए गए फ़र्ज़ी अनुरोध (सीआरएसएफ़) से बचाव.
    • अलग-अलग स्कोप का अनुरोध करने और उपयोगकर्ता की सहमति की पुष्टि करने के लिए हेल्पर तरीके.
    • इंजीनियरों के लिए, डेवलपमेंट के दौरान इस्तेमाल करने के लिए गड़बड़ी ठीक करने से जुड़ी जानकारी और दस्तावेज़ के लिंक. साथ ही, बाद में आपकी साइट पर आने वाले लोगों के लिए भी.
  • Identity Services लाइब्रेरी के बिना लागू करने पर, इन चीज़ों की ज़िम्मेदारी आपकी होगी:
    • 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 को कॉल करने के लिए ज़रूरी होता है.