Google API को एक्सेस करने के लिए OAuth 2.0 का उपयोग करना

Google API का उपयोग OAuth 2.0 प्रोटोकॉल प्रमाणीकरण और प्राधिकरण के लिए। Google सामान्य OAuth 2.0 परिदृश्यों का समर्थन करता है, जैसे कि वेब सर्वर, क्लाइंट-साइड, स्थापित और सीमित-इनपुट डिवाइस एप्लिकेशन के लिए।

शुरू करने के लिए, से OAuth 2.0 क्लाइंट क्रेडेंशियल प्राप्त Google API Console । फिर आपका क्लाइंट एप्लिकेशन Google प्राधिकरण सर्वर से एक एक्सेस टोकन का अनुरोध करता है, प्रतिक्रिया से एक टोकन निकालता है, और उस Google API को टोकन भेजता है जिसे आप एक्सेस करना चाहते हैं। गूगल के साथ OAuth 2.0 का उपयोग करने का एक इंटरैक्टिव प्रदर्शन के लिए के साथ, प्रयोग (अपने खुद के ग्राहक क्रेडेंशियल्स का उपयोग करने का विकल्प भी शामिल है) के लिए OAuth 2.0 खेल का मैदान

यह पृष्ठ Google द्वारा समर्थित OAuth 2.0 प्राधिकरण परिदृश्यों का अवलोकन देता है, और अधिक विस्तृत सामग्री के लिंक प्रदान करता है। प्रमाणीकरण के लिए OAuth 2.0 का उपयोग कर के बारे में जानकारी के लिए, OpenID Connect ने

बुनियादी कदम

OAuth 2.0 का उपयोग करके Google API को एक्सेस करते समय सभी एप्लिकेशन एक मूल पैटर्न का पालन करते हैं। उच्च स्तर पर, आप पाँच चरणों का पालन करते हैं:

1. OAuth से 2.0 साख प्राप्त Google API Console।

यात्रा Google API Console इस तरह के एक ग्राहक आईडी और ग्राहक रहस्य नहीं है कि दोनों गूगल और अपने आवेदन करने के लिए जाना जाता है के रूप में OAuth 2.0 क्रेडेंशियल्स प्राप्त करने के लिए। आप किस प्रकार के एप्लिकेशन का निर्माण कर रहे हैं, इसके आधार पर मूल्यों का सेट भिन्न होता है। उदाहरण के लिए, एक जावास्क्रिप्ट एप्लिकेशन को एक रहस्य की आवश्यकता नहीं होती है, लेकिन एक वेब सर्वर एप्लिकेशन करता है।

2. Google प्राधिकरण सर्वर से एक्सेस टोकन प्राप्त करें।

इससे पहले कि आपका एप्लिकेशन Google API का उपयोग करके निजी डेटा तक पहुंच सके, उसे एक एक्सेस टोकन प्राप्त करना होगा जो उस API तक पहुंच प्रदान करता है। एक एकल एक्सेस टोकन कई एपीआई तक पहुंच की अलग-अलग डिग्री प्रदान कर सकता है। एक चर पैरामीटर बुलाया scope नियंत्रण संसाधनों और संचालन के सेट है कि एक पहुँच टोकन परमिट। पहुंच-टोकन अनुरोध के दौरान, अपने आवेदन में एक या अधिक मान भेजता scope पैरामीटर।

यह अनुरोध करने के कई तरीके हैं, और वे आपके द्वारा बनाए जा रहे एप्लिकेशन के प्रकार के आधार पर भिन्न होते हैं। उदाहरण के लिए, एक जावास्क्रिप्ट एप्लिकेशन Google पर रीडायरेक्ट किए गए ब्राउज़र का उपयोग करके एक्सेस टोकन का अनुरोध कर सकता है, जबकि किसी डिवाइस पर इंस्टॉल किया गया एप्लिकेशन जिसमें कोई ब्राउज़र नहीं है, वेब सेवा अनुरोधों का उपयोग करता है।

कुछ अनुरोधों के लिए प्रमाणीकरण चरण की आवश्यकता होती है जहां उपयोगकर्ता अपने Google खाते से लॉग इन करता है। लॉग इन करने के बाद, उपयोगकर्ता से पूछा जाता है कि क्या वे एक या एक से अधिक अनुमतियाँ देने के इच्छुक हैं जिनका आपका आवेदन अनुरोध कर रहा है। इस प्रक्रिया को उपयोगकर्ता सहमति कहा जाता है।

