Google अश्वेत समुदायों के लिए नस्लीय इक्विटी को आगे बढ़ाने के लिए प्रतिबद्ध है। देखो कैसे।
इस पेज का अनुवाद Cloud Translation API से किया गया है.
Switch to English

Google API तक पहुंचने के लिए OAuth 2.0 का उपयोग करना

Google API प्रमाणीकरण और प्राधिकरण के लिए OAuth 2.0 प्रोटोकॉल का उपयोग करते हैं। Google सामान्य OAuth 2.0 परिदृश्यों का समर्थन करता है जैसे कि वेब सर्वर, क्लाइंट-साइड, इंस्टॉल और सीमित-इनपुट डिवाइस अनुप्रयोगों के लिए।

शुरू करने के लिए, Oauth 2.0 क्लाइंट क्रेडेंशियल्स को Google API Console से प्राप्त करें। तब आपका क्लाइंट एप्लिकेशन Google प्राधिकरण सर्वर से एक्सेस टोकन का अनुरोध करता है, प्रतिक्रिया से एक टोकन निकालता है, और उस टोकन को Google API को भेजता है जिसे आप एक्सेस करना चाहते हैं। Google के साथ OAuth 2.0 का उपयोग करने के एक इंटरैक्टिव प्रदर्शन के लिए (अपने क्लाइंट क्रेडेंशियल्स का उपयोग करने के विकल्प सहित), OAuth 2.0 प्लेग्राउंड के साथ प्रयोग करें।

यह पृष्ठ OAuth 2.0 प्राधिकरण परिदृश्यों का अवलोकन देता है जो Google समर्थन करता है, और अधिक विस्तृत सामग्री के लिंक प्रदान करता है। प्रमाणीकरण के लिए OAuth 2.0 का उपयोग करने के बारे में विवरण के लिए, OpenID कनेक्ट देखें।

बुनियादी कदम

OAuth 2.0 का उपयोग करके Google API एक्सेस करते समय सभी एप्लिकेशन एक मूल पैटर्न का पालन करते हैं। उच्च स्तर पर, आप पाँच चरणों का पालन करते हैं:

1. Google API Console से OAuth 2.0 क्रेडेंशियल्स प्राप्त करें।

OAuth 2.0 क्रेडेंशियल्स जैसे क्लाइंट आईडी और क्लाइंट रहस्य प्राप्त करने के लिए Google API Console पर जाएं, जो Google और आपके एप्लिकेशन दोनों के लिए जाने जाते हैं। मूल्यों का सेट किस प्रकार के अनुप्रयोग के आधार पर भिन्न होता है। उदाहरण के लिए, जावास्क्रिप्ट एप्लिकेशन को एक गुप्त की आवश्यकता नहीं होती है, लेकिन एक वेब सर्वर एप्लिकेशन करता है।

2. Google प्राधिकरण सर्वर से पहुंच टोकन प्राप्त करें।

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

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

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

यदि उपयोगकर्ता कम से कम एक अनुमति देता है, तो Google प्राधिकरण सर्वर आपके एप्लिकेशन को एक एक्सेस टोकन (या एक प्राधिकरण कोड जो आपके एप्लिकेशन को एक्सेस टोकन प्राप्त करने के लिए उपयोग कर सकता है) और उस टोकन द्वारा दी गई एक्सेस के स्कोप की सूची भेजता है। यदि उपयोगकर्ता अनुमति नहीं देता है, तो सर्वर एक त्रुटि देता है।

आमतौर पर यह एक सर्वोत्तम अभ्यास है कि समय के साथ-साथ सामने वाले की आवश्यकता होती है। उदाहरण के लिए, एक ऐप जो कैलेंडर में किसी ईवेंट को सहेजने का समर्थन करना चाहता है, उसे Google कैलेंडर एक्सेस का अनुरोध नहीं करना चाहिए जब तक कि उपयोगकर्ता "कैलेंडर में जोड़ें" बटन दबाए नहीं; वृद्धिशील प्राधिकरण देखें।

