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 Playground का इस्तेमाल करके, अपने क्लाइंट क्रेडेंशियल इस्तेमाल करने का विकल्प शामिल करें.

इस पेज पर, OAuth 2.0 से जुड़ी अनुमति के उन हालातों के बारे में खास जानकारी दी गई है जिन पर Google काम करता है. साथ ही, यहां आपको ज़्यादा जानकारी वाले कॉन्टेंट के लिंक भी मिलेंगे. पुष्टि करने के लिए OAuth 2.0 इस्तेमाल करने के बारे में जानकारी के लिए, OpenID Connect देखें.

बुनियादी चरण

OAuth 2.0 का इस्तेमाल करके, Google API ऐक्सेस करते समय सभी ऐप्लिकेशन, बुनियादी पैटर्न का पालन करते हैं. ऊंचे लेवल पर, आप पांच चरणों को पूरा करते हैं:

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

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

2. Google की अनुमति देने वाले सर्वर से ऐक्सेस टोकन पाएं.

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

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

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

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

आम तौर पर, पहले ऐक्सेस के बजाय, दायरों का दायरा बढ़ाने का अनुरोध करना बेहतर होता है. उदाहरण के लिए, अगर कोई ऐप्लिकेशन कैलेंडर में इवेंट को सेव करने की सुविधा चाहता है, तो उसे Google Calendar के ऐक्सेस का अनुरोध तब तक नहीं करना चाहिए, जब तक उपयोगकर्ता & & परिवार का कोटेशन, कैलेंडर में जोड़ें बटन नहीं दबाते; बढ़ोतरी की अनुमति देखें.

3. उपयोगकर्ता के दिए गए ऐक्सेस के दायरे देखें.

आपके ऐप्लिकेशन की सुविधाओं और फ़ंक्शन को ऐक्सेस करने के लिए, ज़रूरी स्कोप के जवाब में, स्कोप के ऐक्सेस में शामिल किए गए दायरे की तुलना, Google से जुड़े Google API के ऐक्सेस पर निर्भर करें. किसी भी ऐसी सुविधा को बंद करें जो आपके ऐप्लिकेशन से जुड़े एपीआई को ऐक्सेस किए बिना काम नहीं करती.

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

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

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

ऐक्सेस टोकन सिर्फ़ उन कार्रवाइयों और संसाधनों के सेट के लिए मान्य होते हैं जिनके बारे में scope, टोकन अनुरोध में बताया गया है. उदाहरण के लिए, अगर कोई ऐक्सेस टोकन Google Calendar API के लिए जारी किया जाता है, तो वह Google Contacts API का ऐक्सेस नहीं देता. हालांकि, इस तरह के कामों के लिए, आप उस ऐक्सेस टोकन को Google Calendar API पर कई बार भेज सकते हैं.

5. अगर ज़रूरी हो, तो ऐक्सेस टोकन को रीफ़्रेश करें.

ऐक्सेस टोकन की अवधि सीमित है. अगर आपके ऐप्लिकेशन को सिर्फ़ एक ऐक्सेस टोकन मिलने के बाद ही, Google API का ऐक्सेस चाहिए, तो वह रीफ़्रेश टोकन पा सकता है. रीफ़्रेश टोकन की मदद से, आपका ऐप्लिकेशन नए ऐक्सेस टोकन पा सकता है.

स्थितियां

वेब सर्वर ऐप्लिकेशन

Google OAuth 2.0 एंडपॉइंट, ऐसे वेब सर्वर ऐप्लिकेशन के साथ काम करता है जो भाषाओं, फ़्रेमवर्क, जैसे कि PHP, Java, Python, Ruby, और ASP.NET का इस्तेमाल करते हैं.

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

ऐप्लिकेशन को आने वाले समय में इस्तेमाल करने के लिए, रीफ़्रेश टोकन सेव करना चाहिए. साथ ही, Google API को ऐक्सेस करने के लिए, ऐक्सेस टोकन का इस्तेमाल करना चाहिए. ऐक्सेस टोकन की समयसीमा खत्म होने के बाद, नया टोकन पाने के लिए ऐप्लिकेशन, रीफ़्रेश टोकन का इस्तेमाल करता है.

