इस पेज का अनुवाद Cloud Translation API से किया गया है.

Google API ऐक्सेस करने के लिए OAuth 2.0 का इस्तेमाल करना

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

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

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

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

बुनियादी चरण

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

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

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

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

सर्वर-साइड या JavaScript वेब ऐप्लिकेशन के लिए, "वेब" क्लाइंट टाइप का इस्तेमाल करें. इस क्लाइंट टाइप का इस्तेमाल किसी अन्य ऐप्लिकेशन के लिए न करें. जैसे, नेटिव या मोबाइल ऐप्लिकेशन.
Android ऐप्लिकेशन के लिए, "Android" क्लाइंट टाइप का इस्तेमाल करें.
iOS और macOS ऐप्लिकेशन के लिए, "iOS" क्लाइंट टाइप का इस्तेमाल करें.
Universal Windows Platform ऐप्लिकेशन के लिए, "Universal Windows Platform" क्लाइंट टाइप का इस्तेमाल करें.
टीवी या एम्बेड किए गए डिवाइसों जैसे सीमित इनपुट डिवाइसों के लिए, "टीवी और सीमित इनपुट डिवाइसों" क्लाइंट टाइप का इस्तेमाल करें.
सर्वर-टू-सर्वर इंटरैक्शन के लिए, सेवा खातों का इस्तेमाल करें.

2. Google Authorization Server से ऐक्सेस टोकन पाएं.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सेवा खाते

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

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

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

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

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

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

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

टोकन का साइज़

टोकन का साइज़, इन सीमाओं के बीच में हो सकता है:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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