चेतावनी: यह डेटा Google उपयोगकर्ता डेटा नीति के तहत दिया जाता है. कृपया समीक्षा करें और नीति का पालन करें. ऐसा न करने पर, प्रोजेक्ट या खाता निलंबित हो सकता है.

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

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

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

GIS लाइब्रेरी उपयोगकर्ता के डिवाइस पर काम करने वाले ब्राउज़र में चलती है. इसे Node.js जैसे सर्वर साइड JavaScript फ़्रेमवर्क के साथ इस्तेमाल करने के लिए नहीं बनाया गया है. इसके बजाय, Google's 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 सेवाओं की JavaScript लाइब्रेरी को इस्तेमाल करने का फ़ैसला करें या अपनी लाइब्रेरी बनाएं.

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

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

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

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

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

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