आपका ऐप्लिकेशन, Google ऑथराइज़ेशन सर्वर पर टोकन का अनुरोध भेजता है. इसके लिए, ऑथराइज़ेशन कोड मिलता है, किसी टोकन के लिए कोड को एक्सचेंज किया जाता है, और Google API के एंडपॉइंट को कॉल करने के लिए, टोकन का इस्तेमाल किया जाता है.

ज़्यादा जानकारी के लिए, वेब सर्वर ऐप्लिकेशन के लिए OAuth 2.0 इस्तेमाल करना देखें.

इंस्‍टॉल किए गए ऐप्स

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

इस प्रक्रिया की वजह से, क्लाइंट आईडी और कुछ मामलों में क्लाइंट सीक्रेट, जिसे आप अपने ऐप्लिकेशन के सोर्स कोड में जोड़ते हैं. (इस संदर्भ में, क्लाइंट सीक्रेट को सीक्रेट तौर पर नहीं माना जाता है.)

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

ऐप्लिकेशन को आने वाले समय में इस्तेमाल करने के लिए, रीफ़्रेश टोकन सेव करना चाहिए. साथ ही, Google API को ऐक्सेस करने के लिए, ऐक्सेस टोकन का इस्तेमाल करना चाहिए. ऐक्सेस टोकन की समयसीमा खत्म होने के बाद, नया टोकन पाने के लिए ऐप्लिकेशन, रीफ़्रेश टोकन का इस्तेमाल करता है.

आपका ऐप्लिकेशन, Google ऑथराइज़ेशन सर्वर पर टोकन का अनुरोध भेजता है. इसके लिए, ऑथराइज़ेशन कोड मिलता है, किसी टोकन के लिए कोड को एक्सचेंज किया जाता है, और Google API के एंडपॉइंट को कॉल करने के लिए, टोकन का इस्तेमाल किया जाता है.

ज़्यादा जानकारी के लिए, इंस्टॉल किए गए ऐप्लिकेशन के लिए OAuth 2.0 का इस्तेमाल करना देखें.

क्लाइंट-साइड (JavaScript) ऐप्लिकेशन

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

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

नतीजे के तौर पर एक ऐक्सेस टोकन मिलता है. क्लाइंट को इसे Google API के अनुरोध में शामिल करने से पहले पुष्टि करनी होती है. टोकन की समयसीमा खत्म होने पर, ऐप्लिकेशन इस प्रोसेस को दोहराता है.

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

ज़्यादा जानकारी के लिए, क्लाइंट-साइड ऐप्लिकेशन के लिए OAuth 2.0 का इस्तेमाल करना देखें.

सीमित इनपुट वाले डिवाइस पर ऐप्लिकेशन

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

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

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

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

उपयोगकर्ता किसी ऐसे ब्राउज़र में लॉग इन करता है जिस पर ब्राउज़र मौजूद है

ज़्यादा जानकारी के लिए, डिवाइसों के लिए OAuth 2.0 इस्तेमाल करना देखें.

सेवा खाते

Google API, जैसे कि Prediction API और Google Cloud Storage, उपयोगकर्ता की जानकारी ऐक्सेस किए बिना आपके ऐप्लिकेशन की ओर से काम कर सकते हैं. इन परिस्थितियों में आपके ऐप्लिकेशन को एपीआई के लिए अपनी पहचान साबित करनी होती है, लेकिन उपयोगकर्ता की सहमति की ज़रूरत नहीं होती. इसी तरह, एंटरप्राइज़ की स्थिति में, आपका ऐप्लिकेशन कुछ संसाधनों के ऐक्सेस का अनुरोध कर सकता है.

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

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

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

ज़्यादा जानकारी के लिए, सेवा-खाता दस्तावेज़ देखें.

टोकन का साइज़

टोकन कई साइज़ में अलग-अलग हो सकते हैं, नीचे दी गई सीमाओं तक:

  • ऑथराइज़ेशन कोड: 256 बाइट
  • ऐक्सेस टोकन: 2048 बाइट
  • टोकन रीफ़्रेश करें: 512 बाइट

Google Cloud' की सुरक्षा टोकन सेवा एपीआई से मिले ऐक्सेस टोकन, Google API OAuth 2.0 ऐक्सेस टोकन की तरह ही स्ट्रक्चर्ड किए जाते हैं. हालांकि, इनकी टोकन साइज़ की सीमाएं अलग-अलग होती हैं. ज़्यादा जानकारी के लिए, एपीआई दस्तावेज़ देखें.

