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 प्लेग्राउंड का इस्तेमाल करके देखें.

इस पेज पर, 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/ के दायरे को अनुमति देने का अनुरोध करता है, तो Google के लोगों का एपीआई https://www.googleapis.com/auth/contacts का दायरा दिखा सकता है; Google के लोगों के लिए एपीआई तरीके people.updateContact को https://www.googleapis.com/auth/contacts के दायरे की ज़रूरत होती है.

4. एपीआई को ऐक्सेस टोकन भेजें.

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

ऐक्सेस टोकन सिर्फ़ उन कार्रवाइयों और संसाधनों के सेट के लिए मान्य होते हैं जिनके बारे में 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 API एंडपॉइंट को कॉल करने के लिए, टोकन का इस्तेमाल करता है.

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

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

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

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

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

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

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

ज़्यादा जानकारी के लिए, इंस्टॉल किए गए ऐप्लिकेशन के लिए 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, जैसे कि एपीआई का अनुमान और Google Cloud Storage आपके ऐप्लिकेशन की ओर से, उपयोगकर्ता की जानकारी ऐक्सेस किए बिना काम कर सकते हैं. इन स्थितियों में आपके ऐप्लिकेशन को एपीआई के लिए अपनी पहचान की पुष्टि करनी होती है. हालांकि, इसके लिए उपयोगकर्ता की सहमति की ज़रूरत नहीं होती. इसी तरह, एंटरप्राइज़ स्थितियों में, आपका ऐप्लिकेशन कुछ संसाधनों के ऐक्सेस का अनुरोध कर सकता है.

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

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

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

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

टोकन का साइज़

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

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

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

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

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

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

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

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

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

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

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