Google के एपीआई, पुष्टि करने और अनुमति देने के लिए 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 के किसी एपीआई को ऐक्सेस करते समय, सभी ऐप्लिकेशन एक जैसे पैटर्न को फ़ॉलो करते हैं. इसके लिए, आपको ये पांच चरण पूरे करने होते हैं:
1. Google API Console से OAuth 2.0 क्रेडेंशियल पाएं.
Google API Console पर जाकर, OAuth 2.0 क्रेडेंशियल पाएं. जैसे, क्लाइंट आईडी और क्लाइंट सीक्रेट. ये क्रेडेंशियल, Google और आपके ऐप्लिकेशन, दोनों के लिए मान्य होते हैं. आपके बनाए जा रहे ऐप्लिकेशन के टाइप के आधार पर, वैल्यू का सेट अलग-अलग होता है. उदाहरण के लिए, JavaScript ऐप्लिकेशन के लिए सीक्रेट की ज़रूरत नहीं होती, लेकिन वेब सर्वर ऐप्लिकेशन के लिए सीक्रेट की ज़रूरत होती है.
आपको उस प्लैटफ़ॉर्म के लिए OAuth क्लाइंट बनाना होगा जिस पर आपका ऐप्लिकेशन चलेगा, जैसे:
-
Android ऐप्लिकेशन के लिए, Android ऐप्लिकेशन क्लाइंट टाइप का इस्तेमाल करें.
Android -
iOS और macOS ऐप्लिकेशन के लिए, iOS क्लाइंट टाइप का इस्तेमाल करें. -
code
सर्वर-साइड या JavaScript वेब ऐप्लिकेशन के लिए,
वेब ऐप्लिकेशन क्लाइंट टाइप का इस्तेमाल करें. इस क्लाइंट टाइप का इस्तेमाल, किसी अन्य ऐप्लिकेशन के लिए न करें. जैसे, नेटिव या मोबाइल ऐप्लिकेशन. - chrome_extension Chrome एक्सटेंशन के लिए, Chrome एक्सटेंशन क्लाइंट टाइप का इस्तेमाल करें.
-
tv सीमित इनपुट डिवाइसों के लिए, जैसे कि टीवी या एम्बेड किए गए डिवाइस, टीवी और सीमित इनपुट डिवाइस क्लाइंट टाइप का इस्तेमाल करें. - host सर्वर-टू-सर्वर इंटरैक्शन के लिए, सेवा खातों का इस्तेमाल करें. इसके लिए, OAuth क्लाइंट आईडी की ज़रूरत नहीं होती.
2. Google के ऑथराइज़ेशन सर्वर से ऐक्सेस टोकन पाएं.
Google के किसी एपीआई का इस्तेमाल करके, निजी डेटा को ऐक्सेस करने के लिए, आपके ऐप्लिकेशन को एक
ऐक्सेस टोकन पाना होगा. इस टोकन से, उस एपीआई को ऐक्सेस करने की अनुमति मिलती है. एक ऐक्सेस टोकन से, कई एपीआई को अलग-अलग लेवल पर ऐक्सेस किया जा सकता है. `scope` नाम का एक वैरिएबल पैरामीटर, उन संसाधनों और कार्रवाइयों के सेट को कंट्रोल करता है जिनकी अनुमति ऐक्सेस टोकन देता है. ऐक्सेस टोकन के अनुरोध के दौरान,
आपका ऐप्लिकेशन scope पैरामीटर में एक या उससे ज़्यादा वैल्यू भेजता है.
यह अनुरोध करने के कई तरीके हैं. ये तरीके, आपके बनाए जा रहे ऐप्लिकेशन के टाइप के आधार पर अलग-अलग होते हैं. उदाहरण के लिए, JavaScript ऐप्लिकेशन, Google पर ब्राउज़र रीडायरेक्ट का इस्तेमाल करके ऐक्सेस टोकन का अनुरोध कर सकता है. वहीं, किसी ऐसे डिवाइस पर इंस्टॉल किया गया ऐप्लिकेशन जिसमें ब्राउज़र नहीं है, वेब सेवा के अनुरोधों का इस्तेमाल करता है. अनुरोध करने के तरीके के बारे में ज़्यादा जानकारी के लिए, Scenarios और हर तरह के ऐप्लिकेशन के लिए, लागू करने से जुड़ी विस्तृत गाइड देखें.
कुछ अनुरोधों के लिए, पुष्टि करने का चरण ज़रूरी होता है. इसमें उपयोगकर्ता अपने Google खाते से लॉग इन करता है. लॉग इन करने के बाद, उपयोगकर्ता से पूछा जाता है कि वह आपके ऐप्लिकेशन के अनुरोध के मुताबिक, एक या उससे ज़्यादा अनुमतियां देना चाहता है या नहीं. इस प्रोसेस को उपयोगकर्ता की सहमति कहा जाता है.
अगर उपयोगकर्ता कम से कम एक अनुमति देता है, तो Google का ऑथराइज़ेशन सर्वर, आपके ऐप्लिकेशन को एक ऐक्सेस टोकन (या एक ऑथराइज़ेशन कोड, जिसका इस्तेमाल आपका ऐप्लिकेशन ऐक्सेस टोकन पाने के लिए कर सकता है) और उस टोकन से मिली अनुमतियों के दायरों की सूची भेजता है. अगर उपयोगकर्ता अनुमति नहीं देता है, तो सर्वर एक गड़बड़ी दिखाता है.
आम तौर पर, अनुरोध किए गए दायरों को पहले से बताने के बजाय, ज़रूरत पड़ने पर धीरे-धीरे अनुरोध करना सबसे सही तरीका है. उदाहरण के लिए, किसी इवेंट को कैलेंडर में सेव करने की सुविधा देने वाले ऐप्लिकेशन को, Google Calendar के ऐक्सेस का अनुरोध तब तक नहीं करना चाहिए, जब तक उपयोगकर्ता "कैलेंडर में जोड़ें" बटन पर क्लिक न करे. ज़्यादा जानकारी के लिए, धीरे-धीरे अनुमति देना देखें.
3. उपयोगकर्ता की दी गई अनुमतियों के दायरे देखें.
ऐक्सेस टोकन के रिस्पॉन्स में शामिल दायरों की तुलना, उन दायरों से करें जिनकी ज़रूरत आपके ऐप्लिकेशन की सुविधाओं और फ़ंक्शन को ऐक्सेस करने के लिए होती है. ये सुविधाएं और फ़ंक्शन, Google के किसी एपीआई के ऐक्सेस पर निर्भर करते हैं. अपने ऐप्लिकेशन की उन सुविधाओं को बंद करें जो संबंधित एपीआई के ऐक्सेस के बिना काम नहीं कर सकतीं.
आपके अनुरोध में शामिल दायरा, आपके रिस्पॉन्स में शामिल दायरे से मैच नहीं हो सकता. भले ही,
उपयोगकर्ता ने अनुरोध किए गए सभी दायरों की अनुमति दी हो. ऐक्सेस के लिए ज़रूरी दायरों के बारे में जानने के लिए, Google के हर एपीआई का दस्तावेज़ देखें. कोई एपीआई, ऐक्सेस के एक दायरे के लिए, दायरे की स्ट्रिंग की कई वैल्यू मैप कर सकता है. साथ ही, अनुरोध में अनुमति दी गई सभी वैल्यू के लिए, दायरे की एक ही स्ट्रिंग दिखा सकता है.
उदाहरण के लिए, जब कोई ऐप्लिकेशन, उपयोगकर्ता से
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. किसी एपीआई को ऐक्सेस टोकन भेजें.
किसी ऐप्लिकेशन को ऐक्सेस टोकन मिलने के बाद, वह टोकन को HTTP ऑथराइज़ेशन अनुरोध हेडर में, Google के किसी एपीआई को भेजता है. टोकन को यूआरआई क्वेरी-स्ट्रिंग पैरामीटर के तौर पर भेजा जा सकता है. हालांकि, हमारा सुझाव है कि ऐसा न करें, क्योंकि यूआरआई पैरामीटर, पूरी तरह से सुरक्षित न होने वाली लॉग फ़ाइलों में सेव हो सकते हैं. साथ ही, REST के सबसे सही तरीके के तहत, बेवजह यूआरआई पैरामीटर के नाम बनाने से बचना चाहिए.
ऐक्सेस टोकन, सिर्फ़ उन कार्रवाइयों और संसाधनों के सेट के लिए मान्य होते हैं जिनकी जानकारी, टोकन के अनुरोध के
scope में दी गई है. उदाहरण के लिए, अगर Google Calendar API के लिए ऐक्सेस टोकन जारी किया जाता है, तो इससे Google Contacts API को ऐक्सेस करने की अनुमति नहीं मिलती. हालांकि, एक जैसी कार्रवाइयों के लिए, उस ऐक्सेस टोकन को Google Calendar API को कई बार भेजा जा सकता है.
5. ज़रूरत पड़ने पर, ऐक्सेस टोकन रीफ़्रेश करें.
ऐक्सेस टोकन की समयसीमा सीमित होती है. अगर आपके ऐप्लिकेशन को, Google के किसी एपीआई को ऐक्सेस करने के लिए, एक ऐक्सेस टोकन की समयसीमा से ज़्यादा समय चाहिए, तो वह रीफ़्रेश टोकन पा सकता है. रीफ़्रेश टोकन की मदद से, आपका ऐप्लिकेशन नए ऐक्सेस टोकन पा सकता है.
Scenarios
इन स्थितियों में, अलग-अलग तरह के ऐप्लिकेशन के लिए, ऑथराइज़ेशन कोड का अनुरोध करने और ऐक्सेस और रीफ़्रेश टोकन पाने के लिए, OAuth 2.0 का इस्तेमाल करने का तरीका बताया गया है.
वेब सर्वर ऐप्लिकेशन
Google OAuth 2.0 एंडपॉइंट, वेब सर्वर ऐप्लिकेशन के साथ काम करता है. ये ऐप्लिकेशन, PHP, Java, Go, Python, Ruby, और ASP.NET जैसी भाषाओं और फ़्रेमवर्क का इस्तेमाल करते हैं.
ऑथराइज़ेशन की प्रोसेस तब शुरू होती है, जब आपका ऐप्लिकेशन किसी ब्राउज़र को Google यूआरएल पर रीडायरेक्ट करता है. इस यूआरएल में क्वेरी पैरामीटर शामिल होते हैं. इनसे, अनुरोध किए जा रहे ऐक्सेस के टाइप का पता चलता है. Google, उपयोगकर्ता की पुष्टि, सेशन चुनने, और उपयोगकर्ता की सहमति को मैनेज करता है. इसके बाद, ऑथराइज़ेशन कोड मिलता है. ऐप्लिकेशन इस कोड को ऐक्सेस टोकन और रीफ़्रेश टोकन के लिए एक्सचेंज कर सकता है.
ऐप्लिकेशन को रीफ़्रेश टोकन को भविष्य में इस्तेमाल करने के लिए सेव करना चाहिए. साथ ही, Google के किसी एपीआई को ऐक्सेस करने के लिए, ऐक्सेस टोकन का इस्तेमाल करना चाहिए. ऐक्सेस टोकन की समयसीमा खत्म होने के बाद, ऐप्लिकेशन रीफ़्रेश टोकन का इस्तेमाल करके नया ऐक्सेस टोकन पा सकता है.
ज़्यादा जानकारी के लिए, वेब सर्वर ऐप्लिकेशन के लिए OAuth 2.0 का इस्तेमाल करना देखें.
इंस्टॉल किए गए ऐप्स
Google OAuth 2.0 एंडपॉइंट, उन ऐप्लिकेशन के साथ काम करता है जो कंप्यूटर, मोबाइल डिवाइस, और टैबलेट जैसे डिवाइसों पर इंस्टॉल किए जाते हैं. Google API Console से क्लाइंट आईडी बनाते समय, यह बताएं कि यह इंस्टॉल किया गया ऐप्लिकेशन है. इसके बाद, ऐप्लिकेशन के टाइप के तौर पर Android, Chrome एक्सटेंशन, iOS या डेस्कटॉप ऐप्लिकेशन चुनें.
इस प्रोसेस के बाद, आपको एक क्लाइंट आईडी और कुछ मामलों में, एक क्लाइंट सीक्रेट मिलता है. इसे अपने ऐप्लिकेशन के सोर्स कोड में एम्बेड करें. (इस संदर्भ में, क्लाइंट सीक्रेट को स्पष्ट रूप से सीक्रेट के तौर पर नहीं माना जाता.)
ऑथराइज़ेशन की प्रोसेस तब शुरू होती है, जब आपका ऐप्लिकेशन किसी ब्राउज़र को Google यूआरएल पर रीडायरेक्ट करता है. इस यूआरएल में क्वेरी पैरामीटर शामिल होते हैं. इनसे, अनुरोध किए जा रहे ऐक्सेस के टाइप का पता चलता है. Google, उपयोगकर्ता की पुष्टि, सेशन चुनने, और उपयोगकर्ता की सहमति को मैनेज करता है. इसके बाद, ऑथराइज़ेशन कोड मिलता है. ऐप्लिकेशन इस कोड को ऐक्सेस टोकन के लिए एक्सचेंज कर सकता है. ऐप्लिकेशन को Google के किसी एपीआई अनुरोध में ऐक्सेस टोकन शामिल करने से पहले, उसे मान्य करना चाहिए. टोकन की समयसीमा खत्म होने पर, ऐप्लिकेशन इस प्रोसेस को दोहराता है.
ज़रूरी नहीं है कि कोई बैकएंड सर्वर, ऑथराइज़ेशन कोड को रीफ़्रेश टोकन के लिए एक्सचेंज करे. हालांकि, अगर ऐसा किया जाता है, तो रीफ़्रेश टोकन को सुरक्षित जगह पर सेव किया जाना चाहिए. ऐक्सेस टोकन की समयसीमा खत्म होने के बाद, बैकएंड सर्वर, ऐप्लिकेशन के लिए नया ऐक्सेस टोकन पाने के लिए, रीफ़्रेश टोकन का इस्तेमाल करता है.
ज़्यादा जानकारी के लिए, Google के उपयोगकर्ता डेटा को ऐक्सेस करने की अनुमति देना Android के लिए, और iOS और डेस्कटॉप ऐप्लिकेशन के लिए OAuth 2.0 देखें.
क्लाइंट-साइड (JavaScript) ऐप्लिकेशन
Google OAuth 2.0 एंडपॉइंट, JavaScript ऐप्लिकेशन के साथ काम करता है. ये ऐप्लिकेशन, ब्राउज़र में चलते हैं.
ऑथराइज़ेशन की प्रोसेस तब शुरू होती है, जब आपका ऐप्लिकेशन किसी ब्राउज़र को Google यूआरएल पर रीडायरेक्ट करता है. इस यूआरएल में क्वेरी पैरामीटर शामिल होते हैं. इनसे, अनुरोध किए जा रहे ऐक्सेस के टाइप का पता चलता है. Google, उपयोगकर्ता की पुष्टि, सेशन चुनने, और उपयोगकर्ता की सहमति को मैनेज करता है.
इसके बाद, ऐक्सेस टोकन मिलता है. क्लाइंट को Google के किसी एपीआई के अनुरोध में ऐक्सेस टोकन शामिल करने से पहले, उसे मान्य करना चाहिए. टोकन की समयसीमा खत्म होने पर, ऐप्लिकेशन इस प्रोसेस को दोहराता है.
ज़्यादा जानकारी के लिए, क्लाइंट-साइड ऐप्लिकेशन के लिए OAuth 2.0 का इस्तेमाल करना देखें.
सीमित इनपुट डिवाइसों पर मौजूद ऐप्लिकेशन
Google OAuth 2.0 एंडपॉइंट, सीमित इनपुट डिवाइसों पर चलने वाले ऐप्लिकेशन के साथ काम करता है. जैसे गेम कंसोल, वीडियो कैमरा, और प्रिंटर.
ऑथराइज़ेशन की प्रोसेस तब शुरू होती है, जब ऐप्लिकेशन, ऑथराइज़ेशन कोड के लिए Google के यूआरएल पर वेब सेवा का अनुरोध करता है. रिस्पॉन्स में कई पैरामीटर शामिल होते हैं. इनमें एक यूआरएल और एक कोड शामिल होता है, जिसे ऐप्लिकेशन उपयोगकर्ता को दिखाता है.
उपयोगकर्ता, डिवाइस से यूआरएल और कोड पाता है. इसके बाद, ज़्यादा इनपुट क्षमताओं वाले किसी दूसरे डिवाइस या कंप्यूटर पर स्विच करता है. उपयोगकर्ता, ब्राउज़र लॉन्च करता है, बताए गए यूआरएल पर जाता है, लॉग इन करता है, और कोड डालता है.
इस दौरान, ऐप्लिकेशन, Google के किसी यूआरएल को तय इंटरवल पर पोल करता है. उपयोगकर्ता के ऐक्सेस की अनुमति देने के बाद, Google के सर्वर से मिलने वाले रिस्पॉन्स में, ऐक्सेस टोकन और रीफ़्रेश टोकन शामिल होता है. ऐप्लिकेशन को रीफ़्रेश टोकन को भविष्य में इस्तेमाल करने के लिए सेव करना चाहिए. साथ ही, Google के किसी एपीआई को ऐक्सेस करने के लिए, ऐक्सेस टोकन का इस्तेमाल करना चाहिए. ऐक्सेस टोकन की समयसीमा खत्म होने के बाद, ऐप्लिकेशन रीफ़्रेश टोकन का इस्तेमाल करके नया ऐक्सेस टोकन पा सकता है.
ज़्यादा जानकारी के लिए, OAuth 2.0 डिवाइसों के लिए इस्तेमाल करना देखें.
सेवा खाते
Google के एपीआई, जैसे कि Prediction API और Google Cloud Storage, उपयोगकर्ता की जानकारी को ऐक्सेस किए बिना, आपके ऐप्लिकेशन की ओर से काम कर सकते हैं. इन स्थितियों में, आपके ऐप्लिकेशन को एपीआई के लिए अपनी पहचान साबित करनी होती है. हालांकि, इसके लिए उपयोगकर्ता की सहमति की ज़रूरत नहीं होती. इसी तरह, एंटरप्राइज़ के उदाहरणों में, आपका ऐप्लिकेशन कुछ संसाधनों के लिए डेलिगेट किए गए ऐक्सेस का अनुरोध कर सकता है.
सर्वर-टू-सर्वर इंटरैक्शन के इन टाइप के लिए, आपको सेवा खाते की ज़रूरत होती है. यह एक ऐसा खाता होता है जो किसी असली उपयोगकर्ता के बजाय, आपके ऐप्लिकेशन का होता है. आपका ऐप्लिकेशन, सेवा खाते की ओर से Google के एपीआई को कॉल करता है. इसके लिए, उपयोगकर्ता की सहमति की ज़रूरत नहीं होती. (सेवा खाते के अलावा अन्य स्थितियों में, आपका ऐप्लिकेशन, असली उपयोगकर्ताओं की ओर से असली उपयोगकर्ताओं की ओर से Google के एपीआई को कॉल करता है. इसके लिए, कभी-कभी उपयोगकर्ता की सहमति की ज़रूरत होती है.)
Google API Console से मिलने वाले सेवा खाते के क्रेडेंशियल में, जनरेट किया गया एक यूनीक ईमेल पता, एक क्लाइंट आईडी, और कम से कम एक पब्लिक/प्राइवेट कुंजी का जोड़ा शामिल होता है. साइन किया गया JWT बनाने और सही फ़ॉर्मैट में ऐक्सेस टोकन का अनुरोध करने के लिए, क्लाइंट आईडी और एक प्राइवेट कुंजी का इस्तेमाल करें. इसके बाद, आपका ऐप्लिकेशन, टोकन का अनुरोध, Google के OAuth 2.0 ऑथराइज़ेशन सर्वर को भेजता है, यह सर्वर, ऐक्सेस टोकन दिखाता है. ऐप्लिकेशन, Google के किसी एपीआई को ऐक्सेस करने के लिए, इस टोकन का इस्तेमाल करता है. टोकन की समयसीमा खत्म होने पर, ऐप्लिकेशन इस प्रोसेस को दोहराता है.
ज़्यादा जानकारी के लिए, सेवा खाते का दस्तावेज़ देखें.
टोकन का साइज़
टोकन का साइज़ अलग-अलग हो सकता है. हालांकि, इनकी सीमाएं इस तरह हैं:
Google Cloud के Security Token Service API से मिलने वाले ऐक्सेस टोकन, Google API के OAuth 2.0 ऐक्सेस टोकन की तरह ही होते हैं. हालांकि, इनके साइज़ की सीमाएं अलग-अलग होती हैं. ज़्यादा जानकारी के लिए, एपीआई का दस्तावेज़ देखें.
Google के पास इन सीमाओं के अंदर, टोकन का साइज़ बदलने का अधिकार सुरक्षित है. आपका ऐप्लिकेशन टोकन के अलग-अलग साइज़ के साथ काम करने के लिए तैयार होना चाहिए.
रीफ़्रेश टोकन की समयसीमा खत्म होना
आपको अपना कोड इस तरह लिखना होगा कि अगर अनुमति दिया गया रीफ़्रेश टोकन काम न करे, तो भी आपका ऐप्लिकेशन काम करता रहे. रीफ़्रेश टोकन, इनमें से किसी वजह से काम करना बंद कर सकता है:
Google Cloud Platform के किसी ऐसे प्रोजेक्ट के लिए, सात दिनों में खत्म होने वाला रीफ़्रेश टोकन जारी किया जाता है जिसमें OAuth की सहमति वाली स्क्रीन, बाहरी उपयोगकर्ता के टाइप के लिए कॉन्फ़िगर की गई हो और पब्लिशिंग की स्थिति "टेस्टिंग" हो. हालांकि, ऐसा तब नहीं होता, जब अनुरोध किए गए OAuth के दायरे, नाम, ईमेल पता, और उपयोगकर्ता की प्रोफ़ाइल के सबसेट हों. जैसे,
userinfo.email, userinfo.profile, openid दायरे या उनके OpenID Connect के बराबर के दायरे.
फ़िलहाल, OAuth 2.0 क्लाइंट आईडी के हिसाब से, हर Google खाते के लिए 100 रीफ़्रेश टोकन की सीमा है. अगर यह सीमा पूरी हो जाती है, तो नया रीफ़्रेश टोकन बनाने पर, सबसे पुराना रीफ़्रेश टोकन बिना किसी चेतावनी के अपने-आप अमान्य हो जाता है. यह सीमा, सेवा खातों पर लागू नहीं होती है .
उपयोगकर्ता खाते या सेवा खाते के पास, सभी क्लाइंट में कुल रीफ़्रेश टोकन की संख्या की एक बड़ी सीमा भी होती है. ज़्यादातर सामान्य उपयोगकर्ता इस सीमा से ज़्यादा रीफ़्रेश टोकन का इस्तेमाल नहीं करते. हालांकि, लागू करने के तरीके की जांच करने के लिए इस्तेमाल किया जाने वाला डेवलपर का खाता, इस सीमा से ज़्यादा रीफ़्रेश टोकन का इस्तेमाल कर सकता है.
अगर आपको एक से ज़्यादा प्रोग्राम, मशीन या डिवाइसों को अनुमति देनी है, तो एक तरीका यह है कि हर Google खाते के लिए, अनुमति दिए जाने वाले क्लाइंट की संख्या को 15 या 20 तक सीमित करें. अगर आप Google Workspace के एडमिन हैं, तो एडमिन के अधिकारों वाले अतिरिक्त उपयोगकर्ता बनाए जा सकते हैं. साथ ही, इनका इस्तेमाल कुछ क्लाइंट को अनुमति देने के लिए किया जा सकता है.
Google Cloud Platform (GCP) के संगठनों के लिए, सेशन कंट्रोल की नीतियों को मैनेज करना
GCP के संगठनों के एडमिन, Google Cloud के सेशन कंट्रोल की सुविधा का इस्तेमाल करके, GCP के संसाधनों को ऐक्सेस करने के दौरान, उपयोगकर्ताओं से बार-बार पुष्टि करने के लिए कह सकते हैं. इस नीति का असर, Google Cloud Console, the
Google Cloud SDK (इसे gcloud
CLI के तौर पर भी जाना जाता है) के ऐक्सेस पर पड़ता है. साथ ही, इस नीति का असर, Cloud Platform के दायरे में आने वाले तीसरे पक्ष के OAuth ऐप्लिकेशन पर भी पड़ता है. अगर किसी उपयोगकर्ता के लिए सेशन कंट्रोल की नीति लागू है, तो सेशन की अवधि खत्म होने पर, आपके एपीआई कॉल में गड़बड़ी होगी. यह गड़बड़ी, रीफ़्रेश टोकन के वापस लिए जाने पर होने वाली गड़बड़ी जैसी ही होगी. कॉल, invalid_grant गड़बड़ी के टाइप के साथ काम नहीं करेगा. error_subtype फ़ील्ड का इस्तेमाल, वापस लिए गए टोकन और सेशन कंट्रोल की नीति की वजह से होने वाली गड़बड़ी के बीच अंतर करने के लिए किया जा सकता है. उदाहरण के लिए, "error_subtype": "invalid_rapt". सेशन की अवधि बहुत सीमित हो सकती है (एक से 24 घंटे के बीच). इसलिए, ऑथराइज़ेशन सेशन को रीस्टार्ट करके, इस स्थिति को आसानी से मैनेज किया जाना चाहिए.
इसी तरह, सर्वर-टू-सर्वर डिप्लॉयमेंट के लिए, उपयोगकर्ता के क्रेडेंशियल का इस्तेमाल नहीं करना चाहिए. साथ ही, दूसरों को भी ऐसा करने के लिए बढ़ावा नहीं देना चाहिए. अगर लंबे समय तक चलने वाले कामों या कार्रवाइयों के लिए, किसी सर्वर पर उपयोगकर्ता के क्रेडेंशियल डिप्लॉय किए जाते हैं और कोई ग्राहक ऐसे उपयोगकर्ताओं पर सेशन कंट्रोल की नीतियां लागू करता है, तो सर्वर ऐप्लिकेशन काम नहीं करेगा. ऐसा इसलिए, क्योंकि सेशन की अवधि खत्म होने पर, उपयोगकर्ता की फिर से पुष्टि करने का कोई तरीका नहीं होगा.
अपने ग्राहकों को इस सुविधा को डिप्लॉय करने में मदद करने के तरीके के बारे में ज़्यादा जानने के लिए, इस एडमिन के लिए बने सहायता केंद्र के लेख को देखें.
क्लाइंट लाइब्रेरी
नीचे दी गई क्लाइंट लाइब्रेरी, लोकप्रिय फ़्रेमवर्क के साथ इंटिग्रेट होती हैं. इससे OAuth 2.0 को लागू करना आसान हो जाता है. समय के साथ, लाइब्रेरी में और सुविधाएं जोड़ी जाएंगी.
- Google Auth Library for Java
- Google API Client Library for Python
- Google API Client Library for Dart
- Google API Client Library for Go
- Google API Client Library for .NET
- Google API Client Library for Ruby
- Google API Client Library for PHP
- Google API Client Library for JavaScript
- GTMAppAuth - OAuth Client Library for Mac and iOS