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 ऐप्लिकेशन को सीक्रेट की ज़रूरत नहीं होती, लेकिन वेब सर्वर ऐप्लिकेशन ज़रूर देता है.

आपको एक ऐसा 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 पीपल एपीआई, 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 API, जैसे कि अनुमान का एपीआई और 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 के सिक्योरिटी टोकन सर्विस एपीआई से मिले ऐक्सेस टोकन का स्ट्रक्चर 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 को लागू करना आसान हो जाता है. समय के साथ, लाइब्रेरी में और सुविधाएं जोड़ी जाएंगी.