इस पेज का अनुवाद Cloud Translation API से किया गया है.

मोबाइल और डेस्कटॉप ऐप्लिकेशन के लिए OAuth 2.0

अपनी शुभैह

इस दस्तावेज़ में बताया गया है कि फ़ोन, टैबलेट, और कंप्यूटर जैसे डिवाइसों पर इंस्टॉल किए गए ऐप्लिकेशन, 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 फ़्लो को लागू करने में आपकी मदद करने के लिए, आप यहां दी गई लाइब्रेरी और सैंपल का इस्तेमाल करें:

ज़रूरी शर्तें

अपने प्रोजेक्ट के लिए एपीआई चालू करना

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 के हर यूआरएल में शामिल होती है.
1. अपने iOS या iPadOS डिवाइस पर Apple App Store ऐप्लिकेशन खोलें.
2. अपना ऐप्लिकेशन खोजें.
3. शेयर बटन (वर्ग और तीर ऊपर प्रतीक) का चयन करें.
4. लिंक कॉपी करें चुनें.
5. लिंक को टेक्स्ट एडिटर में चिपकाएं. ऐप स्टोर आईडी, यूआरएल का आखिरी हिस्सा होता है.
  उदाहरण: 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 पर OAuth इंटिग्रेशन के लिए, फ़िलहाल किसी कस्टम स्कीम का इस्तेमाल किया जा रहा है, तो आपको 'Android के लिए Google साइन-इन' के सुझाए गए SDK टूल पर पूरी तरह से माइग्रेट करने के लिए, नीचे दी गई कार्रवाइयां पूरी करनी होंगी:

'Google साइन-इन' SDK टूल का इस्तेमाल करने के लिए, अपना कोड अपडेट करें.
Google API कंसोल में कस्टम स्कीम के लिए सहायता बंद करें.

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

'Google साइन-इन Android SDK' पर माइग्रेट करने के लिए, यह तरीका अपनाएं:

'Google साइन-इन' Android SDK का इस्तेमाल करने के लिए, अपना कोड अपडेट करें:
1. अपने कोड की जांच करके पता लगाएं कि 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 पैरामीटर की परिभाषा देखें.
2. scope और client_id अनुरोध पैरामीटर को ध्यान में रखें. आपको 'Google साइन-इन' SDK टूल को कॉन्फ़िगर करने की ज़रूरत होगी.
  ध्यान दें: अगर किसी तीसरे पक्ष की लाइब्रेरी का इस्तेमाल किया जा रहा है, तो उस जानकारी को ढूंढने के लिए लाइब्रेरी की कॉन्फ़िगरेशन फ़ाइल देखें.
3. SDK टूल सेट अप करने के लिए, अपने Android ऐप्लिकेशन में 'Google साइन इन' को इंटिग्रेट करना शुरू करें के निर्देशों का पालन करें. अपने बैकएंड सर्वर का OAuth 2.0 क्लाइंट आईडी पाने के चरण को छोड़ा जा सकता है. ऐसा इसलिए, क्योंकि आपको पिछले चरण से मिले client_id का फिर से इस्तेमाल करना होगा.
4. सर्वर-साइड एपीआई का ऐक्सेस चालू करने से जुड़े निर्देशों का पालन करें. इसके लिए, यह तरीका अपनाएं:
  1. जिन दायरों के लिए अनुमति का अनुरोध किया जा रहा है उनसे जुड़ा ऑथराइज़ेशन कोड पाने के लिए, getServerAuthCode तरीके का इस्तेमाल करें.
  2. अपने ऐप्लिकेशन के बैकएंड पर, ऑथराइज़ेशन कोड भेजें, ताकि ऐक्सेस और रीफ़्रेश टोकन मिल सके.
  3. उपयोगकर्ता की ओर से Google API को कॉल करने के लिए, वापस मिले ऐक्सेस टोकन का इस्तेमाल करें.
  ध्यान दें: अगर आपके ऐप्लिकेशन को ऑफ़लाइन ऐक्सेस की ज़रूरत नहीं है, तो क्लाइंट-साइड एपीआई ऐक्सेस का अनुरोध करने के लिए, इन निर्देशों का पालन करें.
