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 क्रेडेंशियल पाएं.

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

आपको एक ऐसा OAuth क्लाइंट बनाना होगा जो उस प्लैटफ़ॉर्म के हिसाब से सही हो जिस पर आपका ऐप्लिकेशन चलेगा. उदाहरण के लिए:

2. Google ऑथराइज़ेशन सर्वर से ऐक्सेस टोकन पाना.

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

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

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

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

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

3. उपयोगकर्ता के ऐक्सेस के दायरे की जांच करें.

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

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

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

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

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

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

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

स्थितियां

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

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

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

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

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

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

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

Google OAuth 2.0 एंडपॉइंट, उन ऐप्लिकेशन के साथ काम करता है जो कंप्यूटर, मोबाइल डिवाइस, और टैबलेट पर इंस्टॉल किए गए हैं. Google API Console की मदद से क्लाइंट आईडी बनाते समय, बताएं कि यह इंस्टॉल किया गया ऐप्लिकेशन है. इसके बाद, ऐप्लिकेशन के टाइप के तौर पर Android, Chrome ऐप्लिकेशन, iOS, Universal Windows Platform (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 के एपीआई, जैसे कि अनुमान का एपीआई और Google Cloud Storage, आपके ऐप्लिकेशन की ओर से काम कर सकते हैं. इसके लिए, उपयोगकर्ताओं की जानकारी ऐक्सेस नहीं की जा सकती. इन स्थितियों में, आपके ऐप्लिकेशन को एपीआई के लिए अपनी पहचान साबित करनी होगी. हालांकि, इसके लिए उपयोगकर्ता की सहमति लेना ज़रूरी नहीं है. इसी तरह, एंटरप्राइज़ स्थितियों में, आपका ऐप्लिकेशन कुछ संसाधनों को ऐक्सेस देने का अनुरोध कर सकता है.

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

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

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

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

टोकन का साइज़

टोकन के साइज़ में फ़र्क़ हो सकता है. इनकी जानकारी नीचे दी गई सीमा तक हो सकती है:

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

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

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

टोकन की समयसीमा रीफ़्रेश करें

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

बाहरी उपयोगकर्ता टाइप के लिए कॉन्फ़िगर की गई OAuth सहमति स्क्रीन वाला Google Cloud Platform प्रोजेक्ट और "टेस्टिंग" की पब्लिशिंग स्थिति को रीफ़्रेश टोकन जारी किया जाता है. इसकी समयसीमा सात दिनों में खत्म हो जाती है. ऐसा तब नहीं होगा, जब सिर्फ़ OAuth दायरों का अनुरोध किया गया हो. ये नाम, ईमेल पते, और उपयोगकर्ता की प्रोफ़ाइल ( userinfo.email, userinfo.profile, openid के दायरे या उनके OpenID Connect के बराबर) के सबसेट होते हैं.

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

साथ ही, सभी क्लाइंट के किसी उपयोगकर्ता खाते या सेवा खाते के रीफ़्रेश टोकन की कुल संख्या की सीमा भी ज़्यादा होती है. ज़्यादातर सामान्य उपयोगकर्ता इस सीमा को पार नहीं करेंगे. हालांकि, लागू किए जाने की जांच के लिए इस्तेमाल किए गए डेवलपर खाते से यह सीमा पार हो सकती है.

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

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

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

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

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

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

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