यदि उपयोगकर्ता कम से कम एक अनुमति देता है, तो Google प्राधिकरण सर्वर आपके एप्लिकेशन को एक एक्सेस टोकन (या एक प्राधिकरण कोड जिसे आपका एप्लिकेशन एक्सेस टोकन प्राप्त करने के लिए उपयोग कर सकता है) और उस टोकन द्वारा दिए गए एक्सेस के दायरे की एक सूची भेजता है। यदि उपयोगकर्ता अनुमति नहीं देता है, तो सर्वर एक त्रुटि देता है।

आम तौर पर स्कोप का अनुरोध करने के लिए यह सबसे अच्छा अभ्यास है, उस समय पहुंच की आवश्यकता होती है, न कि सामने। उदाहरण के लिए, एक ऐप जो किसी ईवेंट को कैलेंडर में सहेजने का समर्थन करना चाहता है, उसे तब तक Google कैलेंडर एक्सेस का अनुरोध नहीं करना चाहिए जब तक कि उपयोगकर्ता "कैलेंडर में जोड़ें" बटन नहीं दबाता; देखने के वृद्धिशील प्राधिकरण

3. उपयोगकर्ता द्वारा दी गई पहुंच के दायरे की जांच करें।

एक्सेस टोकन प्रतिक्रिया में शामिल स्कोपों ​​की तुलना संबंधित Google API तक पहुंच पर निर्भर आपके एप्लिकेशन की सुविधाओं और कार्यक्षमता तक पहुंचने के लिए आवश्यक स्कोप से करें। संबंधित एपीआई तक पहुंच के बिना काम करने में असमर्थ आपके ऐप की किसी भी सुविधा को अक्षम करें।

हो सकता है कि आपके अनुरोध में शामिल दायरा आपकी प्रतिक्रिया में शामिल दायरे से मेल न खाए, भले ही उपयोगकर्ता ने सभी अनुरोधित दायरे दिए हों। पहुंच के लिए आवश्यक दायरे के लिए प्रत्येक Google API के लिए दस्तावेज़ देखें। एक एपीआई कई स्कोप स्ट्रिंग मानों को एक्सेस के एक स्कोप में मैप कर सकता है, अनुरोध में अनुमत सभी मानों के लिए समान स्कोप स्ट्रिंग लौटाता है। उदाहरण: Google लोग API की गुंजाइश वापस आ सकते हैं https://www.googleapis.com/auth/contacts कोई ऐप्लिकेशन एक उपयोगकर्ता की गुंजाइश को अधिकृत अनुरोध किया जब https://www.google.com/m8/feeds/ ; Google लोग API विधि people.updateContact की दी गुंजाइश की आवश्यकता है https://www.googleapis.com/auth/contacts

4. एक एपीआई को एक्सेस टोकन भेजें।

बाद एक आवेदन पहुंच टोकन प्राप्त करता है, यह एक में एक गूगल एपीआई के टोकन भेजता HTTP प्राधिकरण अनुरोध हेडर । यूआरआई क्वेरी-स्ट्रिंग पैरामीटर के रूप में टोकन भेजना संभव है, लेकिन हम इसकी अनुशंसा नहीं करते हैं, क्योंकि यूआरआई पैरामीटर लॉग फाइलों में समाप्त हो सकते हैं जो पूरी तरह से सुरक्षित नहीं हैं। साथ ही, अनावश्यक यूआरआई पैरामीटर नाम बनाने से बचने के लिए यह अच्छा आरईएसटी अभ्यास है।

पहुँच टोकन केवल संचालन और संसाधनों में वर्णित के सेट के लिए मान्य हैं scope टोकन अनुरोध की। उदाहरण के लिए, यदि Google कैलेंडर API के लिए एक्सेस टोकन जारी किया जाता है, तो यह Google संपर्क API तक पहुंच प्रदान नहीं करता है। हालांकि, आप उस एक्सेस टोकन को समान कार्यों के लिए Google कैलेंडर API को कई बार भेज सकते हैं।

5. यदि आवश्यक हो तो एक्सेस टोकन को रीफ्रेश करें।

एक्सेस टोकन का जीवनकाल सीमित होता है। यदि आपके एप्लिकेशन को एकल एक्सेस टोकन के जीवनकाल के बाद भी Google API तक पहुंच की आवश्यकता है, तो वह एक ताज़ा टोकन प्राप्त कर सकता है। एक ताज़ा टोकन आपके एप्लिकेशन को नए एक्सेस टोकन प्राप्त करने की अनुमति देता है।