Google API Console में, कस्टम स्कीम के लिए सहायता बंद करें:
1. अपनी OAuth 2.0 क्रेडेंशियल सूची पर जाएं और अपना Android क्लाइंट चुनें.
2. बेहतर सेटिंग सेक्शन पर जाएं, कस्टम यूआरआई स्कीम चालू करें चेकबॉक्स से सही का निशान हटाएं और कस्टम यूआरआई स्कीम से जुड़ी सहायता बंद करने के लिए, सेव करें पर क्लिक करें.

कस्टम यूआरआई स्कीम चालू करना

अगर सुझाया गया विकल्प काम नहीं करता है, तो अपने Android क्लाइंट के लिए कस्टम यूआरआई स्कीम चालू करने के लिए, नीचे दिए गए निर्देशों का पालन करें:

अपनी OAuth 2.0 क्रेडेंशियल सूची पर जाएं और अपना Android क्लाइंट चुनें.
बेहतर सेटिंग सेक्शन पर जाएं, कस्टम यूआरआई स्कीम चालू करें चेकबॉक्स पर सही का निशान लगाएं और कस्टम यूआरआई स्कीम से जुड़ी सहायता चालू करने के लिए, सेव करें पर क्लिक करें.

Chrome ऐप्लिकेशन पर कस्टम यूआरआई स्कीम का इस्तेमाल करने के विकल्प

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 नहीं) ऐप्लिकेशन
फ़ॉर्म की वैल्यू	ऐप्लिकेशन के टाइप को डेस्कटॉप ऐप्लिकेशन पर सेट करें.

ध्यान दें: लूपबैक आईपी पते के बारे में ज़्यादा जानकारी पाने के लिए, redirect_uri पैरामीटर की परिभाषा देखें. लूपबैक आईपी की जगह localhost का इस्तेमाल भी किया जा सकता है. हालांकि, इस कॉन्फ़िगरेशन की वजह से क्लाइंट फ़ायरवॉल में समस्याएं आ सकती हैं. सभी नहीं, लेकिन ज़्यादातर फ़ायरवॉल में लूपबैक कम्यूनिकेशन की सुविधा होती है.

मैन्युअल तरीके से कॉपी करें/चिपकाएं

ऐक्सेस के दायरों की पहचान करना

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

हमारा सुझाव है कि 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 हैश है. `code_challenge` = BASE64URL-ENCODE(SHA256(ASCII(`code_verifier`)))
सादा	कोड चैलेंज और ऊपर जनरेट किए गए कोड की पुष्टि करने वाले कोड की वैल्यू, दोनों एक ही हैं. `code_challenge` = `code_verifier`

दूसरा चरण: 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में कॉन्फ़िगर किया है. अगर यह वैल्यू, अनुमति वाले यूआरआई से मेल नहीं खाती है, तो आपको redirect_uri_mismatch गड़बड़ी मिलेगी.

नीचे दी गई टेबल में, हर तरीके के लिए redirect_uri पैरामीटर की सही वैल्यू दिखाई गई है:

redirect_uri की वैल्यू

कस्टम यूआरआई स्कीम

com.example.app:redirect_uri_path

या

com.googleusercontent.apps.123:redirect_uri_path

com.example.app, आपके कंट्रोल वाले डोमेन का रिवर्स डीएनएस नोटेशन है. कस्टम स्कीम में मान्य पीरियड शामिल होना चाहिए.
com.googleusercontent.apps.123, क्लाइंट आईडी का रिवर्स डीएनएस नोटेशन है.
redirect_uri_path, पाथ का एक वैकल्पिक कॉम्पोनेंट है, जैसे कि /oauth2redirect. ध्यान दें कि पाथ एक स्लैश से शुरू होना चाहिए, जो सामान्य एचटीटीपी यूआरएल से अलग होता है.

लूपबैक का आईपी पता

http://127.0.0.1:port या http://[::1]:port

