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

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 आज़माएं. इसमें अपने क्लाइंट क्रेडेंशियल इस्तेमाल करने का विकल्प भी शामिल है.

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

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

बुनियादी चरण

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

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

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

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

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

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

ऐक्सेस टोकन सिर्फ़ उन कार्रवाइयों और संसाधनों के लिए मान्य होते हैं जिनके बारे में टोकन के अनुरोध के 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) या डेस्कटॉप ऐप्लिकेशन चुनें.

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

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

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

टोकन का साइज़

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

code Authorization codes
256 bytes
contextual_token ऐक्सेस टोकन
2048 बाइट
restore_page रीफ़्रेश टोकन
512 बाइट

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

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

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

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

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

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

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

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

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