परिदृश्यों

वेब सर्वर अनुप्रयोग

Google OAuth 2.0 एंडपॉइंट वेब सर्वर अनुप्रयोगों का समर्थन करता है जो PHP, Java, Python, Ruby और ASP.NET जैसी भाषाओं और ढांचे का उपयोग करते हैं।

प्राधिकरण अनुक्रम तब शुरू होता है जब आपका एप्लिकेशन किसी ब्राउज़र को Google URL पर पुनर्निर्देशित करता है; यूआरएल में क्वेरी पैरामीटर शामिल हैं जो अनुरोध किए जा रहे एक्सेस के प्रकार को इंगित करते हैं। Google उपयोगकर्ता प्रमाणीकरण, सत्र चयन और उपयोगकर्ता सहमति को संभालता है। परिणाम एक प्राधिकरण कोड है, जिसे एप्लिकेशन एक्सेस टोकन और रीफ्रेश टोकन के लिए एक्सचेंज कर सकता है।

एप्लिकेशन को भविष्य में उपयोग के लिए रीफ्रेश टोकन स्टोर करना चाहिए और Google एपीआई तक पहुंचने के लिए एक्सेस टोकन का उपयोग करना चाहिए। एक बार एक्सेस टोकन समाप्त हो जाने के बाद, एप्लिकेशन एक नया प्राप्त करने के लिए रीफ्रेश टोकन का उपयोग करता है।

आपका एप्लिकेशन Google प्राधिकरण सर्वर को एक टोकन अनुरोध भेजता है, एक प्राधिकरण कोड प्राप्त करता है, एक टोकन के लिए कोड का आदान-प्रदान करता है, और Google API समापन बिंदु को कॉल करने के लिए टोकन का उपयोग करता है।

जानकारी के लिए, वेब सर्वर अनुप्रयोगों के लिए OAuth 2.0 का उपयोग करना

इंस्टॉल किए गए एप्लिकेशन

Google OAuth 2.0 एंडपॉइंट ऐसे एप्लिकेशन का समर्थन करता है जो कंप्यूटर, मोबाइल डिवाइस और टैबलेट जैसे उपकरणों पर इंस्टॉल होते हैं। जब आप के माध्यम से एक क्लाइंट आईडी बनानी Google API Console , निर्दिष्ट है कि यह एक स्थापित किया गया ऐप्स है, तो आवेदन प्रकार के रूप में एंड्रॉयड, क्रोम एप्लिकेशन, iOS, यूनिवर्सल विंडोज प्लेटफार्म (UWP), या डेस्कटॉप एप्लिकेशन का चयन करें।

इस प्रक्रिया का परिणाम क्लाइंट आईडी और कुछ मामलों में क्लाइंट सीक्रेट के रूप में होता है, जिसे आप अपने एप्लिकेशन के सोर्स कोड में एम्बेड करते हैं। (इस संदर्भ में, ग्राहक रहस्य को स्पष्ट रूप से गुप्त नहीं माना जाता है।)

प्राधिकरण अनुक्रम तब शुरू होता है जब आपका एप्लिकेशन किसी ब्राउज़र को Google URL पर पुनर्निर्देशित करता है; यूआरएल में क्वेरी पैरामीटर शामिल हैं जो अनुरोध किए जा रहे एक्सेस के प्रकार को इंगित करते हैं। Google उपयोगकर्ता प्रमाणीकरण, सत्र चयन और उपयोगकर्ता सहमति को संभालता है। परिणाम एक प्राधिकरण कोड है, जिसे एप्लिकेशन एक्सेस टोकन और रीफ्रेश टोकन के लिए एक्सचेंज कर सकता है।

एप्लिकेशन को भविष्य में उपयोग के लिए रीफ्रेश टोकन स्टोर करना चाहिए और Google एपीआई तक पहुंचने के लिए एक्सेस टोकन का उपयोग करना चाहिए। एक बार एक्सेस टोकन समाप्त हो जाने के बाद, एप्लिकेशन एक नया प्राप्त करने के लिए रीफ्रेश टोकन का उपयोग करता है।

आपका एप्लिकेशन Google प्राधिकरण सर्वर को एक टोकन अनुरोध भेजता है, एक प्राधिकरण कोड प्राप्त करता है, एक टोकन के लिए कोड का आदान-प्रदान करता है, और Google API समापन बिंदु को कॉल करने के लिए टोकन का उपयोग करता है।