3. उपयोगकर्ता द्वारा दी गई पहुंच के जांच के दायरे।

संबंधित Google API के उपयोग पर निर्भर सुविधाओं और आपके एप्लिकेशन की कार्यक्षमता तक पहुंचने के लिए आवश्यक स्कोप की पहुँच प्रतिक्रिया में शामिल स्कोप की तुलना करें। संबंधित API तक पहुंच के बिना आपके एप्लिकेशन की किसी भी सुविधा को अक्षम करने में असमर्थ।

आपके अनुरोध में शामिल स्कोप आपकी प्रतिक्रिया में शामिल स्कोप से मेल नहीं खा सकता है, भले ही उपयोगकर्ता ने सभी अनुरोधित स्कोप दिए हों। एक्सेस के लिए आवश्यक स्कोप के लिए प्रत्येक Google API के लिए प्रलेखन देखें। एपीआई एक एकल स्कोप एक्सेस के कई स्कोप स्ट्रिंग मानों को मैप कर सकता है, रिक्वेस्ट में दिए गए सभी मानों के लिए समान स्कोप स्ट्रिंग लौटाता है। उदाहरण: Google लोग API https://www.googleapis.com/auth/contacts दायरे में लौट सकते हैं जब कोई ऐप किसी उपयोगकर्ता द्वारा https://www.google.com/m8/feeds/ दायरे को अधिकृत करने का अनुरोध करता है; Google लोग API विधि people.updateContact लिए https://www.googleapis.com/auth/contacts स्वीकृत दायरे की आवश्यकता है।

4. एक एपीआई के लिए पहुँच टोकन भेजें।

किसी एप्लिकेशन को एक्सेस टोकन प्राप्त होने के बाद, यह HTTP ऑथराइजेशन रिक्वेस्ट हेडर में Google API को टोकन भेजता है। URI क्वेरी-स्ट्रिंग मापदंडों के रूप में टोकन भेजना संभव है, लेकिन हम इसकी अनुशंसा नहीं करते हैं, क्योंकि URI पैरामीटर लॉग फ़ाइलों में समाप्त हो सकते हैं जो पूरी तरह से सुरक्षित नहीं हैं। इसके अलावा, अनावश्यक URI पैरामीटर नाम बनाने से बचने के लिए यह अच्छा REST अभ्यास है। ध्यान दें कि क्वेरी-स्ट्रिंग समर्थन को 1 जून, 2021 को पदावनत किया जाएगा।

टोकन अनुरोध के scope में वर्णित संचालन और संसाधनों के सेट के लिए एक्सेस टोकन केवल मान्य हैं। उदाहरण के लिए, यदि Google कैलेंडर API के लिए एक्सेस टोकन जारी किया जाता है, तो वह Google संपर्क API तक पहुंच प्रदान नहीं करता है। हालाँकि, आप उसी ऑपरेशन के लिए कई बार Google कैलेंडर API तक उस एक्सेस टोकन को भेज सकते हैं।

5. यदि आवश्यक हो, तो एक्सेस टोकन को रिफ्रेश करें।

पहुंच टोकन सीमित जीवनकाल है। यदि आपके एप्लिकेशन को एकल एक्सेस टोकन के जीवनकाल से परे Google API तक पहुंच की आवश्यकता है, तो यह एक ताज़ा टोकन प्राप्त कर सकता है। एक ताज़ा टोकन आपके एप्लिकेशन को नए एक्सेस टोकन प्राप्त करने की अनुमति देता है।

परिदृश्यों

वेब सर्वर अनुप्रयोग

Google OAuth 2.0 समापन बिंदु वेब सर्वर अनुप्रयोगों का समर्थन करता है जो भाषा और चौखटे जैसे PHP, जावा, पायथन, रूबी और ASP.NET का उपयोग करते हैं।

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

एप्लिकेशन को भविष्य के उपयोग के लिए ताज़ा टोकन संग्रहीत करना चाहिए और Google API तक पहुंचने के लिए एक्सेस टोकन का उपयोग करना चाहिए। एक बार जब टोकन समाप्त हो जाता है, तो एप्लिकेशन एक नया प्राप्त करने के लिए ताज़ा टोकन का उपयोग करता है।

