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

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

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

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

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

बुनियादी कदम

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

1. Google API Console से OAuth 2.0 क्रेडेंशियल प्राप्त करें।

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

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

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

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

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

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

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

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

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

हो सकता है कि आपके अनुरोध में शामिल दायरा आपकी प्रतिक्रिया में शामिल दायरे से मेल न खाए, भले ही उपयोगकर्ता ने सभी अनुरोधित दायरे दिए हों। एक्सेस के लिए आवश्यक दायरे के लिए प्रत्येक Google API के लिए दस्तावेज़ देखें। अनुरोध में अनुमत सभी मानों के लिए समान स्कोप स्ट्रिंग लौटाते हुए, एक एपीआई कई स्कोप स्ट्रिंग मानों को एक्सेस के एक स्कोप में मैप कर सकता है। उदाहरण: Google People 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 प्राधिकरण अनुरोध शीर्षलेख में एक Google API को टोकन भेजता है। यूआरआई क्वेरी-स्ट्रिंग पैरामीटर के रूप में टोकन भेजना संभव है, लेकिन हम इसकी अनुशंसा नहीं करते हैं, क्योंकि यूआरआई पैरामीटर लॉग फाइलों में समाप्त हो सकते हैं जो पूरी तरह से सुरक्षित नहीं हैं। साथ ही, अनावश्यक यूआरआई पैरामीटर नाम बनाने से बचने के लिए यह अच्छा आरईएसटी अभ्यास है। ध्यान दें कि क्वेरी-स्ट्रिंग समर्थन 1 जून, 2021 को बहिष्कृत कर दिया जाएगा।

एक्सेस टोकन केवल टोकन अनुरोध के 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 के माध्यम से क्लाइंट आईडी बनाते हैं , तो निर्दिष्ट करें कि यह एक इंस्टॉल किया गया एप्लिकेशन है, फिर एप्लिकेशन प्रकार के रूप में Android, Chrome ऐप, iOS, यूनिवर्सल विंडोज प्लेटफॉर्म (UWP), या डेस्कटॉप ऐप चुनें।

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

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

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

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

विवरण के लिए, इंस्टॉल किए गए एप्लिकेशन के लिए OAuth 2.0 का उपयोग करना देखें।

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

Google OAuth 2.0 एंडपॉइंट जावास्क्रिप्ट अनुप्रयोगों का समर्थन करता है जो एक ब्राउज़र में चलते हैं।

प्राधिकरण अनुक्रम तब शुरू होता है जब आपका एप्लिकेशन किसी ब्राउज़र को 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 क्लाउड की सुरक्षा टोकन सेवा API द्वारा लौटाए गए एक्सेस टोकन Google API OAuth 2.0 एक्सेस टोकन के समान संरचित होते हैं, लेकिन टोकन आकार की अलग-अलग सीमाएँ होती हैं। विवरण के लिए, एपीआई दस्तावेज देखें।

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

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

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

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

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

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

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

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

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

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

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

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

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

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