जानकारी के लिए, इंस्टॉल किए गए एप्लिकेशन के लिए OAuth 2.0 का उपयोग करना

क्लाइंट-साइड (जावास्क्रिप्ट) एप्लिकेशन

Google OAuth 2.0 एंडपॉइंट ब्राउज़र में चलने वाले JavaScript ऐप्लिकेशन का समर्थन करता है।

प्राधिकरण अनुक्रम तब शुरू होता है जब आपका एप्लिकेशन किसी ब्राउज़र को Google URL पर पुनर्निर्देशित करता है; यूआरएल में क्वेरी पैरामीटर शामिल हैं जो अनुरोध किए जा रहे एक्सेस के प्रकार को इंगित करते हैं। Google उपयोगकर्ता प्रमाणीकरण, सत्र चयन और उपयोगकर्ता सहमति को संभालता है।

परिणाम एक एक्सेस टोकन है, जिसे क्लाइंट को Google API अनुरोध में शामिल करने से पहले सत्यापित करना चाहिए। जब टोकन समाप्त हो जाता है, तो एप्लिकेशन प्रक्रिया को दोहराता है।

आपका JS एप्लिकेशन Google प्राधिकरण सर्वर को एक टोकन अनुरोध भेजता है, एक टोकन प्राप्त करता है, टोकन को मान्य करता है, और Google API समापन बिंदु को कॉल करने के लिए टोकन का उपयोग करता है।

जानकारी के लिए, क्लाइंट-साइड अनुप्रयोगों के लिए OAuth 2.0 का उपयोग करना

सीमित-इनपुट उपकरणों पर अनुप्रयोग

Google OAuth 2.0 एंडपॉइंट ऐसे एप्लिकेशन का समर्थन करता है जो गेम कंसोल, वीडियो कैमरा और प्रिंटर जैसे सीमित इनपुट डिवाइस पर चलते हैं।

प्राधिकरण अनुक्रम एक प्राधिकरण कोड के लिए Google URL के लिए एक वेब सेवा अनुरोध करने वाले एप्लिकेशन के साथ शुरू होता है। प्रतिक्रिया में कई पैरामीटर होते हैं, जिसमें एक यूआरएल और एक कोड शामिल होता है जो एप्लिकेशन उपयोगकर्ता को दिखाता है।

उपयोगकर्ता डिवाइस से यूआरएल और कोड प्राप्त करता है, फिर एक अलग डिवाइस या कंप्यूटर में समृद्ध इनपुट क्षमताओं के साथ स्विच करता है। उपयोगकर्ता एक ब्राउज़र लॉन्च करता है, निर्दिष्ट यूआरएल पर नेविगेट करता है, लॉग इन करता है और कोड दर्ज करता है।

इस बीच, एप्लिकेशन एक निर्दिष्ट अंतराल पर एक Google URL का सर्वेक्षण करता है। उपयोगकर्ता द्वारा पहुंच को मंजूरी देने के बाद, Google सर्वर की प्रतिक्रिया में एक एक्सेस टोकन और रीफ्रेश टोकन होता है। एप्लिकेशन को भविष्य में उपयोग के लिए रीफ्रेश टोकन स्टोर करना चाहिए और Google एपीआई तक पहुंचने के लिए एक्सेस टोकन का उपयोग करना चाहिए। एक बार एक्सेस टोकन समाप्त हो जाने के बाद, एप्लिकेशन एक नया प्राप्त करने के लिए रीफ्रेश टोकन का उपयोग करता है।

उपयोगकर्ता एक अलग डिवाइस पर लॉग इन करता है जिसमें एक ब्राउज़र होता है

जानकारी के लिए, उपकरणों के लिए OAuth 2.0 का उपयोग करना

सेवा खाते

Google API जैसे प्रेडिक्शन API और Google क्लाउड स्टोरेज उपयोगकर्ता जानकारी तक पहुंच के बिना आपके एप्लिकेशन की ओर से कार्य कर सकते हैं। इन स्थितियों में आपके आवेदन को एपीआई को अपनी पहचान साबित करने की आवश्यकता है, लेकिन उपयोगकर्ता की सहमति आवश्यक नहीं है। इसी तरह, एंटरप्राइज़ परिदृश्यों में, आपका एप्लिकेशन कुछ संसाधनों के लिए प्रत्यायोजित पहुंच का अनुरोध कर सकता है।

