इस दस्तावेज़ में बताया गया है कि फ़ोन, टैबलेट, और कंप्यूटर जैसे डिवाइसों पर इंस्टॉल किए गए ऐप्लिकेशन, YouTube Data API को ऐक्सेस करने की अनुमति देने के लिए, Google के OAuth 2.0 एंडपॉइंट का इस्तेमाल कैसे करते हैं.
OAuth 2.0 की मदद से, उपयोगकर्ता किसी ऐप्लिकेशन के साथ खास डेटा शेयर कर सकते हैं. हालांकि, इस दौरान उनके उपयोगकर्ता नाम, पासवर्ड, और अन्य जानकारी को निजी रखा जाता है. उदाहरण के लिए, किसी चैनल का YouTube डेटा वापस पाने की अनुमति पाने के लिए, ऐप्लिकेशन OAuth 2.0 का इस्तेमाल कर सकता है.
इंस्टॉल किए गए ऐप्लिकेशन, अलग-अलग डिवाइसों पर उपलब्ध कराए जाते हैं. इसलिए, यह माना जाता है कि ये ऐप्लिकेशन, गोपनीय नहीं रख सकते. उपयोगकर्ता के ऐप्लिकेशन में मौजूद रहने या बैकग्राउंड में चलने के दौरान, वे Google API को ऐक्सेस कर सकते हैं.
अनुमति देने का यह फ़्लो, वेब सर्वर ऐप्लिकेशन के लिए इस्तेमाल किए जाने वाले फ़्लो के जैसा ही है. मुख्य अंतर यह है कि इंस्टॉल किए गए ऐप्लिकेशन को सिस्टम ब्राउज़र खोलना होगा और Google के ऑथराइज़ेशन सर्वर से मिलने वाले रिस्पॉन्स को मैनेज करने के लिए, एक लोकल रीडायरेक्ट यूआरआई उपलब्ध कराना होगा.
विकल्प
मोबाइल ऐप्लिकेशन के लिए, हो सकता है कि आप Android या iOS के लिए 'Google साइन इन' का इस्तेमाल करना चाहें. 'Google साइन-इन' की क्लाइंट लाइब्रेरी पुष्टि करने और उपयोगकर्ता की अनुमति को मैनेज करती है. इन्हें लागू करना, यहां बताए गए निचले लेवल के प्रोटोकॉल से आसान हो सकता है.
जिन डिवाइसों पर सिस्टम ब्राउज़र काम नहीं करता या जिनमें सीमित इनपुट सुविधाएं (जैसे, टीवी, गेम कंसोल, कैमरा या प्रिंटर) उपलब्ध हैं उन पर चल रहे ऐप्लिकेशन के लिए, टीवी और डिवाइसों के लिए OAuth 2.0 या टीवी और सीमित इनपुट डिवाइसों पर साइन इन करने की सुविधा देखें.
लाइब्रेरी और सैंपल
हमारा सुझाव है कि इस दस्तावेज़ में बताए गए OAuth 2.0 फ़्लो को लागू करने में आपकी मदद करने के लिए, आप यहां दी गई लाइब्रेरी और सैंपल का इस्तेमाल करें:
- Android के लिए AppAuth लाइब्रेरी
- iOS के लिए AppAuth लाइब्रेरी
- ऐप्लिकेशन के लिए OAuth: Windows सैंपल
ज़रूरी शर्तें
अपने प्रोजेक्ट के लिए एपीआई चालू करना
Google API को कॉल करने वाले किसी भी ऐप्लिकेशन को, API Consoleमें उन एपीआई को चालू करना होगा.
अपने प्रोजेक्ट के लिए एपीआई चालू करने के लिए:
- Google API Consoleमें Open the API Library .
- If prompted, select a project, or create a new one.
- YouTube Data API को ढूंढने और चालू करने के लिए, लाइब्रेरी पेज का इस्तेमाल करें. ऐसे कोई दूसरे एपीआई ढूंढें जिनका इस्तेमाल आपका ऐप्लिकेशन करेगा और उन्हें भी चालू करें.
अनुमति देने वाले क्रेडेंशियल बनाएं
Google API को ऐक्सेस करने के लिए OAuth 2.0 का इस्तेमाल करने वाले किसी भी ऐप्लिकेशन में, ऐसे ऑथराइज़ेशन क्रेडेंशियल होने चाहिए जिनसे Google के OAuth 2.0 सर्वर पर ऐप्लिकेशन की पहचान की जा सके. अपने प्रोजेक्ट के लिए क्रेडेंशियल बनाने का तरीका यहां बताया गया है. इसके बाद, आपके ऐप्लिकेशन उन एपीआई को ऐक्सेस करने के लिए क्रेडेंशियल का इस्तेमाल कर सकते हैं जिन्हें आपने उस प्रोजेक्ट के लिए चालू किया है.
- Go to the Credentials page.
- क्रेडेंशियल बनाएं > OAuth क्लाइंट आईडी पर क्लिक करें.
- यहां दिए गए सेक्शन में, क्लाइंट टाइप और रीडायरेक्ट करने के उन तरीकों के बारे में बताया गया है जो Google के ऑथराइज़ेशन सर्वर पर काम करने वाले होते हैं. अपने ऐप्लिकेशन के लिए सुझाया गया क्लाइंट टाइप चुनें, अपने OAuth क्लाइंट को नाम दें, और फ़ॉर्म में ज़रूरत के मुताबिक अन्य फ़ील्ड सेट करें.
Android
- Android ऐप्लिकेशन का टाइप चुनें.
- OAuth क्लाइंट के लिए कोई नाम डालें. क्लाइंट की पहचान करने के लिए, यह नाम आपके प्रोजेक्ट के Credentials page पेज पर दिखाया जाता है.
- अपने Android ऐप्लिकेशन के पैकेज का नाम डालें. यह वैल्यू, आपकी ऐप्लिकेशन मेनिफ़ेस्ट फ़ाइल में
<manifest>
एलिमेंट केpackage
एट्रिब्यूट में तय की गई है. - ऐप्लिकेशन डिस्ट्रिब्यूशन का SHA-1 साइनिंग सर्टिफ़िकेट फ़िंगरप्रिंट डालें.
- अगर आपके ऐप्लिकेशन में Google Play की ऐप्लिकेशन साइनिंग का इस्तेमाल किया जाता है, तो Play Console के ऐप्लिकेशन साइनिंग पेज से SHA-1 फ़िंगरप्रिंट कॉपी करें.
- अगर आपको अपने कीस्टोर और साइनिंग पासकोड खुद मैनेज करने हैं, तो Java के साथ मिलने वाली keytool सुविधा का इस्तेमाल करें. इससे सर्टिफ़िकेट की जानकारी को ऐसे फ़ॉर्मैट में प्रिंट किया जा सकता है जिसे कोई भी व्यक्ति आसानी से पढ़ सके. keytool आउटपुट के
Certificate fingerprints
सेक्शन में मौजूदSHA1
वैल्यू कॉपी करें. ज़्यादा जानकारी के लिए, Android के लिए Google API के दस्तावेज़ में अपने क्लाइंट की पुष्टि करना देखें.
- (वैकल्पिक) अपने Android ऐप्लिकेशन के मालिकाना हक की पुष्टि करें.
- बनाएं पर क्लिक करें.
iOS
- iOS ऐप्लिकेशन टाइप चुनें.
- OAuth क्लाइंट के लिए कोई नाम डालें. क्लाइंट की पहचान करने के लिए, यह नाम आपके प्रोजेक्ट के Credentials page पेज पर दिखाया जाता है.
- अपने ऐप्लिकेशन के लिए बंडल आइडेंटिफ़ायर डालें. बंडल आईडी, आपके ऐप्लिकेशन की जानकारी वाली प्रॉपर्टी की सूची की रिसॉर्स फ़ाइल (info.plist) में मौजूद CFBundleIdentifier कुंजी की वैल्यू होता है. यह वैल्यू आम तौर पर, Xcode प्रोजेक्ट एडिटर के सामान्य पैनल या 'हस्ताक्षर और क्षमता' पैनल में दिखती है. बंडल आईडी, Apple की App Store Connect साइट पर ऐप्लिकेशन के लिए, ऐप्लिकेशन की जानकारी वाले पेज के सामान्य जानकारी वाले सेक्शन में भी दिखता है.
- (ज़रूरी नहीं)
अगर आपका ऐप्लिकेशन Apple के App Store में पब्लिश हुआ है, तो उसका App Store आईडी डालें. स्टोर आईडी, संख्या वाली ऐसी स्ट्रिंग होती है जो Apple App Store के हर यूआरएल में शामिल होती है.
- अपने iOS या iPadOS डिवाइस पर Apple App Store ऐप्लिकेशन खोलें.
- अपना ऐप्लिकेशन खोजें.
- शेयर बटन (वर्ग और तीर ऊपर प्रतीक) का चयन करें.
- लिंक कॉपी करें चुनें.
- लिंक को टेक्स्ट एडिटर में चिपकाएं. ऐप स्टोर आईडी, यूआरएल का आखिरी हिस्सा होता है.
उदाहरण:
https://apps.apple.com/app/google/id284815942
- (ज़रूरी नहीं)
अपना टीम आईडी डालें. ज़्यादा जानकारी के लिए, Apple डेवलपर खाते के दस्तावेज़ में अपने टीम आईडी का पता लगाना देखें.
- बनाएं पर क्लिक करें.
यूडब्ल्यूपी
- Universal Windows Platform ऐप्लिकेशन टाइप चुनें.
- OAuth क्लाइंट के लिए कोई नाम डालें. क्लाइंट की पहचान करने के लिए, यह नाम आपके प्रोजेक्ट के Credentials page पेज पर दिखाया जाता है.
- अपने ऐप्लिकेशन का 12 वर्णों का Microsoft Store आईडी डालें. यह वैल्यू, Microsoft Partner Center में, ऐप्लिकेशन मैनेजमेंट सेक्शन में ऐप्लिकेशन आइडेंटिटी पेज पर देखी जा सकती है.
- बनाएं पर क्लिक करें.
यूडब्ल्यूपी ऐप्लिकेशन के लिए, कस्टम यूआरआई स्कीम 39 वर्णों से ज़्यादा लंबी नहीं हो सकती.
कस्टम यूआरआई स्कीम (Android, iOS, UWP)
कस्टम यूआरआई स्कीम, डीपलिंक करने का एक तरीका है. इसमें आपके ऐप्लिकेशन को खोलने के लिए, कस्टम-तय की गई स्कीम का इस्तेमाल किया जाता है.
Android पर कस्टम यूआरआई स्कीम का इस्तेमाल करने के विकल्पAndroid SDK के लिए 'Google साइन इन' का इस्तेमाल करें. यह आपके ऐप्लिकेशन को सीधे OAuth 2.0 रिस्पॉन्स देता है. इससे रीडायरेक्ट यूआरआई की ज़रूरत नहीं पड़ती.
Android SDK टूल के लिए 'Google साइन-इन' पर माइग्रेट करने का तरीका
अगर Android पर OAuth इंटिग्रेशन के लिए, फ़िलहाल किसी कस्टम स्कीम का इस्तेमाल किया जा रहा है, तो आपको 'Android के लिए Google साइन-इन' के सुझाए गए SDK टूल पर पूरी तरह से माइग्रेट करने के लिए, नीचे दी गई कार्रवाइयां पूरी करनी होंगी:
- 'Google साइन-इन' SDK टूल का इस्तेमाल करने के लिए, अपना कोड अपडेट करें.
- Google API कंसोल में कस्टम स्कीम के लिए सहायता बंद करें.
'Google साइन-इन Android SDK' पर माइग्रेट करने के लिए, यह तरीका अपनाएं:
-
'Google साइन-इन' Android SDK का इस्तेमाल करने के लिए, अपना कोड अपडेट करें:
-
अपने कोड की जांच करके पता लगाएं कि Google के OAuth 2.0 सर्वर पर अनुरोध कहां भेजा जा रहा है. अगर कस्टम स्कीम का इस्तेमाल किया जा रहा है, तो आपका अनुरोध यहां दिखेगा:
https://accounts.google.com/o/oauth2/v2/auth? scope=<SCOPES>& response_type=code& &state=<STATE>& redirect_uri=com.example.app:/oauth2redirect& client_id=<CLIENT_ID>
com.example.app:/oauth2redirect
, ऊपर दिए गए उदाहरण में कस्टम स्कीम रीडायरेक्ट यूआरआई है. कस्टम यूआरआई स्कीम की वैल्यू के फ़ॉर्मैट के बारे में ज़्यादा जानने के लिए,redirect_uri
पैरामीटर की परिभाषा देखें. -
scope
औरclient_id
अनुरोध पैरामीटर को ध्यान में रखें. आपको 'Google साइन-इन' SDK टूल को कॉन्फ़िगर करने की ज़रूरत होगी. -
SDK टूल सेट अप करने के लिए,
अपने Android ऐप्लिकेशन में 'Google साइन इन' को इंटिग्रेट करना शुरू करें
के निर्देशों का पालन करें. अपने बैकएंड सर्वर का OAuth 2.0 क्लाइंट आईडी पाने के चरण को छोड़ा जा सकता है. ऐसा इसलिए, क्योंकि आपको पिछले चरण से मिले
client_id
का फिर से इस्तेमाल करना होगा. -
सर्वर-साइड एपीआई का ऐक्सेस चालू करने से जुड़े निर्देशों का पालन करें. इसके लिए, यह तरीका अपनाएं:
-
जिन दायरों के लिए अनुमति का अनुरोध किया जा रहा है उनसे जुड़ा ऑथराइज़ेशन कोड पाने के लिए,
getServerAuthCode
तरीके का इस्तेमाल करें. - अपने ऐप्लिकेशन के बैकएंड पर, ऑथराइज़ेशन कोड भेजें, ताकि ऐक्सेस और रीफ़्रेश टोकन मिल सके.
- उपयोगकर्ता की ओर से Google API को कॉल करने के लिए, वापस मिले ऐक्सेस टोकन का इस्तेमाल करें.
-
जिन दायरों के लिए अनुमति का अनुरोध किया जा रहा है उनसे जुड़ा ऑथराइज़ेशन कोड पाने के लिए,
-
अपने कोड की जांच करके पता लगाएं कि Google के OAuth 2.0 सर्वर पर अनुरोध कहां भेजा जा रहा है. अगर कस्टम स्कीम का इस्तेमाल किया जा रहा है, तो आपका अनुरोध यहां दिखेगा:
-
Google API Console में, कस्टम स्कीम के लिए सहायता बंद करें:
- अपनी OAuth 2.0 क्रेडेंशियल सूची पर जाएं और अपना Android क्लाइंट चुनें.
- बेहतर सेटिंग सेक्शन पर जाएं, कस्टम यूआरआई स्कीम चालू करें चेकबॉक्स से सही का निशान हटाएं और कस्टम यूआरआई स्कीम से जुड़ी सहायता बंद करने के लिए, सेव करें पर क्लिक करें.
कस्टम यूआरआई स्कीम चालू करना
अगर सुझाया गया विकल्प काम नहीं करता है, तो अपने Android क्लाइंट के लिए कस्टम यूआरआई स्कीम चालू करने के लिए, नीचे दिए गए निर्देशों का पालन करें:- अपनी OAuth 2.0 क्रेडेंशियल सूची पर जाएं और अपना Android क्लाइंट चुनें.
- बेहतर सेटिंग सेक्शन पर जाएं, कस्टम यूआरआई स्कीम चालू करें चेकबॉक्स पर सही का निशान लगाएं और कस्टम यूआरआई स्कीम से जुड़ी सहायता चालू करने के लिए, सेव करें पर क्लिक करें.
Chrome Identity API का इस्तेमाल करें, जो सीधे आपके ऐप्लिकेशन को OAuth 2.0 रिस्पॉन्स देता है. इससे रीडायरेक्ट यूआरआई की ज़रूरत नहीं पड़ती.
ऐप्लिकेशन के मालिकाना हक की पुष्टि करना (Android, Chrome)
ऐप्लिकेशन प्रतिरूपण के जोखिम को कम करने के लिए आप अपने ऐप्लिकेशन के स्वामित्व की पुष्टि कर सकते हैं.
Android
पुष्टि की प्रक्रिया पूरी करने के लिए, अगर आपके पास Google Play डेवलपर खाता है और आपका ऐप्लिकेशन Google Play Console पर रजिस्टर है, तो उसका इस्तेमाल किया जा सकता है. पुष्टि की प्रक्रिया को पूरा करने के लिए, आपको ये शर्तें पूरी करनी होंगी:
- आपके पास Google Play Console में रजिस्टर किया गया ऐसा ऐप्लिकेशन होना चाहिए जिसके पैकेज नाम और SHA-1 साइनिंग सर्टिफ़िकेट फ़िंगरप्रिंट का नाम, Android OAuth क्लाइंट के फ़िंगरप्रिंट से मेल खाता हो.
- आपके पास Google Play Console में ऐप्लिकेशन के लिए, एडमिन की अनुमति होनी चाहिए. Google Play Console में ऐक्सेस मैनेजमेंट के बारे में ज़्यादा जानें.
Android क्लाइंट के ऐप्लिकेशन के मालिकाना हक की पुष्टि करें सेक्शन में, पुष्टि की प्रक्रिया पूरी करने के लिए मालिकाना हक की पुष्टि करें बटन पर क्लिक करें.
पुष्टि की प्रक्रिया पूरी होने पर, इसकी पुष्टि के लिए एक सूचना दिखाई जाएगी. ऐसा न करने पर, गड़बड़ी का मैसेज दिखेगा.
पुष्टि न हो पाने की समस्या को ठीक करने के लिए, कृपया नीचे दिया गया तरीका अपनाएं:
- पक्का करें कि जिस ऐप्लिकेशन की पुष्टि की जा रही है वह Google Play Console पर रजिस्टर किया गया ऐप्लिकेशन है.
- पक्का करें कि आपके पास Google Play Console में ऐप्लिकेशन के लिए, एडमिन की अनुमति हो.
Chrome
पुष्टि की प्रक्रिया पूरी करने के लिए, आपको अपने Chrome वेब स्टोर डेवलपर खाते का इस्तेमाल करना होगा. पुष्टि की प्रक्रिया को पूरा करने के लिए, यहां दी गई शर्तें पूरी करना ज़रूरी है:
- आपके पास Chrome वेब स्टोर डेवलपर डैशबोर्ड पर रजिस्टर किया गया एक आइटम होना चाहिए, जिसका आइटम आईडी वही होना चाहिए जो Chrome एक्सटेंशन OAuth क्लाइंट के लिए आप पुष्टि कर रहे हैं.
- Chrome वेब स्टोर आइटम के लिए आपको प्रकाशक होना चाहिए. 'Chrome वेब स्टोर डेवलपर डैशबोर्ड' में ऐक्सेस मैनेजमेंट के बारे में ज़्यादा जानें.
Chrome एक्सटेंशन क्लाइंट के ऐप्लिकेशन के मालिकाना हक की पुष्टि करें सेक्शन में, पुष्टि की प्रक्रिया पूरी करने के लिए मालिकाना हक की पुष्टि करें बटन पर क्लिक करें.
ध्यान दें: कृपया अपने खाते का ऐक्सेस देने के बाद, पुष्टि की प्रक्रिया पूरी करने से पहले कुछ मिनट इंतज़ार करें.
पुष्टि की प्रक्रिया पूरी होने पर, इसकी पुष्टि के लिए एक सूचना दिखाई जाएगी. ऐसा न करने पर, गड़बड़ी का मैसेज दिखेगा.
पुष्टि न हो पाने की समस्या को ठीक करने के लिए, कृपया नीचे दिया गया तरीका अपनाएं:
- पक्का करें कि 'Chrome वेब स्टोर डेवलपर डैशबोर्ड' पर रजिस्टर किया गया एक आइटम आईडी मौजूद हो, जिसका आइटम आईडी वही हो जो Chrome एक्सटेंशन OAuth क्लाइंट के लिए आप पुष्टि कर रहे हैं.
- पक्का करें कि आप ऐप्लिकेशन के पब्लिशर हैं. इसका मतलब है कि आप ऐप्लिकेशन के निजी पब्लिशर हों या ग्रुप पब्लिशर के सदस्य हों. Chrome वेब स्टोर डेवलपर डैशबोर्ड में ऐक्सेस मैनेजमेंट के बारे में ज़्यादा जानें.
- अगर आपने अभी-अभी ग्रुप पब्लिशर की सूची अपडेट की है, तो पुष्टि करें कि ग्रुप पब्लिशर की सदस्यता सूची, 'Chrome वेब स्टोर' डेवलपर डैशबोर्ड में सिंक की गई हो. पब्लिशर की सदस्यता की सूची को सिंक करने के बारे में ज़्यादा जानें.
लूपबैक आईपी पता (macOS, Linux, Windows डेस्कटॉप)
इस यूआरएल का इस्तेमाल करके ऑथराइज़ेशन कोड पाने के लिए, ज़रूरी है कि आपका ऐप्लिकेशन लोकल वेब सर्वर पर दिख रहा हो. ऐसा कई प्लैटफ़ॉर्म पर मुमकिन है, लेकिन सभी पर नहीं. हालांकि, अगर आपका प्लैटफ़ॉर्म इस पर काम करता है, तो यह ऑथराइज़ेशन कोड पाने के लिए सुझाया गया तरीका है.
जब आपके ऐप्लिकेशन को अनुमति मिल जाती है, तो सबसे अच्छे तरीके से उसे इस्तेमाल करने के लिए, उसे एक एचटीएमएल पेज दिखाकर जवाब देना चाहिए. इस पेज में, उपयोगकर्ता को ब्राउज़र बंद करने और ऐप्लिकेशन पर वापस जाने के निर्देश दिए जाते हैं.
इस्तेमाल के लिए सुझाया गया तरीका | macOS, Linux, और Windows डेस्कटॉप (लेकिन Universal Windows Platform नहीं) ऐप्लिकेशन |
फ़ॉर्म की वैल्यू | ऐप्लिकेशन के टाइप को डेस्कटॉप ऐप्लिकेशन पर सेट करें. |
मैन्युअल तरीके से कॉपी करें/चिपकाएं
ऐक्सेस के दायरों की पहचान करना
स्कोप की सुविधा का इस्तेमाल करके आपका ऐप्लिकेशन, सिर्फ़ उन संसाधनों का ऐक्सेस मांग सकता है जिनकी उसे ज़रूरत है. साथ ही, उपयोगकर्ता आपके ऐप्लिकेशन को दिए गए ऐक्सेस की सीमा को कंट्रोल कर सकते हैं. इसलिए, अनुरोध किए गए दायरों की संख्या और उपयोगकर्ता की सहमति लेने की संभावना, अलग-अलग हो सकती है.
हमारा सुझाव है कि OAuth 2.0 की अनुमति देने की सुविधा लागू करने से पहले, आप उन दायरों का पता लगा लें जिन्हें ऐक्सेस करने के लिए आपके ऐप्लिकेशन को अनुमति की ज़रूरत होगी.
YouTube Data API v3 इन दायरों का इस्तेमाल करता है:
बंदूक पर लगने वाली दूरबीन | |
---|---|
https://www.googleapis.com/auth/youtube | अपना YouTube खाता मैनेज करें |
https://www.googleapis.com/auth/youtube.channel-memberships.creator | अपने चैनल के मौजूदा सक्रिय सदस्यों की सूची और उनका मौजूदा लेवल देखें. यह भी देखें कि वे चैनल के सदस्य कब बने |
https://www.googleapis.com/auth/youtube.force-ssl | अपने YouTube वीडियो की रेटिंग, टिप्पणियां और कैप्शन देखें, उनमें बदलाव करें और उन्हें हमेशा के लिए मिटाएं |
https://www.googleapis.com/auth/youtube.readonly | अपना YouTube खाता देखें |
https://www.googleapis.com/auth/youtube.upload | अपने YouTube वीडियो मैनेज करें |
https://www.googleapis.com/auth/youtubepartner | YouTube पर अपनी परिसंपत्ति तथा संबंधित सामग्री देखें व प्रबंधित करें |
https://www.googleapis.com/auth/youtubepartner-channel-audit | किसी YouTube भागीदार की ऑडिट प्रक्रिया के दौरान उससे प्रासंगिक अपने YouTube चैनल की निजी जानकारी देखें |
OAuth 2.0 एपीआई के दायरे दस्तावेज़ में, उन दायरों की पूरी सूची है जिनका इस्तेमाल Google API को ऐक्सेस करने के लिए किया जा सकता है.
OAuth 2.0 ऐक्सेस टोकन पाना
यहां दिए गए चरण में बताया गया है कि आपका ऐप्लिकेशन, Google के OAuth 2.0 सर्वर के साथ कैसे इंटरैक्ट करता है. इससे, उपयोगकर्ता की ओर से एपीआई अनुरोध करने के लिए, उपयोगकर्ता की सहमति ली जा सकती है. आपके ऐप्लिकेशन के पास यह सहमति होनी चाहिए. इसके बाद ही वह Google API के किसी ऐसे अनुरोध पर कार्रवाई कर सकता है जिसके लिए उपयोगकर्ता की अनुमति की ज़रूरत होती है.
पहला चरण: कोड की पुष्टि करने वाला प्रोग्राम और चैलेंज जनरेट करना
Google, कोड एक्सचेंज के लिए प्रूफ़ बटन (पीकेसीई) प्रोटोकॉल के साथ काम करता है, ताकि इंस्टॉल किए गए ऐप्लिकेशन फ़्लो को ज़्यादा सुरक्षित बनाया जा सके. पुष्टि करने के हर अनुरोध के लिए, एक यूनीक कोड की पुष्टि करने वाला प्रोग्राम बनाया जाता है. साथ ही, इसकी ट्रांसफ़ॉर्म की गई वैल्यू, जिसे "code_Challenge" कहा जाता है, ऑथराइज़ेशन सर्वर को भेजा जाता है, ताकि ऑथराइज़ेशन कोड हासिल किया जा सके.
कोड की पुष्टि करने वाला प्रोग्राम बनाएं
code_verifier
एक हाई-एंट्रॉपी क्रिप्टोग्राफ़िक रैंडम स्ट्रिंग है, जो रिज़र्व नहीं किए गए वर्णों [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" का इस्तेमाल करती है. इसमें कम से कम 43 वर्ण और ज़्यादा से ज़्यादा 128 वर्ण हो सकते हैं.
कोड की पुष्टि करने वाले डिवाइस में इतनी एंट्रॉपी होनी चाहिए कि उसमें वैल्यू का अनुमान न लगाया जा सके.
कोड चैलेंज बनाएं
कोड चैलेंज बनाने के दो तरीके इस्तेमाल किए जा सकते हैं.
कोड चैलेंज जनरेट करने के तरीके | |
---|---|
S256 (सुझाया गया) | कोड चैलेंज, कोड की पुष्टि करने वाले कोड के Base64URL (बिना पैडिंग के) SHA256 हैश है.
|
सादा | कोड चैलेंज और ऊपर जनरेट किए गए कोड की पुष्टि करने वाले कोड की वैल्यू, दोनों एक ही हैं.
|
दूसरा चरण: Google के OAuth 2.0 सर्वर पर अनुरोध भेजना
उपयोगकर्ता की अनुमति पाने के लिए, https://accounts.google.com/o/oauth2/v2/auth
पर Google के ऑथराइज़ेशन सर्वर को अनुरोध भेजें. यह एंडपॉइंट, ऐक्टिव सेशन लुकअप को मैनेज करता है,
उपयोगकर्ता की पुष्टि करता है, और उपयोगकर्ता की सहमति लेता है. एंडपॉइंट को सिर्फ़ एसएसएल से ऐक्सेस किया जा सकता है. साथ ही, यह एचटीटीपी (एसएसएल को छोड़कर) कनेक्शन को अस्वीकार कर देता है.
ऑथराइज़ेशन सर्वर, इंस्टॉल किए गए ऐप्लिकेशन के लिए इन क्वेरी स्ट्रिंग पैरामीटर के साथ काम करता है:
पैरामीटर | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
client_id |
ज़रूरी
आपके ऐप्लिकेशन का क्लाइंट आईडी. यह वैल्यू, आपको API Console Credentials pageमें मिलेगी. |
||||||||||||||||
redirect_uri |
ज़रूरी
यह तय करता है कि Google का ऑथराइज़ेशन सर्वर आपके ऐप्लिकेशन को रिस्पॉन्स कैसे भेजता है. इंस्टॉल किए गए ऐप्लिकेशन के लिए, रीडायरेक्ट करने के कई विकल्प उपलब्ध हैं. इसके लिए, आपको अपने ऑथराइज़ेशन क्रेडेंशियल को, रीडायरेक्ट करने के किसी खास तरीके को ध्यान में रखकर सेट अप करना होगा. वैल्यू, उस OAuth 2.0 क्लाइंट के लिए, आधिकारिक रीडायरेक्ट यूआरआई में से किसी एक से पूरी तरह मेल खानी चाहिए
जिसे आपने अपने क्लाइंट के
API Console
Credentials pageमें कॉन्फ़िगर किया है. अगर यह वैल्यू, अनुमति वाले यूआरआई से
मेल नहीं खाती है, तो आपको नीचे दी गई टेबल में, हर तरीके के लिए
|
||||||||||||||||
response_type |
ज़रूरी
इससे यह तय होता है कि Google OAuth 2.0 एंडपॉइंट, ऑथराइज़ेशन कोड दिखाता है या नहीं. इंस्टॉल किए गए ऐप्लिकेशन के लिए पैरामीटर मान को |
||||||||||||||||
scope |
ज़रूरी
दायरों की स्पेस-डीलिमिटेड सूची, जो उन संसाधनों की पहचान करती है जिन्हें आपका ऐप्लिकेशन, उपयोगकर्ता की ओर से ऐक्सेस कर सकता है. इन वैल्यू से उस स्क्रीन के बारे में पता चलता है जो Google, उपयोगकर्ता को दिखाता है. स्कोप की सुविधा का इस्तेमाल करके आपका ऐप्लिकेशन, सिर्फ़ उन संसाधनों का ऐक्सेस मांग सकता है जिनकी उसे ज़रूरत है. साथ ही, उपयोगकर्ता आपके ऐप्लिकेशन को दिए गए ऐक्सेस के लेवल को कंट्रोल कर सकते हैं. इसलिए, अनुरोध किए गए दायरों की संख्या और उपयोगकर्ता की सहमति पाने की संभावना, दोनों में बिलकुल उलट होता है. YouTube Data API v3 इन दायरों का इस्तेमाल करता है:
OAuth 2.0 एपीआई के दायरे दस्तावेज़ में, उन दायरों की पूरी सूची मिलती है जिनका इस्तेमाल Google API को ऐक्सेस करने के लिए किया जा सकता है. |
||||||||||||||||
code_challenge |
सुझाया गया
कोड में बदले गए ऐसे |
||||||||||||||||
code_challenge_method |
सुझाया गया
इससे पता चलता है कि |
||||||||||||||||
state |
सुझाया गया
ऐसी किसी भी स्ट्रिंग वैल्यू के बारे में बताता है जिसका इस्तेमाल आपका ऐप्लिकेशन, अनुमति देने के आपके अनुरोध और उसके रिस्पॉन्स के बीच की स्थिति को बनाए रखने के लिए करता है.
सर्वर वही वैल्यू दिखाता है जिसे आपने
इस पैरामीटर का इस्तेमाल कई कामों के लिए किया जा सकता है. जैसे, अपने आवेदन में
उपयोगकर्ता को सही संसाधन पर ले जाना, नॉन्स भेजना, और दूसरी साइटों से किए जाने वाले जालसाज़ी के अनुरोधों को
कम करना. आपके |
||||||||||||||||
login_hint |
ज़रूरी नहीं
अगर आपके ऐप्लिकेशन को पता है कि कौनसा उपयोगकर्ता पुष्टि करने की कोशिश कर रहा है, तो वह इस पैरामीटर का इस्तेमाल करके, Google के पुष्टि करने वाले सर्वर को संकेत दे सकता है. सर्वर इस संकेत का इस्तेमाल, लॉगिन फ़्लो को आसान बनाने के लिए या तो साइन-इन फ़ॉर्म में ईमेल फ़ील्ड को पहले से भरकर या एक से ज़्यादा लॉगिन वाले सही सेशन को चुनकर करता है. पैरामीटर की वैल्यू को किसी ईमेल पते या |
अनुमति देने वाले यूआरएल का सैंपल
नीचे दिए गए टैब अलग-अलग रीडायरेक्ट यूआरआई विकल्पों के लिए अनुमति देने वाले सैंपल यूआरएल दिखाते हैं.
हर यूआरएल, एक ऐसे स्कोप के ऐक्सेस का अनुरोध करता है जो लोगों का YouTube डेटा पाने की अनुमति देता है.redirect_uri
पैरामीटर की वैल्यू को छोड़कर, बाकी सभी यूआरएल एक जैसे हैं. यूआरएल में
ज़रूरी response_type
और client_id
पैरामीटर के साथ-साथ, वैकल्पिक state
पैरामीटर भी
शामिल होता है. हर यूआरएल में लाइन ब्रेक और स्पेस शामिल होते हैं, ताकि उन्हें पढ़ा जा सके.
कस्टम यूआरआई स्कीम
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl& response_type=code& state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken& redirect_uri=com.example.app%3A/oauth2redirect& client_id=client_id
लूपबैक आईपी पता
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl& response_type=code& state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken& redirect_uri=http%3A//127.0.0.1%3A9004& client_id=client_id
तीसरा चरण: Google, उपयोगकर्ता से सहमति लेने का अनुरोध करता है
इस चरण में, उपयोगकर्ता यह तय करता है कि आपके ऐप्लिकेशन को अनुरोध किया गया ऐक्सेस देना है या नहीं. इस चरण में, Google एक सहमति विंडो दिखाता है. इसमें आपके ऐप्लिकेशन और Google API सेवाओं का नाम दिखता है. इन सेवाओं को ऐक्सेस करने के लिए, Google उपयोगकर्ता के ऑथराइज़ेशन क्रेडेंशियल की मदद से अनुरोध करता है. साथ ही, ऐक्सेस के दायरों की खास जानकारी भी दिखाता है. इसके बाद, उपयोगकर्ता आपके ऐप्लिकेशन के अनुरोध किए गए एक या उससे ज़्यादा दायरों का ऐक्सेस देने के लिए सहमति दे सकता है या अनुरोध अस्वीकार कर सकता है.
आपके ऐप्लिकेशन को इस चरण में कुछ भी करने की ज़रूरत नहीं है, क्योंकि वह Google के OAuth 2.0 सर्वर से जवाब मिलने का इंतज़ार करता है. इससे यह पता चलता है कि ऐप्लिकेशन को ऐक्सेस दिया गया है या नहीं. इस जवाब के बारे में अगले चरण में बताया गया है.
गड़बड़ियां
Google के OAuth 2.0 ऑथराइज़ेशन एंडपॉइंट पर किए जाने वाले अनुरोधों की मदद से, उपयोगकर्ताओं को गड़बड़ी के मैसेज दिखाए जा सकते हैं. ऐसा, पुष्टि करने और अनुमति देने के अनुमानित फ़्लो के बजाय किया जाता है. आम तौर पर होने वाली गड़बड़ियों के कोड और उनके समाधान के बारे में यहां बताया गया है.
admin_policy_enforced
Google Workspace एडमिन की नीतियों की वजह से, Google खाता एक या एक से ज़्यादा दायरों की अनुमति नहीं दे सकता. Google Workspace एडमिन का सहायता लेख पढ़ें यह कंट्रोल करें कि तीसरे पक्ष और आपके डोमेन के कौनसे ऐप्लिकेशन, Google Workspace के डेटा को ऐक्सेस कर सकते हैं. इससे आपको इस बारे में ज़्यादा जानकारी मिलेगी कि आपके OAuth क्लाइंट आईडी का ऐक्सेस मिलने तक, एडमिन सभी दायरों या संवेदनशील और प्रतिबंधित दायरों के ऐक्सेस पर कैसे पाबंदी लगा सकता है.
disallowed_useragent
ऑथराइज़ेशन एंडपॉइंट, एम्बेड किए गए उपयोगकर्ता एजेंट के अंदर दिखाया जाता है, जिसे Google की OAuth 2.0 नीतियों के तहत अनुमति नहीं मिलती.
Android
android.webkit.WebView
में अनुमति देने के अनुरोध खोलते समय, Android डेवलपर को गड़बड़ी का यह मैसेज दिख सकता है.
इसके बजाय, डेवलपर को Android लाइब्रेरी का इस्तेमाल करना चाहिए. जैसे, Android के लिए Google साइन-इन या OpenID Foundation का Android के लिए AppAuth.
वेब डेवलपर को यह गड़बड़ी तब दिख सकती है, जब कोई Android ऐप्लिकेशन, एम्बेड किए गए उपयोगकर्ता एजेंट में सामान्य वेब लिंक खोलता है और उपयोगकर्ता आपकी साइट से Google के OAuth 2.0 ऑथराइज़ेशन एंडपॉइंट पर नेविगेट करता है. डेवलपर को ऑपरेटिंग सिस्टम के डिफ़ॉल्ट लिंक हैंडलर में, सामान्य लिंक को खोलने की अनुमति देनी चाहिए. इनमें Android ऐप्लिकेशन के लिंक हैंडलर या डिफ़ॉल्ट ब्राउज़र ऐप्लिकेशन, दोनों शामिल होते हैं. Android के कस्टम टैब लाइब्रेरी भी इस सुविधा का इस्तेमाल कर सकती है.
iOS
WKWebView
में अनुमति देने के अनुरोध खोलते समय, iOS और macOS डेवलपर को यह गड़बड़ी दिख सकती है.
इसके बजाय, डेवलपर को iOS लाइब्रेरी का इस्तेमाल करना चाहिए, जैसे कि
iOS के लिए Google Sign-In या Open Foundation का
iOS के लिए AppAuth.
वेब डेवलपर को यह गड़बड़ी तब दिख सकती है, जब कोई iOS या macOS ऐप्लिकेशन, एम्बेड किए गए उपयोगकर्ता एजेंट में कोई सामान्य वेब लिंक खोलता है और उपयोगकर्ता आपकी साइट से Google के OAuth 2.0 ऑथराइज़ेशन एंडपॉइंट पर
नेविगेट करता है. डेवलपर को ऑपरेटिंग सिस्टम के डिफ़ॉल्ट लिंक हैंडलर में, सामान्य लिंक को खोलने की अनुमति
देनी चाहिए. इनमें,
यूनिवर्सल लिंक
हैंडलर या डिफ़ॉल्ट ब्राउज़र ऐप्लिकेशन, दोनों शामिल होते हैं.
SFSafariViewController
लाइब्रेरी भी इस सुविधा का इस्तेमाल किया जा सकता है.
org_internal
अनुरोध में दिया गया OAuth क्लाइंट आईडी, एक ऐसे प्रोजेक्ट का हिस्सा है जो किसी Google Cloud संगठन के Google खातों का ऐक्सेस सीमित करता है. कॉन्फ़िगरेशन के इस विकल्प के बारे में ज़्यादा जानने के लिए, उस स्क्रीन पर OAuth के लिए सहमति सेट अप करने की प्रक्रिया से जुड़े सहायता लेख में, उपयोगकर्ता का टाइप सेक्शन देखें.
invalid_grant
अगर कोड की पुष्टि करने वाले टूल और चैलेंज का इस्तेमाल किया जा रहा है, तो code_callenge
पैरामीटर अमान्य है या मौजूद नहीं है. पक्का करें कि
code_challenge
पैरामीटर सही तरीके से सेट किया गया हो.
किसी ऐक्सेस टोकन को रीफ़्रेश करते समय, हो सकता है कि टोकन की समयसीमा खत्म हो गई हो या वह अमान्य हो गया हो. उपयोगकर्ता की फिर से पुष्टि करें और नए टोकन पाने के लिए, उपयोगकर्ता की सहमति मांगें. अगर आपको लगातार यह गड़बड़ी दिख रही है, तो पक्का करें कि आपका ऐप्लिकेशन सही तरीके से कॉन्फ़िगर किया गया हो. साथ ही, यह भी पक्का करें कि आपके अनुरोध में सही टोकन और पैरामीटर का इस्तेमाल किया जा रहा हो. ऐसा न करने पर, हो सकता है कि उपयोगकर्ता खाता मिटा दिया गया हो या बंद कर दिया गया हो.
redirect_uri_mismatch
अनुमति देने के अनुरोध में पास किया गया redirect_uri
, OAuth क्लाइंट आईडी के लिए, अनुमति वाले रीडायरेक्ट
यूआरआई से मेल नहीं खाता है. Google API Console Credentials pageमें,
अनुमति वाले रीडायरेक्ट यूआरआई की समीक्षा करें.
पास किया गया redirect_uri
, क्लाइंट टाइप के लिए अमान्य हो सकता है.
redirect_uri
पैरामीटर, OAuth आउट-ऑफ़-बैंड (OOB) फ़्लो को रेफ़र कर सकता है, जो अब काम नहीं करता. अपना इंटिग्रेशन अपडेट करने के लिए,
डेटा को दूसरी जगह भेजने से जुड़ी गाइड
देखें.
invalid_request
आपके किए गए अनुरोध में कोई गड़बड़ी थी. ऐसा कई वजहों से हो सकता है:
- अनुरोध सही तरीके से फ़ॉर्मैट नहीं किया गया था
- अनुरोध में ज़रूरी पैरामीटर मौजूद नहीं थे
- अनुरोध, पुष्टि करने के लिए किसी ऐसे तरीके का इस्तेमाल करता है जो Google पर काम नहीं करता. पुष्टि करें कि आपका OAuth इंटिग्रेशन, सुझाए गए इंटिग्रेशन के तरीके का इस्तेमाल करता है
- रीडायरेक्ट यूआरआई के लिए कस्टम स्कीम का इस्तेमाल किया जाता है : अगर आपको गड़बड़ी का मैसेज दिखता है कस्टम यूआरआई स्कीम Chrome ऐप्लिकेशन पर काम नहीं करती है या आपके Android क्लाइंट के लिए कस्टम यूआरआई स्कीम चालू नहीं है, तो इसका मतलब है कि कस्टम यूआरआई स्कीम का इस्तेमाल किया जा रहा है, जो Chrome ऐप्लिकेशन पर काम नहीं करती और वह Android पर डिफ़ॉल्ट रूप से बंद होती है. कस्टम यूआरआई स्कीम के विकल्पों के बारे में ज़्यादा जानें
चौथा चरण: OAuth 2.0 सर्वर रिस्पॉन्स को मैनेज करना
आपके ऐप्लिकेशन को जिस तरह से, अनुमति वाले रिस्पॉन्स मिलते हैं यह उस
रीडायरेक्ट यूआरआई स्कीम पर निर्भर करता है जिसका इस्तेमाल वह करता है. स्कीम कुछ भी हो, रिस्पॉन्स में ऑथराइज़ेशन कोड (code
) या कोई गड़बड़ी (error
) शामिल होगी. जैसे, error=access_denied
से पता चलता है कि उपयोगकर्ता ने अनुरोध अस्वीकार कर दिया है.
अगर उपयोगकर्ता आपके ऐप्लिकेशन का ऐक्सेस देता है, तो अगले चरण में बताए गए तरीके से, ऑथराइज़ेशन कोड को ऐक्सेस टोकन और रीफ़्रेश टोकन से बदला जा सकता है.
पांचवां चरण: टोकन को रीफ़्रेश करने और ऐक्सेस करने के लिए Exchange का ऑथराइज़ेशन कोड
ऐक्सेस टोकन के लिए ऑथराइज़ेशन कोड को एक्सचेंज करने के लिए, https://oauth2.googleapis.com/token
एंडपॉइंट को कॉल करें और ये पैरामीटर सेट करें:
फ़ील्ड | |
---|---|
client_id |
API Console Credentials pageसे मिला क्लाइंट आईडी. |
client_secret |
क्लाइंट सीक्रेट, जो API Console Credentials pageसे मिला है. |
code |
शुरुआती अनुरोध के बाद, ऑथराइज़ेशन कोड लौटाया गया. |
code_verifier |
कोड की पुष्टि करने वाला वह टूल जिसे आपने पहले चरण में बनाया है. |
grant_type |
जैसा कि OAuth 2.0 में बताया गया है, इस फ़ील्ड की वैल्यू authorization_code पर सेट होनी चाहिए. |
redirect_uri |
दिए गए client_id के लिए, API Console
Credentials page में आपके प्रोजेक्ट के लिए दिए गए
रीडायरेक्ट यूआरआई में से एक. |
नीचे दिए गए स्निपेट में, अनुरोध का एक सैंपल दिखाया गया है:
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7& client_id=your_client_id& client_secret=your_client_secret& redirect_uri=http://127.0.0.1:9004& grant_type=authorization_code
इस अनुरोध का जवाब देने के लिए, Google एक JSON ऑब्जेक्ट दिखाता है. इसमें, कुछ समय के लिए रहने वाला ऐक्सेस टोकन और रीफ़्रेश टोकन होता है.
इस जवाब में ये फ़ील्ड शामिल होते हैं:
फ़ील्ड | |
---|---|
access_token |
वह टोकन जो आपका ऐप्लिकेशन, Google API अनुरोध को अनुमति देने के लिए भेजता है. |
expires_in |
ऐक्सेस टोकन की बची हुई अवधि कुछ सेकंड में. |
id_token |
ध्यान दें: यह प्रॉपर्टी सिर्फ़ तब दिखती है, जब आपके अनुरोध में पहचान का स्कोप शामिल होता है, जैसे कि openid , profile या email . यह वैल्यू
JSON Web Token (JWT) होती है. इसमें उपयोगकर्ता की डिजिटल तौर पर साइन की गई पहचान
होती है. |
refresh_token |
ऐसा टोकन जिसका इस्तेमाल करके, नया ऐक्सेस टोकन पाया जा सकता है. रीफ़्रेश टोकन तब तक मान्य रहते हैं, जब तक उपयोगकर्ता ऐक्सेस रद्द नहीं कर देता. ध्यान दें कि इंस्टॉल किए गए ऐप्लिकेशन के लिए रीफ़्रेश टोकन हमेशा दिखाए जाते हैं. |
scope |
access_token के दिए ऐक्सेस के दायरे, स्पेस-डीलिमिटेड और केस-सेंसिटिव स्ट्रिंग की सूची के तौर पर दिखते हैं. |
token_type |
टोकन टाइप किया गया. फ़िलहाल, इस फ़ील्ड की वैल्यू हमेशा
Bearer पर सेट होती है. |
नीचे दिया गया स्निपेट एक सैंपल रिस्पॉन्स दिखाता है:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "token_type": "Bearer", "scope": "https://www.googleapis.com/auth/youtube.force-ssl", "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
Calling Google API
आपके ऐप्लिकेशन को ऐक्सेस टोकन मिल जाने के बाद, किसी उपयोगकर्ता खाते की ओर से Google API को कॉल करने के लिए, टोकन का इस्तेमाल किया जा सकता है. हालांकि, इसके लिए ज़रूरी है कि एपीआई के लिए ज़रूरी ऐक्सेस के दायरे दिए गए हों. ऐसा करने के लिए, एपीआई को किए गए अनुरोध में ऐक्सेस टोकन शामिल करें. इसके लिए, access_token
क्वेरी पैरामीटर या Authorization
एचटीटीपी हेडर Bearer
वैल्यू शामिल करें. जब मुमकिन हो, तब एचटीटीपी हेडर को प्राथमिकता दी जानी चाहिए, क्योंकि सर्वर लॉग में क्वेरी स्ट्रिंग अक्सर दिखती हैं. ज़्यादातर मामलों में,
Google API पर अपने कॉल सेट अप करने के लिए, क्लाइंट लाइब्रेरी का इस्तेमाल किया जा सकता है. उदाहरण के लिए,
YouTube Live Streaming API को कॉल करते समय.
ध्यान दें कि YouTube Live Streaming API, सेवा खाते के फ़्लो के साथ काम नहीं करता. सेवा खाते को YouTube खाते से लिंक करने का कोई तरीका नहीं है. इसलिए, इस फ़्लो का इस्तेमाल करके अनुरोधों को अनुमति देने की कोशिश करने पर, NoLinkedYouTubeAccount
गड़बड़ी जनरेट होगी.
OAuth 2.0 प्लेग्राउंड में, सभी Google API को आज़माया जा सकता है और उनके स्कोप देखे जा सकते हैं.
एचटीटीपी जीईटी के उदाहरण
Authorization: Bearer
एचटीटीपी हेडर का इस्तेमाल करके,
liveBroadcasts.list
एंडपॉइंट (YouTube Live Streaming API)
को कॉल करने पर ऐसा दिख सकता है. ध्यान दें कि आपको अपना ऐक्सेस टोकन बताना होगा:
GET /youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
यहां access_token
क्वेरी स्ट्रिंग पैरामीटर का इस्तेमाल करके, पुष्टि किए गए उपयोगकर्ता के लिए उसी एपीआई को कॉल किया गया है:
GET https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true
curl
के उदाहरण
curl
कमांड-लाइन ऐप्लिकेशन का इस्तेमाल करके, इन कमांड की जांच की जा सकती है. यहां एक उदाहरण दिया गया है, जिसमें एचटीटीपी हेडर विकल्प का इस्तेमाल किया जाता है (इसका सुझाव दिया जाता है):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true
इसके अलावा, क्वेरी स्ट्रिंग पैरामीटर विकल्प:
curl https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true
ऐक्सेस टोकन को रीफ़्रेश करना
ऐक्सेस टोकन, समय-समय पर खत्म हो जाते हैं और मिलते-जुलते एपीआई अनुरोध के लिए, अमान्य क्रेडेंशियल बन जाते हैं. अगर आपने टोकन से जुड़े स्कोप के लिए ऑफ़लाइन ऐक्सेस का अनुरोध किया है, तो उपयोगकर्ता से अनुमति मांगे बिना (उपयोगकर्ता के मौजूद न होने पर भी) ऐक्सेस टोकन को रीफ़्रेश किया जा सकता है.
किसी ऐक्सेस टोकन को रीफ़्रेश करने के लिए, आपका ऐप्लिकेशन Google के ऑथराइज़ेशन सर्वर (https://oauth2.googleapis.com/token
) को एचटीटीपीएस POST
का अनुरोध भेजता है. इस अनुरोध में ये पैरामीटर शामिल होते हैं:
फ़ील्ड | |
---|---|
client_id |
API Consoleसे मिला क्लाइंट आईडी. |
client_secret |
API Consoleसे मिला क्लाइंट सीक्रेट.
(client_secret Android, iOS या Chrome ऐप्लिकेशन के तौर पर रजिस्टर किए गए क्लाइंट के अनुरोधों पर
लागू नहीं होता है.)
|
grant_type |
जैसा कि OAuth 2.0 की खास बातों में बताया गया है, इस फ़ील्ड की वैल्यू refresh_token पर सेट होनी चाहिए. |
refresh_token |
ऑथराइज़ेशन कोड के एक्सचेंज से मिला रीफ़्रेश टोकन. |
नीचे दिए गए स्निपेट में, अनुरोध का एक सैंपल दिखाया गया है:
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded client_id=your_client_id& client_secret=your_client_secret& refresh_token=refresh_token& grant_type=refresh_token
जब तक उपयोगकर्ता ने ऐप्लिकेशन को दिया गया ऐक्सेस रद्द नहीं किया, तब तक टोकन सर्वर, JSON ऑब्जेक्ट दिखाता है. इस ऑब्जेक्ट में नया ऐक्सेस टोकन होता है. नीचे दिया गया स्निपेट एक सैंपल रिस्पॉन्स दिखाता है:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "scope": "https://www.googleapis.com/auth/drive.metadata.readonly", "token_type": "Bearer" }
ध्यान दें कि जारी किए जाने वाले रीफ़्रेश टोकन की संख्या सीमित है; हर क्लाइंट/उपयोगकर्ता के कॉम्बिनेशन के लिए एक सीमा और सभी क्लाइंट के लिए हर उपयोगकर्ता के लिए दूसरी सीमा. रीफ़्रेश टोकन को लंबे समय तक इस्तेमाल करने के लिए सेव करके रखना चाहिए. साथ ही, जब तक ये मान्य रहेंगे, इनका इस्तेमाल जारी रखना चाहिए. अगर आपका ऐप्लिकेशन बहुत ज़्यादा रीफ़्रेश टोकन का अनुरोध करता है, तो वह इन सीमाओं का पालन कर सकता है. इस स्थिति में, पुराने रीफ़्रेश टोकन काम करना बंद कर देंगे.
टोकन निरस्त करना
कुछ मामलों में, हो सकता है कि उपयोगकर्ता किसी ऐप्लिकेशन को दिया गया ऐक्सेस वापस लेना चाहें. उपयोगकर्ता, खाता सेटिंग में जाकर ऐक्सेस रद्द कर सकता है. ज़्यादा जानकारी के लिए, तीसरे पक्ष की उन साइटों और ऐप्लिकेशन के पास मौजूद, साइट या ऐप्लिकेशन के ऐक्सेस को हटाएं सेक्शन हटाएं जिनके पास आपके खाते का ऐक्सेस है सहायता दस्तावेज़ देखें.
किसी ऐप्लिकेशन को दी गई ऐक्सेस को प्रोग्राम के हिसाब से रद्द करना भी संभव है. प्रोग्राम के हिसाब से प्रोसेस को रद्द करना तब ज़रूरी होता है, जब कोई उपयोगकर्ता सदस्यता छोड़ता है, किसी ऐप्लिकेशन को हटा देता है या किसी ऐप्लिकेशन के लिए ज़रूरी एपीआई संसाधनों में काफ़ी बदलाव करता है. दूसरे शब्दों में, ऐप्लिकेशन को हटाने की प्रोसेस के एक हिस्से में एपीआई अनुरोध शामिल हो सकता है. इससे यह पक्का किया जाता है कि ऐप्लिकेशन को पहले दी गई अनुमतियां हटा दी गई हैं.
किसी टोकन को प्रोग्राम के हिसाब से रद्द करने के लिए, आपका ऐप्लिकेशन https://oauth2.googleapis.com/revoke
को अनुरोध करता है और टोकन को पैरामीटर के तौर पर शामिल करता है:
curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \ https://oauth2.googleapis.com/revoke?token={token}
टोकन, ऐक्सेस टोकन या रीफ़्रेश टोकन हो सकता है. अगर टोकन एक ऐक्सेस टोकन है और उसमें उससे जुड़ा रीफ़्रेश टोकन मौजूद है, तो रीफ़्रेश टोकन भी रद्द कर दिया जाएगा.
अगर सहमति रद्द हो जाती है, तो रिस्पॉन्स का एचटीटीपी स्टेटस कोड
200
होता है. गड़बड़ी की स्थितियों के लिए, गड़बड़ी के कोड के साथ एचटीटीपी स्टेटस कोड 400
दिखाया जाता है.
इसके बारे में और पढ़ें
नेटिव ऐप्लिकेशन के लिए, आईईटीएफ़ का सबसे सही मौजूदा तरीका OAuth 2.0 यहां बताए गए कई सबसे सही तरीकों के बारे में बताया गया है.