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 का इस्तेमाल करें.

इस पेज पर, 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 क्लाइंट बनाना होगा जिस पर आपका ऐप्लिकेशन चलेगा. उदाहरण के लिए:

2. Google ऑथराइज़ेशन सर्वर से ऐक्सेस टोकन पाना.

इससे पहले कि आपका ऐप्लिकेशन, Google API का इस्तेमाल करके निजी डेटा को ऐक्सेस कर सके, उसे एक ऐक्सेस टोकन हासिल करना होगा, जो उस एपीआई का ऐक्सेस देता है. एक ऐक्सेस टोकन से कई एपीआई को अलग-अलग लेवल का ऐक्सेस मिल सकता है. scope नाम का वैरिएबल पैरामीटर, उन रिसॉर्स और कार्रवाइयों के सेट को कंट्रोल करता है जिन्हें ऐक्सेस टोकन अनुमति देता है. ऐक्सेस-टोकन अनुरोध के दौरान, आपका ऐप्लिकेशन scope पैरामीटर में एक या उससे ज़्यादा मान भेजता है.

यह अनुरोध करने के कई तरीके हैं. ये इस बात पर निर्भर करते हैं कि आप किस तरह का ऐप्लिकेशन बना रहे हैं. उदाहरण के लिए, कोई JavaScript ऐप्लिकेशन किसी ब्राउज़र पर Google को रीडायरेक्ट करने के लिए, ऐक्सेस टोकन का अनुरोध कर सकता है. वहीं, डिवाइस पर इंस्टॉल किए गए किसी ऐप्लिकेशन में वेब सेवा के अनुरोधों का इस्तेमाल किया जाता है.

कुछ अनुरोधों के लिए पुष्टि करने के एक ऐसे चरण की ज़रूरत होती है जिसमें उपयोगकर्ता अपने Google खाते से लॉग इन करता है. लॉग इन करने के बाद, उपयोगकर्ता से पूछा जाता है कि क्या वह आपके ऐप्लिकेशन के लिए अनुरोध की जा रही एक या उससे ज़्यादा अनुमतियां देना चाहता है. इस प्रोसेस को उपयोगकर्ता की सहमति कहते हैं.

अगर उपयोगकर्ता कम से कम एक अनुमति देता है, तो Google ऑथराइज़ेशन सर्वर आपके ऐप्लिकेशन को एक ऐक्सेस टोकन (या एक ऑथराइज़ेशन कोड, जिसका इस्तेमाल आपका ऐप्लिकेशन ऐक्सेस टोकन पाने के लिए कर सकता है) और उस टोकन से मिले ऐक्सेस के दायरों की सूची भेजता है. अगर उपयोगकर्ता अनुमति नहीं देता है, तो सर्वर एक गड़बड़ी दिखाता है.

आम तौर पर, पहले से ऐक्सेस की ज़रूरत होने पर, दायरा बढ़ाने का अनुरोध करना सबसे अच्छा तरीका होता है. उदाहरण के लिए, जो ऐप्लिकेशन किसी इवेंट को कैलेंडर में सेव करना चाहता है उसे Google Calendar के ऐक्सेस का अनुरोध तब तक नहीं करना चाहिए, जब तक उपयोगकर्ता "Calendar में जोड़ें" बटन नहीं दबाता. इंक्रीमेंटल ऑथराइज़ेशन देखें.

3. उपयोगकर्ता के दिए गए ऐक्सेस के दायरे की जांच करें.

मिलते-जुलते Google API के ऐक्सेस के हिसाब से, आपके ऐप्लिकेशन की सुविधाओं और फ़ंक्शन को ऐक्सेस करने के लिए, ज़रूरी शर्तों के दायरे में ऐक्सेस टोकन में शामिल दायरों की तुलना करें. मिलते-जुलते एपीआई को ऐक्सेस किए बिना, अपने ऐप्लिकेशन की ऐसी सभी सुविधाएं बंद कर दें जो काम नहीं कर सकतीं.