Google, इन सीमाओं के अंदर टोकन का साइज़ बदलने का अधिकार सुरक्षित रखता है. इसलिए, आपके ऐप्लिकेशन में वैरिएबल टोकन के साइज़ के हिसाब से काम करना चाहिए.

टोकन की समयसीमा खत्म होने की तारीख

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

  • उपयोगकर्ता ने आपके ऐप्लिकेशन का ऐक्सेस रद्द कर दिया है.
  • रीफ़्रेश टोकन का इस्तेमाल छह महीने से नहीं किया गया है.
  • उपयोगकर्ता ने पासवर्ड बदल दिए हैं और रीफ़्रेश टोकन में Gmail के दायरे शामिल हैं.
  • उपयोगकर्ता खाते की अधिकतम सीमा, मंज़ूर किए गए (लाइव) रीफ़्रेश टोकन की संख्या से ज़्यादा है.
  • उपयोगकर्ता, Google Cloud Platform के ऐसे संगठन का हिस्सा है जिस पर सेशन कंट्रोल की नीतियां लागू हैं.

Google Cloud Platform प्रोजेक्ट, बाहरी उपयोगकर्ता टाइप के लिए कॉन्फ़िगर की गई OAuth सहमति स्क्रीन के साथ जांच और कोटेशन की प्रकाशन स्थिति के लिए कॉन्फ़िगर किया गया है. इसे सात दिन में रीफ़्रेश होने वाला टोकन जारी किया जाता है.

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

उपयोगकर्ता खाते या सेवा खाते के सभी क्लाइंट के लिए उपलब्ध रीफ़्रेश टोकन की कुल संख्या भी ज़्यादा होती है. #

अगर आपको एक से ज़्यादा प्रोग्राम, मशीनों या डिवाइसों की अनुमति देनी है, तो इसका एक तरीका यह है कि आप हर Google खाते से जुड़े क्लाइंट की संख्या को 15 या 20 तक सीमित करें. अगर आप Google Workspace एडमिन हैं, तो आप एडमिन के खास अधिकारों वाले अतिरिक्त उपयोगकर्ता बना सकते हैं. साथ ही, उनका इस्तेमाल कुछ क्लाइंट को अनुमति देने के लिए कर सकते हैं.

Google Cloud Platform (GCP) संगठनों के लिए, सेशन कंट्रोल से जुड़ी नीतियों का पालन करना

जीसीपी संगठनों के एडमिन को उपयोगकर्ताओं के लिए, फिर से पुष्टि करने की ज़रूरत पड़ सकती है. ऐसा तब होता है, जब वे Google Cloud सेशन कंट्रोल की सुविधा का इस्तेमाल करते हैं. इस नीति का असर Google Cloud Console, Google Cloud SDK (इसे gcloud CLI के नाम से भी जाना जाता है) और तीसरे पक्ष के ऐसे किसी भी OAuth ऐप्लिकेशन को ऐक्सेस करने पर पड़ता है जिसके लिए Cloud Platform के दायरे की ज़रूरत होती है. अगर किसी उपयोगकर्ता ने सेशन कंट्रोल की नीति लागू की हुई है, तो सेशन की अवधि खत्म होने पर, आपके एपीआई कॉल की तरह ही गड़बड़ी होगी, जैसा कि रीफ़्रेश टोकन को रद्द करने पर होता था. कॉल, गड़बड़ी के invalid_token टाइप के साथ काम नहीं करेगा; सब-गड़बड़ी के टाइप का इस्तेमाल, निरस्त टोकन और सेशन कंट्रोल की नीति की वजह से होने वाले काम के बीच अंतर करने के लिए किया जा सकता है. सेशन की अवधि बहुत कम (1 घंटे से 24 घंटे के बीच) हो सकती है. इसलिए, पुष्टि करने वाले सेशन को रीस्टार्ट करके, इसे अच्छी तरह से हैंडल करना चाहिए.

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

इस सुविधा को लागू करने में अपने ग्राहकों की मदद करने के तरीके के बारे में ज़्यादा जानकारी के लिए, एडमिन पर फ़ोकस करने वाला सहायता लेख देखें.

क्लाइंट लाइब्रेरी

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