सर्वर से सर्वर बातचीत के इन प्रकार के लिए आप एक सेवा खाते की आवश्यकता है, जो एक खाता है कि आपके आवेदन करने के बजाय एक व्यक्ति अंत उपयोगकर्ता से संबंधित है। आपका एप्लिकेशन सेवा खाते की ओर से Google API को कॉल करता है, और उपयोगकर्ता की सहमति की आवश्यकता नहीं है। (गैर-सेवा-खाता परिदृश्यों में, आपका एप्लिकेशन अंतिम-उपयोगकर्ताओं की ओर से Google API को कॉल करता है, और कभी-कभी उपयोगकर्ता की सहमति आवश्यक होती है।)

एक सेवा खाते के क्रेडेंशियल है, जो आप से प्राप्त Google API Consoleएक जेनरेट किया गया ईमेल पता है कि अद्वितीय है, एक ग्राहक आईडी, और कम से कम एक सार्वजनिक / निजी कुंजी युग्म शामिल हैं। आप एक हस्ताक्षरित JWT बनाने और उपयुक्त प्रारूप में एक एक्सेस-टोकन अनुरोध बनाने के लिए क्लाइंट आईडी और एक निजी कुंजी का उपयोग करते हैं। आपका एप्लिकेशन तब Google OAuth 2.0 प्राधिकरण सर्वर को टोकन अनुरोध भेजता है, जो एक एक्सेस टोकन देता है। एप्लिकेशन Google API तक पहुंचने के लिए टोकन का उपयोग करता है। जब टोकन समाप्त हो जाता है, तो एप्लिकेशन प्रक्रिया को दोहराता है।

आपका सर्वर एप्लिकेशन Google प्राधिकरण सर्वर से टोकन का अनुरोध करने के लिए JWT का उपयोग करता है, फिर Google API एंडपॉइंट को कॉल करने के लिए टोकन का उपयोग करता है। कोई अंतिम उपयोगकर्ता शामिल नहीं है।

जानकारी के लिए, सेवा-खाता प्रलेखन

टोकन आकार

टोकन आकार में भिन्न हो सकते हैं, निम्नलिखित सीमा तक:

  • प्राधिकरण कोड: 256 बाइट्स
  • एक्सेस टोकन: 2048 बाइट्स
  • टोकन ताज़ा करें: 512 बाइट्स

प्रवेश Google मेघ के द्वारा दिया टोकन सुरक्षा टोकन सेवा एपीआई गूगल एपीआई OAuth 2.0 पहुंच टोकन की तरह ही संरचित लेकिन अलग टोकन आकार सीमा होती है। जानकारी के लिए, API दस्तावेज़

Google इन सीमाओं के भीतर टोकन आकार बदलने का अधिकार सुरक्षित रखता है, और आपके आवेदन को तदनुसार परिवर्तनीय टोकन आकारों का समर्थन करना चाहिए।

रीफ़्रेश टोकन समाप्ति

इस संभावना का अनुमान लगाने के लिए आपको अपना कोड लिखना होगा कि एक दिया गया ताज़ा टोकन अब काम नहीं कर सकता है। रिफ्रेश टोकन इनमें से किसी एक कारण से काम करना बंद कर सकता है:

  • उपयोगकर्ता है अपने अनुप्रयोग की ऐक्सेस निरस्त कर
  • छह महीने से ताज़ा टोकन का उपयोग नहीं किया गया है।
  • उपयोगकर्ता ने पासवर्ड बदल दिया और रीफ्रेश टोकन में जीमेल स्कोप शामिल हैं।
  • उपयोगकर्ता खाते ने दिए गए (लाइव) रीफ़्रेश टोकन की अधिकतम संख्या को पार कर लिया है।
  • उपयोगकर्ता एक Google क्लाउड प्लेटफ़ॉर्म संगठन से संबंधित है जिसकी सत्र नियंत्रण नीतियां प्रभावी हैं।

बाहरी उपयोगकर्ता प्रकार के लिए कॉन्फ़िगर की गई OAuth सहमति स्क्रीन और "परीक्षण" की प्रकाशन स्थिति के साथ Google क्लाउड प्लेटफ़ॉर्म प्रोजेक्ट को 7 दिनों में समाप्त होने वाला ताज़ा टोकन जारी किया जाता है।