हो सकता है कि आपके अनुरोध में शामिल किया गया दायरा, आपके जवाब में शामिल किए गए दायरे से मेल न खाए. भले ही, उपयोगकर्ता ने अनुरोध किए गए सभी दायरे दिए हों. ऐक्सेस करने के लिए ज़रूरी दायरों के बारे में जानने के लिए, हर Google API के दस्तावेज़ देखें. कोई एपीआई, ऐक्सेस के दायरे वाले एक से ज़्यादा दायरे वाली स्ट्रिंग की वैल्यू को मैप कर सकता है. ऐसा करने से, अनुरोध में स्वीकार की गई सभी वैल्यू के लिए एक ही दायरे की स्ट्रिंग मिल सकती है. उदाहरण के लिए: जब किसी ऐप्लिकेशन में उपयोगकर्ता से https://www.google.com/m8/feeds/ के दायरे को अनुमति देने के लिए, https://www.googleapis.com/auth/contacts Google API को दायरे के तौर पर दिखाया जाता है, तो Google का 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, Python, Ruby, और ASP.NET जैसे फ़्रेमवर्क और भाषाएं इस्तेमाल की जाती हैं.

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

ऐप्लिकेशन को आने वाले समय में इस्तेमाल करने के लिए, रीफ़्रेश टोकन सेव करके रखना होगा और Google API ऐक्सेस करने के लिए, ऐक्सेस टोकन का इस्तेमाल करना चाहिए. जब ऐक्सेस टोकन खत्म हो जाता है, तब ऐप्लिकेशन रीफ़्रेश टोकन का इस्तेमाल करके, नया टोकन जनरेट करता है.

आपका ऐप्लिकेशन, Google ऑथराइज़ेशन सर्वर पर एक टोकन अनुरोध भेजता है. इस अनुरोध को एक ऑथराइज़ेशन कोड मिलता है, उसे किसी टोकन के लिए बदला जाता है, और उसे टोकन इस्तेमाल करके, Google के एपीआई एंडपॉइंट को कॉल किया जाता है.

ज़्यादा जानकारी के लिए, वेब सर्वर ऐप्लिकेशन के लिए OAuth 2.0 का इस्तेमाल करना देखें.

इंस्‍टॉल किए गए ऐप्स

Google OAuth 2.0 एंडपॉइंट उन ऐप्लिकेशन के साथ काम करता है जो कंप्यूटर, मोबाइल डिवाइसों, और टैबलेट जैसे डिवाइसों पर इंस्टॉल किए गए हैं. Google API Console का इस्तेमाल करके क्लाइंट आईडी बनाते समय, बताएं कि यह एक इंस्टॉल किया गया ऐप्लिकेशन है. इसके बाद, ऐप्लिकेशन टाइप के तौर पर Android, Chrome ऐप्लिकेशन, iOS, यूनिवर्सल Windows प्लैटफ़ॉर्म (UWP) या डेस्कटॉप ऐप्लिकेशन चुनें.

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

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

ऐप्लिकेशन को आने वाले समय में इस्तेमाल करने के लिए, रीफ़्रेश टोकन सेव करके रखना होगा और Google API ऐक्सेस करने के लिए, ऐक्सेस टोकन का इस्तेमाल करना चाहिए. जब ऐक्सेस टोकन खत्म हो जाता है, तब ऐप्लिकेशन रीफ़्रेश टोकन का इस्तेमाल करके, नया टोकन जनरेट करता है.

आपका ऐप्लिकेशन, Google ऑथराइज़ेशन सर्वर पर एक टोकन अनुरोध भेजता है. इस अनुरोध को एक ऑथराइज़ेशन कोड मिलता है, उसे किसी टोकन के लिए बदला जाता है, और उसे टोकन इस्तेमाल करके, Google के एपीआई एंडपॉइंट को कॉल किया जाता है.

ज़्यादा जानकारी के लिए, इंस्टॉल किए गए ऐप्लिकेशन के लिए OAuth 2.0 का इस्तेमाल करना देखें.

क्लाइंट-साइड (JavaScript) ऐप्लिकेशन

Google OAuth 2.0 एंडपॉइंट, ब्राउज़र में चलने वाले JavaScript ऐप्लिकेशन के साथ काम करता है.

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

