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 क्लाइंट बनाना होगा जिस पर आपका ऐप्लिकेशन चलेगा. उदाहरण के लिए:
- Android ऐप्लिकेशन के लिए, Android ऐप्लिकेशन टाइप का इस्तेमाल करें.
-
iOS ऐप्लिकेशन के लिए,
iOS ऐप्लिकेशन टाइप का इस्तेमाल करें.
- desktop_windows डेस्कटॉप ऐप्लिकेशन (जैसे, Windows, macOS या Linux ऐप्लिकेशन या सीएलआई टूल) के लिए, डेस्कटॉप ऐप्लिकेशन टाइप का इस्तेमाल करें.
- कोड सर्वर-साइड या JavaScript वेब ऐप्लिकेशन के लिए, वेब ऐप्लिकेशन ऐप्लिकेशन टाइप का इस्तेमाल करें. इस ऐप्लिकेशन टाइप का इस्तेमाल किसी अन्य ऐप्लिकेशन के लिए न करें. जैसे, नेटिव या मोबाइल ऐप्लिकेशन.
- chrome_extension Chrome एक्सटेंशन के लिए, Chrome एक्सटेंशन ऐप्लिकेशन टाइप का इस्तेमाल करें.
- tv सीमित इनपुट डिवाइसों, जैसे कि टीवी या एम्बेड किए गए डिवाइसों के लिए, टीवी और सीमित इनपुट डिवाइस ऐप्लिकेशन टाइप का इस्तेमाल करें.
- होस्ट सर्वर-टू-सर्वर इंटरैक्शन के लिए, सेवा खातों का इस्तेमाल करें. इसके लिए, OAuth क्लाइंट आईडी की ज़रूरत नहीं होती.
2. Google के ऑथराइज़ेशन सर्वर से ऐक्सेस टोकन पाना.
Google API का इस्तेमाल करके निजी डेटा ऐक्सेस करने से पहले, आपके ऐप्लिकेशन को एक ऐक्सेस टोकन पाना होगा. इससे उस एपीआई को ऐक्सेस किया जा सकेगा. एक ऐक्सेस टोकन से, कई एपीआई को अलग-अलग लेवल का ऐक्सेस दिया जा सकता है. scope नाम का एक वैरिएबल पैरामीटर, उन संसाधनों और कार्रवाइयों के सेट को कंट्रोल करता है जिनकी अनुमति ऐक्सेस टोकन देता है. ऐक्सेस-टोकन के अनुरोध के दौरान, आपका ऐप्लिकेशन scope पैरामीटर में एक या उससे ज़्यादा वैल्यू भेजता है.
यह अनुरोध करने के कई तरीके हैं. ये तरीके, बनाए जा रहे ऐप्लिकेशन के टाइप के हिसाब से अलग-अलग होते हैं. उदाहरण के लिए, कोई JavaScript ऐप्लिकेशन, Google पर ब्राउज़र रीडायरेक्ट का इस्तेमाल करके ऐक्सेस टोकन का अनुरोध कर सकता है. वहीं, बिना ब्राउज़र वाले डिवाइस पर इंस्टॉल किया गया ऐप्लिकेशन, वेब सेवा के अनुरोधों का इस्तेमाल करता है. अनुरोध करने के तरीके के बारे में ज़्यादा जानकारी के लिए, Scenarios और हर तरह के ऐप्लिकेशन के लिए, लागू करने के बारे में जानकारी देने वाली गाइड देखें.
कुछ अनुरोधों के लिए, पुष्टि करने की ज़रूरत होती है. इसके लिए, उपयोगकर्ता को अपने Google खाते से लॉग इन करना होता है. लॉग इन करने के बाद, उपयोगकर्ता से पूछा जाता है कि क्या वह आपके ऐप्लिकेशन को एक या उससे ज़्यादा अनुमतियां देना चाहता है. इस प्रोसेस को उपयोगकर्ता की सहमति कहा जाता है.
अगर उपयोगकर्ता कम से कम एक अनुमति देता है, तो Google का ऑथराइज़ेशन सर्वर आपके ऐप्लिकेशन को एक ऐक्सेस टोकन (या एक ऑथराइज़ेशन कोड जिसका इस्तेमाल करके आपका ऐप्लिकेशन ऐक्सेस टोकन हासिल कर सकता है) और उस टोकन से मिलने वाले ऐक्सेस के स्कोप की सूची भेजता है. अगर उपयोगकर्ता अनुमति नहीं देता है, तो सर्वर गड़बड़ी का मैसेज दिखाता है.
आम तौर पर, स्कोप का अनुरोध पहले से करने के बजाय, ज़रूरत पड़ने पर करना सबसे सही तरीका है. उदाहरण के लिए, अगर कोई ऐप्लिकेशन किसी इवेंट को कैलेंडर में सेव करने की सुविधा देना चाहता है, तो उसे Google Calendar का ऐक्सेस तब तक नहीं मांगना चाहिए, जब तक उपयोगकर्ता "कैलेंडर में जोड़ें" बटन नहीं दबाता. इंक्रीमेंटल ऑथराइज़ेशन देखें.
3. उपयोगकर्ता ने ऐक्सेस के जो दायरे तय किए हैं उनकी जांच करें.
ऐक्सेस टोकन के रिस्पॉन्स में शामिल स्कोप की तुलना, उन स्कोप से करें जो आपके ऐप्लिकेशन की सुविधाओं और फ़ंक्शन को ऐक्सेस करने के लिए ज़रूरी हैं. ये सुविधाएं और फ़ंक्शन, Google APIs के ऐक्सेस पर निर्भर करते हैं. अपने ऐप्लिकेशन की ऐसी सभी सुविधाएं बंद कर दें जो संबंधित एपीआई के ऐक्सेस के बिना काम नहीं कर सकतीं.
ऐसा हो सकता है कि आपके अनुरोध में शामिल स्कोप, आपके जवाब में शामिल स्कोप से मेल न खाए. भले ही, उपयोगकर्ता ने अनुरोध किए गए सभी स्कोप को अनुमति दी हो. ऐक्सेस के लिए ज़रूरी स्कोप के बारे में जानने के लिए, हर 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 के 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 संगठनों के एडमिन को 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 क्लाइंट लाइब्रेरी