अपने प्लैटफ़ॉर्म से, काम के लूपबैक आईपी पते के बारे में क्वेरी करें. साथ ही, किसी रैंडम पोर्ट पर एचटीटीपी लिसनर का इस्तेमाल करें. port को उस असल पोर्ट नंबर से बदलें जिस पर आपका ऐप्लिकेशन सुनता है.

ध्यान दें कि मोबाइल ऐप्लिकेशन पर, लूपबैक आईपी पते के रीडायरेक्ट के विकल्प की सुविधा बंद है.

response_type

ज़रूरी

इससे यह तय होता है कि Google OAuth 2.0 एंडपॉइंट, ऑथराइज़ेशन कोड दिखाता है या नहीं.

इंस्टॉल किए गए ऐप्लिकेशन के लिए पैरामीटर मान को code पर सेट करें.

scope

ज़रूरी

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

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

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 को ऐक्सेस करने के लिए किया जा सकता है.

code_challenge

सुझाया गया

कोड में बदले गए ऐसे code_verifier के बारे में बताता है जिसे ऑथराइज़ेशन कोड एक्सचेंज के दौरान, सर्वर-साइड चैलेंज के तौर पर इस्तेमाल किया जाएगा. ज़्यादा जानकारी के लिए, ऊपर दिया गया कोड चैलेंज बनाएं सेक्शन देखें.

code_challenge_method

सुझाया गया

इससे पता चलता है कि code_verifier को कोड में बदलने के लिए कौनसा तरीका इस्तेमाल किया गया था. इस तरीके का इस्तेमाल ऑथराइज़ेशन कोड एक्सचेंज के दौरान किया जाएगा. इस पैरामीटर का इस्तेमाल, ऊपर बताए गए code_challenge पैरामीटर के साथ किया जाना चाहिए. अगर किसी अनुरोध में code_challenge शामिल है, तो code_challenge_method की वैल्यू, डिफ़ॉल्ट रूप से plain हो जाती है. इस पैरामीटर के लिए, सिर्फ़ S256 या plain वैल्यू इस्तेमाल की जा सकती हैं.

state

सुझाया गया

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

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

अहम जानकारी: OAuth क्लाइंट को OAuth2 की खास बातों में बताए गए तरीके के मुताबिक, सीएसआरएफ को रोकना होगा. ऐसा करने का एक तरीका यह है कि अनुमति के अनुरोध और ऑथराइज़ेशन सर्वर के रिस्पॉन्स के बीच की स्थिति बनाए रखने के लिए, state पैरामीटर का इस्तेमाल किया जाए.

login_hint

ज़रूरी नहीं

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

पैरामीटर की वैल्यू को किसी ईमेल पते या sub आइडेंटिफ़ायर पर सेट करें. यह वैल्यू, उपयोगकर्ता के Google आईडी के बराबर होती है.

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

अनुमति देने वाले यूआरएल का सैंपल

नीचे दिए गए टैब अलग-अलग रीडायरेक्ट यूआरआई विकल्पों के लिए अनुमति देने वाले सैंपल यूआरएल दिखाते हैं.

हर यूआरएल, एक ऐसे स्कोप के ऐक्सेस का अनुरोध करता है जो व्यक्ति का YouTube खाता देखने की अनुमति देता है.

redirect_uri पैरामीटर की वैल्यू को छोड़कर, बाकी सभी यूआरएल एक जैसे हैं. यूआरएल में ज़रूरी response_type और client_id पैरामीटर के साथ-साथ, वैकल्पिक state पैरामीटर भी शामिल होता है. हर यूआरएल में लाइन ब्रेक और स्पेस शामिल होते हैं, ताकि उन्हें पढ़ा जा सके.