वर्तमान में प्रति OAuth 2.0 क्लाइंट आईडी प्रति Google खाता 50 रीफ्रेश टोकन की सीमा है। यदि सीमा समाप्त हो जाती है, तो एक नया रीफ्रेश टोकन बनाना बिना किसी चेतावनी के सबसे पुराने रीफ्रेश टोकन को स्वचालित रूप से अमान्य कर देता है। यह सीमा पर लागू नहीं होता सेवा खाते

एक उपयोगकर्ता खाते या सेवा खाते में सभी ग्राहकों के लिए ताज़ा टोकन की कुल संख्या की एक बड़ी सीमा भी है। अधिकांश सामान्य उपयोगकर्ता इस सीमा से अधिक नहीं होंगे, लेकिन किसी कार्यान्वयन का परीक्षण करने के लिए उपयोग किए जाने वाले डेवलपर के खाते में हो सकता है।

आप एक से अधिक कार्यक्रमों, मशीनों, या उपकरणों को प्राधिकृत करने की जरूरत है, एक वैकल्पिक हल ग्राहकों की संख्या है कि आप 15 या 20 के लिए Google खाते प्रति को अधिकृत आप एक कर रहे हैं सीमित करने के लिए है गूगल कार्यस्थान व्यवस्थापक , आप प्रशासनिक विशेषाधिकार और साथ अतिरिक्त उपयोगकर्ताओं बना सकते हैं कुछ ग्राहकों को अधिकृत करने के लिए उनका उपयोग करें।

Google क्लाउड प्लेटफ़ॉर्म (GCP) संगठनों के लिए सत्र नियंत्रण नीतियों से निपटना

जबकि वे जीसीपी संसाधनों का उपयोग जीसीपी संगठनों के व्यवस्थापक उपयोगकर्ताओं के लगातार पुन: प्रमाणीकरण की आवश्यकता हो सकती, का उपयोग करते हुए Google मेघ सत्र कंट्रोल सुविधा । यह नीति प्रभावों Google क्लाउड कंसोल, के लिए पहुँच Google मेघ एसडीके (भी gcloud CLI के रूप में जाना जाता है), और किसी भी तृतीय पक्ष OAuth अनुप्रयोग है कि मेघ प्लेटफ़ॉर्म गुंजाइश की आवश्यकता है। एक उपयोगकर्ता सत्र की अवधि समाप्त होने पर तो जगह में एक सत्र के नियंत्रण नीति है, तो आपके API कॉल करता है, तो ताज़ा टोकन निरस्त किया गया है क्या होगा के समान बाहर त्रुटि जाएगा - कॉल एक त्रुटि प्रकार के साथ असफल हो जायेगी invalid_token ; उप-त्रुटि प्रकार का उपयोग रिवोक टोकन और सत्र नियंत्रण नीति के कारण विफलता के बीच अंतर करने के लिए किया जा सकता है। चूंकि सत्र की अवधि बहुत सीमित (1 घंटे से 24 घंटे के बीच) हो सकती है, इसलिए इस परिदृश्य को एक सत्र सत्र को फिर से शुरू करके इनायत से संभाला जाना चाहिए।

समान रूप से, आपको सर्वर से सर्वर परिनियोजन के लिए उपयोगकर्ता क्रेडेंशियल्स का उपयोग या उपयोग को प्रोत्साहित नहीं करना चाहिए। यदि उपयोगकर्ता क्रेडेंशियल लंबे समय तक चलने वाली नौकरियों या संचालन के लिए सर्वर पर तैनात किए जाते हैं और ग्राहक ऐसे उपयोगकर्ताओं पर सत्र नियंत्रण नीतियां लागू करता है, तो सर्वर एप्लिकेशन विफल हो जाएगा क्योंकि सत्र की अवधि समाप्त होने पर उपयोगकर्ता को फिर से प्रमाणित करने का कोई तरीका नहीं होगा।

कैसे मदद करने के लिए अपने ग्राहकों को इस सुविधा की तैनाती के बारे में अधिक जानकारी के लिए, इसे देखें व्यवस्थापक ध्यान केंद्रित सहायता लेख।

ग्राहक पुस्तकालय

निम्नलिखित क्लाइंट लाइब्रेरी लोकप्रिय फ्रेमवर्क के साथ एकीकृत होते हैं, जो OAuth 2.0 को लागू करना आसान बनाता है। समय के साथ पुस्तकालयों में और अधिक सुविधाएँ जोड़ी जाएँगी।