आपका एप्लिकेशन Google प्राधिकरण सर्वर को एक टोकन अनुरोध भेजता है, एक प्राधिकरण कोड प्राप्त करता है, एक टोकन के लिए कोड का आदान-प्रदान करता है, और Google API समापन बिंदु को कॉल करने के लिए टोकन का उपयोग करता है।

विवरण के लिए, वेब सर्वर एप्लिकेशन के लिए OAuth 2.0 का उपयोग करना देखें।

स्थापित अनुप्रयोगों

Google OAuth 2.0 समापन बिंदु उन अनुप्रयोगों का समर्थन करता है जो कंप्यूटर, मोबाइल डिवाइस और टैबलेट जैसे उपकरणों पर इंस्टॉल किए जाते हैं। जब आप Google API Console के माध्यम से क्लाइंट आईडी बनाते हैं , तो निर्दिष्ट करें कि यह एक इंस्टॉल किया गया एप्लिकेशन है, फिर एप्लिकेशन प्रकार के रूप में एंड्रॉइड, क्रोम ऐप, आईओएस, यूनिवर्सल विंडोज प्लेटफॉर्म (यूडब्ल्यूपी), या डेस्कटॉप ऐप चुनें।

इस प्रक्रिया के परिणामस्वरूप क्लाइंट ID और कुछ मामलों में, एक क्लाइंट सीक्रेट होता है, जिसे आप अपने एप्लिकेशन के स्रोत कोड में एम्बेड करते हैं। (इस संदर्भ में, ग्राहक रहस्य को स्पष्ट रूप से गुप्त नहीं माना जाता है।)

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

एप्लिकेशन को भविष्य के उपयोग के लिए ताज़ा टोकन स्टोर करना चाहिए और Google API तक पहुंचने के लिए एक्सेस टोकन का उपयोग करना चाहिए। एक बार जब टोकन समाप्त हो जाता है, तो एप्लिकेशन एक नया प्राप्त करने के लिए ताज़ा टोकन का उपयोग करता है।

आपका एप्लिकेशन Google प्राधिकरण सर्वर को एक टोकन अनुरोध भेजता है, एक प्राधिकरण कोड प्राप्त करता है, एक टोकन के लिए कोड का आदान-प्रदान करता है, और Google API समापन बिंदु को कॉल करने के लिए टोकन का उपयोग करता है।

विवरण के लिए, स्थापित अनुप्रयोगों के लिए OAuth 2.0 का उपयोग करना देखें।

क्लाइंट-साइड (जावास्क्रिप्ट) अनुप्रयोग

Google OAuth 2.0 समापन बिंदु एक ब्राउज़र में चलने वाले जावास्क्रिप्ट अनुप्रयोगों का समर्थन करता है।

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

परिणाम एक पहुंच टोकन है, जिसे ग्राहक को Google API अनुरोध में शामिल करने से पहले मान्य करना चाहिए। जब टोकन समाप्त हो जाता है, तो एप्लिकेशन प्रक्रिया को दोहराता है।

आपका JS एप्लिकेशन Google प्राधिकरण सर्वर को टोकन अनुरोध भेजता है, टोकन प्राप्त करता है, टोकन को मान्य करता है, और Google API समापन बिंदु को कॉल करने के लिए टोकन का उपयोग करता है।

विवरण के लिए, क्लाइंट-साइड एप्लिकेशन के लिए OAuth 2.0 का उपयोग करना देखें।

सीमित-इनपुट उपकरणों पर अनुप्रयोग

Google OAuth 2.0 समापन बिंदु उन अनुप्रयोगों का समर्थन करता है जो गेम-कंसोल, वीडियो कैमरा और प्रिंटर जैसे सीमित-इनपुट डिवाइस पर चलते हैं।