तीसरा चरण: 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` पर सेट होती है.

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

नीचे दिया गया स्निपेट एक सैंपल रिस्पॉन्स दिखाता है:

{
  "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 Data API को कॉल करते समय.

ध्यान दें कि YouTube Data API, सेवा खातों के साथ सिर्फ़ YouTube कॉन्टेंट के ऐसे मालिकों के लिए काम करता है जो एक से ज़्यादा YouTube चैनलों के मालिक हैं और उन्हें मैनेज करते हैं. जैसे, रिकॉर्ड लेबल और फ़िल्म स्टूडियो.

OAuth 2.0 प्लेग्राउंड में, सभी Google API को आज़माया जा सकता है और उनके स्कोप देखे जा सकते हैं.

एचटीटीपी जीईटी के उदाहरण

Authorization: Bearer एचटीटीपी हेडर का इस्तेमाल करके, youtube.channels एंडपॉइंट (YouTube Data API) को कॉल करने पर, ऐसा कुछ दिख सकता है. ध्यान दें कि आपको अपना ऐक्सेस टोकन बताना होगा:

GET /youtube/v3/channels?part=snippet&mine=true HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

यहां access_token क्वेरी स्ट्रिंग पैरामीटर का इस्तेमाल करके, पुष्टि किए गए उपयोगकर्ता के लिए उसी एपीआई को कॉल किया गया है:

GET https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true

`curl` के उदाहरण

curl कमांड-लाइन ऐप्लिकेशन का इस्तेमाल करके, इन कमांड की जांच की जा सकती है. यहां एक उदाहरण दिया गया है, जिसमें एचटीटीपी हेडर विकल्प का इस्तेमाल किया जाता है (इसका सुझाव दिया जाता है):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/channels?part=snippet&mine=true

इसके अलावा, क्वेरी स्ट्रिंग पैरामीटर विकल्प:

curl https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&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 यहां बताए गए कई सबसे सही तरीकों के बारे में बताया गया है.

मोबाइल और डेस्कटॉप ऐप्लिकेशन के लिए OAuth 2.0

लाइब्रेरी और सैंपल

ज़रूरी शर्तें

अपने प्रोजेक्ट के लिए एपीआई चालू करना

अनुमति देने वाले क्रेडेंशियल बनाएं

Android

iOS

यूडब्ल्यूपी

कस्टम यूआरआई स्कीम (Android, iOS, UWP)

Android SDK टूल के लिए 'Google साइन-इन' पर माइग्रेट करने का तरीका

कस्टम यूआरआई स्कीम चालू करना

ऐप्लिकेशन के मालिकाना हक की पुष्टि करना (Android, Chrome)

Android

Chrome

लूपबैक आईपी पता (macOS, Linux, Windows डेस्कटॉप)

मैन्युअल तरीके से कॉपी करें/चिपकाएं

ऐक्सेस के दायरों की पहचान करना

OAuth 2.0 ऐक्सेस टोकन पाना

पहला चरण: कोड की पुष्टि करने वाला प्रोग्राम और चैलेंज जनरेट करना

कोड की पुष्टि करने वाला प्रोग्राम बनाएं

कोड चैलेंज बनाएं

दूसरा चरण: Google के OAuth 2.0 सर्वर पर अनुरोध भेजना

अनुमति देने वाले यूआरएल का सैंपल

कस्टम यूआरआई स्कीम

लूपबैक आईपी पता

तीसरा चरण: Google, उपयोगकर्ता से सहमति लेने का अनुरोध करता है

गड़बड़ियां

admin_policy_enforced

disallowed_useragent

Android

iOS

org_internal

invalid_grant

redirect_uri_mismatch

invalid_request

चौथा चरण: OAuth 2.0 सर्वर रिस्पॉन्स को मैनेज करना

पांचवां चरण: टोकन को रीफ़्रेश करने और ऐक्सेस करने के लिए Exchange का ऑथराइज़ेशन कोड

Calling Google API

एचटीटीपी जीईटी के उदाहरण

curl के उदाहरण

ऐक्सेस टोकन को रीफ़्रेश करना

टोकन निरस्त करना

इसके बारे में और पढ़ें

`admin_policy_enforced`

`disallowed_useragent`

`org_internal`

`invalid_grant`

`redirect_uri_mismatch`

`invalid_request`

`curl` के उदाहरण