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 API Console पर जाकर, OAuth 2.0 क्रेडेंशियल पाएं. जैसे, क्लाइंट आईडी और क्लाइंट सीक्रेट. Google और आपके ऐप्लिकेशन, दोनों को इनकी जानकारी होती है. वैल्यू का सेट, इस बात पर निर्भर करता है कि किस तरह का ऐप्लिकेशन बनाया जा रहा है. उदाहरण के लिए, JavaScript ऐप्लिकेशन को सीक्रेट की ज़रूरत नहीं होती, लेकिन वेब सर्वर ऐप्लिकेशन को होती है.
आपको उस प्लैटफ़ॉर्म के लिए सही OAuth क्लाइंट बनाना होगा जिस पर आपका ऐप्लिकेशन चलेगा. उदाहरण के लिए:
- Android ऐप्लिकेशन के लिए, Android ऐप्लिकेशन टाइप का इस्तेमाल करें.
-
iOS ऐप्लिकेशन के लिए, iOS ऐप्लिकेशन टाइप का इस्तेमाल करें.
- desktop_windows डेस्कटॉप ऐप्लिकेशन (जैसे, Windows, macOS या Linux ऐप्लिकेशन या सीएलआई टूल) के लिए, डेस्कटॉप ऐप्लिकेशन टाइप का इस्तेमाल करें.
- कोड सर्वर-साइड या JavaScript वेब ऐप्लिकेशन के लिए, वेब ऐप्लिकेशन ऐप्लिकेशन टाइप का इस्तेमाल करें. इस ऐप्लिकेशन टाइप का इस्तेमाल किसी अन्य ऐप्लिकेशन के लिए न करें. जैसे, नेटिव या मोबाइल ऐप्लिकेशन.
- chrome_extension Chrome एक्सटेंशन के लिए, Chrome एक्सटेंशन ऐप्लिकेशन टाइप का इस्तेमाल करें.
- tv सीमित इनपुट डिवाइसों, जैसे कि टीवी या एम्बेड किए गए डिवाइसों के लिए, टीवी और सीमित इनपुट डिवाइस ऐप्लिकेशन टाइप का इस्तेमाल करें.
- होस्ट सर्वर-टू-सर्वर इंटरैक्शन के लिए, सेवा खातों का इस्तेमाल करें. इसके लिए, OAuth क्लाइंट आईडी की ज़रूरत नहीं होती.
2. Google Authorization Server से ऐक्सेस टोकन पाएं.
Google API का इस्तेमाल करके निजी डेटा ऐक्सेस करने से पहले, आपके ऐप्लिकेशन को एक ऐक्सेस टोकन पाना होगा. इससे उस एपीआई को ऐक्सेस करने की अनुमति मिलती है. एक ऐक्सेस टोकन से, कई एपीआई को अलग-अलग लेवल का ऐक्सेस दिया जा सकता है. scope नाम का एक वैरिएबल पैरामीटर, उन संसाधनों और कार्रवाइयों के सेट को कंट्रोल करता है जिनकी अनुमति ऐक्सेस टोकन देता है. ऐक्सेस-टोकन के अनुरोध के दौरान, आपका ऐप्लिकेशन scope पैरामीटर में एक या उससे ज़्यादा वैल्यू भेजता है.
यह अनुरोध करने के कई तरीके हैं. ये तरीके, आपके बनाए जा रहे ऐप्लिकेशन के टाइप के हिसाब से अलग-अलग होते हैं. उदाहरण के लिए, कोई JavaScript ऐप्लिकेशन, Google पर ब्राउज़र रीडायरेक्ट का इस्तेमाल करके ऐक्सेस टोकन का अनुरोध कर सकता है. वहीं, बिना ब्राउज़र वाले डिवाइस पर इंस्टॉल किया गया ऐप्लिकेशन, वेब सेवा के अनुरोधों का इस्तेमाल करता है. अनुरोध करने के तरीके के बारे में ज़्यादा जानने के लिए, Scenarios और हर तरह के ऐप्लिकेशन के लिए, लागू करने के बारे में ज़्यादा जानकारी देने वाली गाइड देखें.
कुछ अनुरोधों के लिए, पुष्टि करने की ज़रूरत होती है. इसके लिए, उपयोगकर्ता को अपने Google खाते से लॉग इन करना होता है. लॉग इन करने के बाद, उपयोगकर्ता से पूछा जाता है कि क्या वह आपके ऐप्लिकेशन को एक या उससे ज़्यादा अनुमतियां देना चाहता है. इस प्रोसेस को उपयोगकर्ता की सहमति कहा जाता है.
अगर उपयोगकर्ता कम से कम एक अनुमति देता है, तो Google का ऑथराइज़ेशन सर्वर आपके ऐप्लिकेशन को एक ऐक्सेस टोकन (या एक ऑथराइज़ेशन कोड जिसका इस्तेमाल करके आपका ऐप्लिकेशन ऐक्सेस टोकन हासिल कर सकता है) और उस टोकन से मिलने वाले ऐक्सेस के स्कोप की सूची भेजता है. अगर उपयोगकर्ता अनुमति नहीं देता है, तो सर्वर गड़बड़ी का मैसेज दिखाता है.
आम तौर पर, स्कोप का अनुरोध एक साथ करने के बजाय, ज़रूरत पड़ने पर धीरे-धीरे करना सबसे सही तरीका माना जाता है. उदाहरण के लिए, अगर कोई ऐप्लिकेशन किसी इवेंट को कैलेंडर में सेव करने की सुविधा देना चाहता है, तो उसे Google 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 को भेजता है. टोकन को यूआरआई क्वेरी-स्ट्रिंग पैरामीटर के तौर पर भेजा जा सकता है. हालांकि, हमारा सुझाव है कि ऐसा न करें, क्योंकि यूआरआई पैरामीटर ऐसी लॉग फ़ाइलों में सेव हो सकते हैं जो पूरी तरह से सुरक्षित नहीं हैं. साथ ही, REST का सबसे सही तरीका यह है कि यूआरआई पैरामीटर के नाम बेवजह न बनाए जाएं.
ऐक्सेस टोकन, सिर्फ़ उन कार्रवाइयों और संसाधनों के लिए मान्य होते हैं जिनके बारे में टोकन के अनुरोध के scope में बताया गया है. उदाहरण के लिए, अगर Google Calendar API के लिए कोई ऐक्सेस टोकन जारी किया जाता है, तो उससे Google Contacts API को ऐक्सेस नहीं किया जा सकता. हालांकि, एक जैसी कार्रवाइयों के लिए, उस ऐक्सेस टोकन को Google Calendar API पर कई बार भेजा जा सकता है.
5. अगर ज़रूरी हो, तो ऐक्सेस टोकन को रीफ़्रेश करें.
ऐक्सेस टोकन सीमित समय के लिए मान्य होते हैं. अगर आपके ऐप्लिकेशन को किसी Google API के ऐक्सेस की ज़रूरत है, तो वह एक ऐक्सेस टोकन की समयसीमा खत्म होने के बाद, रीफ़्रेश टोकन पा सकता है. रीफ़्रेश टोकन की मदद से, आपका ऐप्लिकेशन नए ऐक्सेस टोकन हासिल कर सकता है.
अलग-अलग चैनलों के लिए बजट
इन उदाहरणों में बताया गया है कि अलग-अलग तरह के ऐप्लिकेशन के लिए, OAuth 2.0 का इस्तेमाल करके ऑथराइज़ेशन कोड का अनुरोध कैसे किया जाता है. साथ ही, ऐक्सेस और रीफ़्रेश टोकन पाने का तरीका भी बताया गया है.
वेब सर्वर ऐप्लिकेशन
Google OAuth 2.0 एंडपॉइंट, वेब सर्वर ऐप्लिकेशन के साथ काम करता है. ये ऐप्लिकेशन, PHP, Java, Go, Python, Ruby, और ASP.NET जैसी भाषाओं और फ़्रेमवर्क का इस्तेमाल करते हैं.
अनुमति देने का क्रम तब शुरू होता है, जब आपका ऐप्लिकेशन किसी ब्राउज़र को Google के यूआरएल पर रीडायरेक्ट करता है. यूआरएल में क्वेरी पैरामीटर शामिल होते हैं, जो यह बताते हैं कि किस तरह के ऐक्सेस का अनुरोध किया जा रहा है. Google, उपयोगकर्ता की पुष्टि, सेशन चुनने, और उपयोगकर्ता की सहमति को मैनेज करता है. इसके बाद, एक ऑथराइज़ेशन कोड मिलता है. ऐप्लिकेशन इस कोड को ऐक्सेस टोकन और रीफ़्रेश टोकन से बदल सकता है.
ऐप्लिकेशन को आने वाले समय में इस्तेमाल करने के लिए, रीफ़्रेश टोकन को सेव करना चाहिए. साथ ही, Google API को ऐक्सेस करने के लिए, ऐक्सेस टोकन का इस्तेमाल करना चाहिए. ऐक्सेस टोकन की समयसीमा खत्म होने के बाद, ऐप्लिकेशन नया टोकन पाने के लिए रीफ़्रेश टोकन का इस्तेमाल करता है.
ज़्यादा जानकारी के लिए, वेब सर्वर ऐप्लिकेशन के लिए OAuth 2.0 का इस्तेमाल करना लेख पढ़ें.
इंस्टॉल किए गए ऐप्स
Google OAuth 2.0 एंडपॉइंट, कंप्यूटर, मोबाइल डिवाइस, और टैबलेट जैसे डिवाइसों पर इंस्टॉल किए गए ऐप्लिकेशन के साथ काम करता है. Google API Console की मदद से क्लाइंट आईडी बनाते समय, यह बताएं कि यह इंस्टॉल किया गया ऐप्लिकेशन है. इसके बाद, ऐप्लिकेशन टाइप के तौर पर Android, Chrome एक्सटेंशन, iOS या डेस्कटॉप ऐप्लिकेशन चुनें.
इस प्रोसेस से एक क्लाइंट आईडी मिलता है. कुछ मामलों में, एक क्लाइंट सीक्रेट भी मिलता है. इसे आपको अपने ऐप्लिकेशन के सोर्स कोड में एम्बेड करना होता है. (इस मामले में, क्लाइंट सीक्रेट को ज़ाहिर तौर पर सीक्रेट नहीं माना जाता.)
अनुमति देने का क्रम तब शुरू होता है, जब आपका ऐप्लिकेशन किसी ब्राउज़र को Google के यूआरएल पर रीडायरेक्ट करता है. यूआरएल में क्वेरी पैरामीटर शामिल होते हैं, जो यह बताते हैं कि किस तरह के ऐक्सेस का अनुरोध किया जा रहा है. Google, उपयोगकर्ता की पुष्टि, सेशन चुनने, और उपयोगकर्ता की सहमति को मैनेज करता है. इसके बाद, एक ऑथराइज़ेशन कोड मिलता है. ऐप्लिकेशन इस कोड को ऐक्सेस टोकन से बदल सकता है. ऐप्लिकेशन को Google API अनुरोध में शामिल करने से पहले, ऐक्सेस टोकन की पुष्टि करनी चाहिए. टोकन की समयसीमा खत्म होने पर, ऐप्लिकेशन इस प्रोसेस को दोहराता है.
इसके अलावा, बैकएंड सर्वर, ऑथराइज़ेशन कोड को रीफ़्रेश टोकन से बदल सकता है. साथ ही, उसे किसी सुरक्षित जगह पर सेव कर सकता है. ऐक्सेस टोकन की समयसीमा खत्म होने के बाद, बैकएंड सर्वर रीफ़्रेश टोकन का इस्तेमाल करके, ऐप्लिकेशन के लिए नया ऐक्सेस टोकन हासिल करता है.
ज़्यादा जानकारी के लिए, Android के लिए Google उपयोगकर्ता के डेटा को ऐक्सेस करने की अनुमति दें, iOS ऐप्लिकेशन में Google API ऐक्सेस करें, और डेस्कटॉप ऐप्लिकेशन के लिए OAuth 2.0 देखें.
क्लाइंट-साइड (JavaScript) ऐप्लिकेशन
Google OAuth 2.0 एंडपॉइंट, ब्राउज़र में चलने वाले JavaScript ऐप्लिकेशन के साथ काम करता है.
अनुमति देने का क्रम तब शुरू होता है, जब आपका ऐप्लिकेशन किसी ब्राउज़र को Google के यूआरएल पर रीडायरेक्ट करता है. यूआरएल में क्वेरी पैरामीटर शामिल होते हैं, जो यह बताते हैं कि किस तरह के ऐक्सेस का अनुरोध किया जा रहा है. 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 को कॉल करता है. साथ ही, कभी-कभी उपयोगकर्ता की सहमति ज़रूरी होती है.)
सेवा खाते के क्रेडेंशियल, आपको Google API Console से मिलते हैं. इनमें एक यूनीक ईमेल पता, क्लाइंट आईडी, और कम से कम एक सार्वजनिक/निजी कुंजी का जोड़ा शामिल होता है. साइन किया हुआ JWT बनाने और सही फ़ॉर्मैट में ऐक्सेस-टोकन का अनुरोध करने के लिए, क्लाइंट आईडी और एक निजी पासकोड का इस्तेमाल किया जाता है. इसके बाद, आपका ऐप्लिकेशन Google OAuth 2.0 ऑथराइज़ेशन सर्वर को टोकन का अनुरोध भेजता है. यह सर्वर, ऐक्सेस टोकन दिखाता है. ऐप्लिकेशन, Google API को ऐक्सेस करने के लिए टोकन का इस्तेमाल करता है. टोकन की समयसीमा खत्म होने पर, ऐप्लिकेशन इस प्रोसेस को दोहराता है.
ज़्यादा जानकारी के लिए, सेवा खाते से जुड़ा दस्तावेज़ देखें.
टोकन का साइज़
टोकन का साइज़ अलग-अलग हो सकता है. हालांकि, यह इन सीमाओं के अंदर होना चाहिए:
Google Cloud के सिक्योरिटी टोकन सर्विस एपीआई से मिले ऐक्सेस टोकन, Google API के OAuth 2.0 ऐक्सेस टोकन की तरह ही होते हैं. हालांकि, टोकन के साइज़ की सीमाएं अलग-अलग होती हैं. ज़्यादा जानकारी के लिए, एपीआई से जुड़ा दस्तावेज़ देखें.
Google, इन सीमाओं के अंदर टोकन के साइज़ में बदलाव करने का अधिकार सुरक्षित रखता है. साथ ही, आपके ऐप्लिकेशन को टोकन के अलग-अलग साइज़ के साथ काम करना चाहिए.
रीफ़्रेश टोकन की समयसीमा खत्म होना
आपको अपना कोड इस तरह लिखना चाहिए कि अगर दिया गया रीफ़्रेश टोकन काम न करे, तो भी आपका ऐप्लिकेशन काम करता रहे. इनमें से किसी एक वजह से, रीफ़्रेश टोकन काम करना बंद कर सकता है:
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 सीएलआई भी कहा जाता है), और तीसरे पक्ष के ऐसे किसी भी OAuth ऐप्लिकेशन के ऐक्सेस पर पड़ता है जिसके लिए Cloud Platform के स्कोप की ज़रूरत होती है. अगर किसी उपयोगकर्ता के लिए सेशन कंट्रोल की नीति लागू है, तो सेशन की अवधि खत्म होने पर आपके एपीआई कॉल में गड़बड़ी दिखेगी. यह गड़बड़ी वैसी ही होगी जैसी रीफ़्रेश टोकन रद्द होने पर दिखती है. कॉल में invalid_grant गड़बड़ी दिखेगी. error_subtype फ़ील्ड का इस्तेमाल करके, रद्द किए गए टोकन और सेशन कंट्रोल की नीति की वजह से हुई गड़बड़ी के बीच अंतर किया जा सकता है. उदाहरण के लिए, "error_subtype": "invalid_rapt". सेशन कितनी देर चला, यह बहुत कम हो सकता है (1 घंटे से 24 घंटे के बीच). इसलिए, इस स्थिति को ठीक से मैनेज करने के लिए, पुष्टि करने वाले सेशन को रीस्टार्ट करना ज़रूरी है.
इसी तरह, आपको सर्वर-टू-सर्वर डिप्लॉयमेंट के लिए, उपयोगकर्ता के क्रेडेंशियल का इस्तेमाल नहीं करना चाहिए या इसके इस्तेमाल को बढ़ावा नहीं देना चाहिए. अगर उपयोगकर्ता के क्रेडेंशियल, लंबे समय तक चलने वाले कामों या कार्रवाइयों के लिए किसी सर्वर पर डिप्लॉय किए जाते हैं और कोई ग्राहक ऐसे उपयोगकर्ताओं पर सेशन कंट्रोल की नीतियां लागू करता है, तो सर्वर ऐप्लिकेशन काम नहीं करेगा. ऐसा इसलिए होगा, क्योंकि सेशन कितनी देर चला, यह अवधि खत्म होने पर, उपयोगकर्ता की फिर से पुष्टि करने का कोई तरीका नहीं होगा.
अपने ग्राहकों को इस सुविधा को डिप्लॉय करने में मदद करने के तरीके के बारे में ज़्यादा जानने के लिए, एडमिन के लिए उपलब्ध सहायता लेख पढ़ें.
क्लाइंट लाइब्रेरी
यहां दी गई क्लाइंट लाइब्रेरी, लोकप्रिय फ़्रेमवर्क के साथ इंटिग्रेट होती हैं. इससे OAuth 2.0 को लागू करना आसान हो जाता है. समय के साथ, लाइब्रेरी में और सुविधाएं जोड़ी जाएंगी.
- Java के लिए Google Auth Library
- Python के लिए Google API की क्लाइंट लाइब्रेरी
- Dart के लिए Google API क्लाइंट लाइब्रेरी
- Go के लिए Google API क्लाइंट लाइब्रेरी
- .NET के लिए Google API क्लाइंट लाइब्रेरी
- Ruby के लिए Google API की क्लाइंट लाइब्रेरी
- PHP के लिए Google API क्लाइंट लाइब्रेरी
- JavaScript के लिए Google API क्लाइंट लाइब्रेरी
- GTMAppAuth - Mac और iOS के लिए OAuth क्लाइंट लाइब्रेरी