प्राधिकरण अनुक्रम Google के URL से एक प्राधिकरण कोड के लिए एक वेब सेवा अनुरोध करने वाले एप्लिकेशन से शुरू होता है। प्रतिक्रिया में कई पैरामीटर शामिल हैं, जिसमें एक URL और एक कोड है जो एप्लिकेशन उपयोगकर्ता को दिखाता है।

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

इस बीच, एप्लिकेशन एक निर्दिष्ट अंतराल पर Google URL का सर्वेक्षण करता है। उपयोगकर्ता द्वारा पहुंच को मंजूरी देने के बाद, Google सर्वर की प्रतिक्रिया में एक पहुंच टोकन और ताज़ा टोकन होता है। एप्लिकेशन को भविष्य के उपयोग के लिए ताज़ा टोकन स्टोर करना चाहिए और Google API तक पहुंचने के लिए एक्सेस टोकन का उपयोग करना चाहिए। एक बार जब टोकन समाप्त हो जाता है, तो एप्लिकेशन एक नया प्राप्त करने के लिए ताज़ा टोकन का उपयोग करता है।

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

विवरण के लिए, उपकरणों के लिए OAuth 2.0 का उपयोग करना देखें।

सेवा खाते

Google API जैसे कि प्रिडिक्शन API और Google क्लाउड स्टोरेज आपके एप्लिकेशन की ओर से उपयोगकर्ता की जानकारी प्राप्त किए बिना कार्य कर सकते हैं। इन स्थितियों में आपके एप्लिकेशन को API की अपनी पहचान साबित करने की आवश्यकता है, लेकिन कोई उपयोगकर्ता सहमति आवश्यक नहीं है। इसी तरह, उद्यम परिदृश्यों में, आपका आवेदन कुछ संसाधनों तक प्रत्यायोजित पहुंच का अनुरोध कर सकता है।

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

एक सेवा खाते की क्रेडेंशियल्स, जो आप Google API Console से प्राप्त करते हैं, में एक उत्पन्न ईमेल पता शामिल होता है जो अद्वितीय, एक क्लाइंट आईडी और कम से कम एक सार्वजनिक / निजी कुंजी जोड़ी है। आप हस्ताक्षरित JWT बनाने के लिए क्लाइंट आईडी और एक निजी कुंजी का उपयोग करते हैं और उचित प्रारूप में एक्सेस-टोकन अनुरोध का निर्माण करते हैं। आपका एप्लिकेशन तब Google OAuth 2.0 प्राधिकरण सर्वर को टोकन अनुरोध भेजता है, जो एक्सेस टोकन लौटाता है। एप्लिकेशन Google टोकन तक पहुंचने के लिए टोकन का उपयोग करता है। जब टोकन समाप्त हो जाता है, तो एप्लिकेशन प्रक्रिया को दोहराता है।

आपका सर्वर एप्लिकेशन Google प्राधिकरण सर्वर से टोकन का अनुरोध करने के लिए एक JWT का उपयोग करता है, फिर Google API समापन बिंदु को कॉल करने के लिए टोकन का उपयोग करता है। कोई अंत-उपयोगकर्ता शामिल नहीं है।

विवरण के लिए, सेवा-खाता प्रलेखन देखें

टोकन का आकार

टोकन आकार में भिन्न हो सकते हैं, निम्नलिखित सीमा तक:

  • प्राधिकरण कोड: 256 बाइट्स
  • पहुंच टोकन: 2048 बाइट्स
  • टोकन ताज़ा करें: 512 बाइट्स

Google क्लाउड के सिक्योरिटी टोकन सर्विस एपीआई द्वारा लौटाए गए टोकन Google API OAuth 2.0 एक्सेस टोकन की तरह ही संरचित हैं, लेकिन अलग-अलग टोकन साइज सीमाएँ हैं। विवरण के लिए, एपीआई प्रलेखन देखें।

Google इन सीमाओं के भीतर टोकन आकार बदलने का अधिकार सुरक्षित रखता है, और आपके आवेदन को तदनुसार चर टोकन आकार का समर्थन करना चाहिए।