इससे एक ऐक्सेस टोकन मिलता है. क्लाइंट को इसे Google API के अनुरोध में शामिल करने से पहले पुष्टि करनी चाहिए. टोकन की समयसीमा खत्म हो जाने पर, ऐप्लिकेशन इस प्रोसेस को दोहराता है.

आपका JS ऐप्लिकेशन, Google ऑथराइज़ेशन सर्वर पर टोकन अनुरोध भेजता है, उसे टोकन मिलता है, और टोकन की पुष्टि करता है और टोकन का इस्तेमाल, Google API एंडपॉइंट को कॉल करने के लिए करता है.

ज़्यादा जानकारी के लिए, क्लाइंट-साइड ऐप्लिकेशन के लिए OAuth 2.0 का इस्तेमाल करना देखें.

सीमित इनपुट वाले डिवाइस पर ऐप्लिकेशन

Google OAuth 2.0 एंडपॉइंट, सीमित कंसोल पर चलने वाले ऐप्लिकेशन जैसे कि गेम कंसोल, वीडियो कैमरा, और प्रिंटर पर काम करता है.

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

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

इस बीच, ऐप्लिकेशन तय किए गए समय अंतराल पर Google के यूआरएल को पोल करता है. जब उपयोगकर्ता ऐक्सेस को मंज़ूरी दे देता है, तब Google सर्वर के रिस्पॉन्स में ऐक्सेस टोकन और रीफ़्रेश टोकन शामिल होता है. इस ऐप्लिकेशन को आने वाले समय में इस्तेमाल करने के लिए, रीफ़्रेश टोकन सेव करके रखने होंगे और Google API ऐक्सेस करने के लिए, ऐक्सेस टोकन का इस्तेमाल करना चाहिए. ऐक्सेस टोकन की समयसीमा खत्म होने के बाद, ऐप्लिकेशन नया टोकन लेने के लिए, रीफ़्रेश टोकन का इस्तेमाल करता है.

उपयोगकर्ता किसी ऐसे अलग डिवाइस में लॉग इन करता है जिसमें ब्राउज़र है

ज़्यादा जानकारी के लिए, डिवाइसों के लिए OAuth 2.0 का इस्तेमाल करना देखें.

सेवा खाते

Google API, जैसे कि Prediction API और Google Cloud Storage, उपयोगकर्ता की जानकारी ऐक्सेस किए बिना आपके ऐप्लिकेशन की ओर से काम कर सकते हैं. इन स्थितियों में, यह ज़रूरी है कि आपके ऐप्लिकेशन को इस एपीआई को अपनी पहचान साबित करनी हो. ऐसे में, उपयोगकर्ता की सहमति लेना ज़रूरी नहीं है. इसी तरह, एंटरप्राइज़ स्थितियों में, आपका ऐप्लिकेशन कुछ संसाधनों का ऐक्सेस मांग सकता है.

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

Google API Consoleसे मिले सेवा खाते के क्रेडेंशियल में, जनरेट किया गया ईमेल पता शामिल होता है. यह ईमेल पता यूनीक, क्लाइंट आईडी, और कम से कम एक सार्वजनिक/निजी कुंजी का जोड़ा होता है. हस्ताक्षर किए गए JWT बनाने और सही फ़ॉर्मैट में ऐक्सेस-टोकन अनुरोध बनाने के लिए, Client-ID और एक निजी कुंजी का इस्तेमाल करें. इसके बाद, आपका ऐप्लिकेशन Google OAuth 2.0 के ऑथराइज़ेशन सर्वर पर टोकन का अनुरोध भेजता है. यह सर्वर, ऐक्सेस टोकन दिखाता है. इस ऐप्लिकेशन में, Google API को ऐक्सेस करने के लिए टोकन का इस्तेमाल किया जाता है. टोकन की समयसीमा खत्म हो जाने पर, ऐप्लिकेशन इस प्रोसेस को दोहराता है.

आपका सर्वर ऐप्लिकेशन, Google ऑथराइज़ेशन सर्वर से टोकन का अनुरोध करने के लिए, JWT का इस्तेमाल करता है. इसके बाद, Google API एंडपॉइंट को कॉल करने के लिए टोकन का इस्तेमाल करता है. इस काम में असली उपयोगकर्ता शामिल नहीं होता.

