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