टोकन समाप्ति को ताज़ा करें

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

  • उपयोगकर्ता ने आपके ऐप की पहुंच रद्द कर दी है
  • छह महीने से रिफ्रेश टोकन का उपयोग नहीं किया गया है।
  • उपयोगकर्ता ने पासवर्ड बदल दिए और ताज़ा टोकन में जीमेल स्कोप हैं।
  • उपयोगकर्ता खाते ने अधिकतम (लाइव) ताज़ा टोकन की संख्या को पार कर लिया है।
  • उपयोगकर्ता Google क्लाउड प्लेटफ़ॉर्म संगठन से संबंधित है जिसमें सत्र नियंत्रण नीतियां प्रभावी हैं।

बाहरी उपयोगकर्ता प्रकार और "परीक्षण" की एक प्रकाशन स्थिति के लिए कॉन्फ़िगर की गई OAuth सहमति स्क्रीन के साथ Google क्लाउड प्लेटफ़ॉर्म परियोजना को 7 दिनों में ताज़ा टोकन जारी किया जाता है।

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

उपयोगकर्ता खाते में ताज़ा टोकन की कुल संख्या पर एक बड़ी सीमा है या सेवा खाता सभी ग्राहकों के पास हो सकता है। अधिकांश सामान्य उपयोगकर्ता इस सीमा को पार नहीं करेंगे, लेकिन कार्यान्वयन को परखने के लिए उपयोग किए जाने वाले डेवलपर के खाते का उपयोग हो सकता है।

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

Google क्लाउड प्लेटफ़ॉर्म (GCP) संगठनों के लिए सत्र नियंत्रण नीतियों से निपटना

GCP संगठनों के व्यवस्थापकों को Google क्लाउड सत्र नियंत्रण सुविधा का उपयोग करते हुए, GCP संसाधनों का उपयोग करते समय उपयोगकर्ताओं के लगातार सौंदर्यीकरण की आवश्यकता हो सकती है यह नीति Google क्लाउड कंसोल, Google क्लाउड SDK (जिसे gcloud CLI के रूप में भी जाना जाता है) और क्लाउड प्लेटफ़ॉर्म स्कोप की आवश्यकता वाले किसी भी तृतीय पक्ष OAuth अनुप्रयोग तक पहुँच को प्रभावित करती है। यदि किसी उपयोगकर्ता के पास सत्र नियंत्रण नीति है, तो सत्र अवधि की समाप्ति पर, आपकी एपीआई कॉल उसी तरह की त्रुटि करेगी, जैसे कि ताज़ा टोकन निरस्त हो जाने पर क्या होगा। चूंकि सत्र की अवधि बहुत सीमित हो सकती है (1 घंटे से 24 घंटे के बीच), इस परिदृश्य को किसी सत्र को फिर से शुरू करके इनायत से संभाला जाना चाहिए।

समान रूप से, आपको सर्वर पर सर्वर परिनियोजन के लिए उपयोगकर्ता क्रेडेंशियल्स के उपयोग, या उपयोग को प्रोत्साहित नहीं करना चाहिए। यदि उपयोगकर्ता क्रेडेंशियल्स को लंबे समय तक चलने वाली नौकरियों या संचालन के लिए एक सर्वर पर तैनात किया जाता है और एक ग्राहक ऐसे उपयोगकर्ताओं पर सत्र नियंत्रण नीतियों को लागू करता है, तो सर्वर एप्लिकेशन विफल हो जाएगा क्योंकि सत्र की अवधि समाप्त होने पर उपयोगकर्ता को फिर से प्रमाणित करने का कोई तरीका नहीं होगा।

इस सुविधा को लागू करने में अपने ग्राहकों की मदद करने के बारे में अधिक जानकारी के लिए, इस व्यवस्थापक-फोकस्ड सहायता आलेख को देखें।

ग्राहक पुस्तकालय

निम्न क्लाइंट लाइब्रेरी लोकप्रिय फ्रेमवर्क के साथ एकीकृत होती हैं, जो OAuth 2.0 को लागू करने को सरल बनाता है। समय के साथ पुस्तकालयों में और अधिक सुविधाएँ जोड़ी जाएंगी।