ज़्यादा जानकारी के लिए, सेवा-खाते का दस्तावेज़ देखें.

टोकन का साइज़

टोकन का साइज़ नीचे दी गई सीमाओं तक अलग-अलग हो सकता है:

  • ऑथराइज़ेशन कोड: 256 बाइट
  • ऐक्सेस टोकन: 2048 बाइट
  • टोकन रीफ़्रेश करें: 512 बाइट

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

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

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

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

बाहरी उपयोगकर्ता के टाइप और "टेस्टिंग" के पब्लिश होने की स्थिति के लिए कॉन्फ़िगर किए गए OAuth Google Cloud प्रोजेक्ट में, सात दिनों में एक रीफ़्रेश टोकन जारी किया जाता है. ऐसा तब होता है, जब अनुरोध करने वाले OAuth दायरों में सिर्फ़ नाम, ईमेल पते, और उपयोगकर्ता प्रोफ़ाइल या OpenID Connect जैसे मिलते-जुलते के ज़रिए शामिल किया गया हो. userinfo.email, userinfo.profile, openid

फ़िलहाल, हर Google खाते के लिए OAuth 2.0 क्लाइंट आईडी के लिए ज़्यादा से ज़्यादा 100 रीफ़्रेश टोकन बनाए जा सकते हैं. अगर तय सीमा पूरी हो जाती है, तो नया रीफ़्रेश टोकन बनाने पर, बिना किसी चेतावनी के सबसे पुराना रीफ़्रेश टोकन अपने-आप अमान्य हो जाता है. यह सीमा सेवा खातों पर लागू नहीं होती.

किसी उपयोगकर्ता खाते या सेवा खाते के सभी क्लाइंट के लिए, रीफ़्रेश टोकन की कुल संख्या की भी ज़्यादा सीमा है. ज़्यादातर सामान्य उपयोगकर्ता, इस सीमा को पार नहीं करते हैं. इसलिए, लागू करने की जांच के लिए इस्तेमाल किए गए डेवलपर के खाते से, सीमा को पार किया जा सकता है.

अगर आपको एक से ज़्यादा प्रोग्राम, मशीन या डिवाइसों को अनुमति देनी है, तो एक तरीका यह है कि हर Google खाते के लिए अनुमति वाले क्लाइंट की संख्या को 15 या 20 तक सीमित किया जाए. अगर आप Google Workspace एडमिन हैं, तो आपके पास एडमिन के तौर पर अधिकार वाले अतिरिक्त उपयोगकर्ता बनाने का विकल्प है. साथ ही, उनका इस्तेमाल करके, कुछ क्लाइंट को अनुमति दी जा सकती है.

Google Cloud Platform (GCP) संगठनों के लिए सेशन कंट्रोल नीतियों का सामना करना

GCP संगठनों के एडमिन, Google Cloud सेशन कंट्रोल सुविधा का इस्तेमाल करके, उपयोगकर्ताओं के लिए बार-बार फिर से पुष्टि करने की कोशिश कर सकते हैं. इस नीति का असर Google Cloud Console, Google Cloud SDK (इसे gcloud सीएलआई भी कहा जाता है) और तीसरे पक्ष के ऐसे OAuth ऐप्लिकेशन के ऐक्सेस पर पड़ता है जिनके लिए Cloud Platform के दायरे की ज़रूरत होती है. अगर उपयोगकर्ता के पास सेशन कंट्रोल की नीति है और सेशन की अवधि खत्म होने पर, रीफ़्रेश किए गए टोकन के रद्द होने पर आपके एपीआई कॉल में कोई गड़बड़ी होगी, तो वह गलत तरीके से काम करेगा. सेशन की कंट्रोल नीति की वजह से रद्द किए गए टोकन और असफलता के बीच अंतर करने के लिए, error_subtype फ़ील्ड का इस्तेमाल किया जा सकता है.invalid_grant"error_subtype": "invalid_rapt"

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

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

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

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