इस पेज का अनुवाद 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. लिंक को टेक्स्ट एडिटर में चिपकाएं. 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 पर अपने OAuth इंटिग्रेशन के लिए कस्टम स्कीम का इस्तेमाल किया जा रहा है, तो Android SDK के लिए सुझाए गए 'Google साइन-इन' के इस्तेमाल पर पूरी तरह से माइग्रेट करने के लिए, आपको नीचे दी गई कार्रवाइयां पूरी करनी होंगी:

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

ध्यान दें: Google API कंसोल में कस्टम स्कीम के लिए सहायता बंद करने से पहले, आपको अपने कोड अपडेट (अपने सभी उपयोगकर्ता आधार या पुराने डिवाइसों पर इस्तेमाल होने वाले समय को ध्यान में रखते हुए) पूरे करके डिप्लॉय करने चाहिए. इससे, उपयोगकर्ताओं को आपका ऐप्लिकेशन इस्तेमाल करते समय 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 कंसोल में कस्टम स्कीम के लिए सहायता बंद करें:
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 Web Store डेवलपर खाते का इस्तेमाल करना होगा. पुष्टि की प्रक्रिया पूरी करने के लिए, इन शर्तों को पूरा करना ज़रूरी है:

आपके Chrome Web Store डेवलपर डैशबोर्ड में, रजिस्टर किया गया एक आइटम होना चाहिए. साथ ही, उस आईडी का आइटम आईडी होना चाहिए जिसकी पहचान Chrome एक्सटेंशन OAuth क्लाइंट के लिए की जा रही है.
Chrome Web Store आइटम के लिए, आपको पब्लिशर होना ज़रूरी है. Chrome Web Store Developer Dashboard में, ऐक्सेस मैनेजमेंट के बारे में ज़्यादा जानें.

पुष्टि की प्रक्रिया पूरी करने के लिए, 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 Exchange के लिए प्रूफ़ की (PKCE) प्रोटोकॉल के साथ काम करता है, ताकि इंस्टॉल किए गए ऐप्लिकेशन के फ़्लो को ज़्यादा सुरक्षित बनाया जा सके. अनुमति के हर अनुरोध के लिए, एक यूनीक कोड की पुष्टि करने वाला टूल बनाया जाता है. ऑथराइज़ेशन कोड पाने के लिए, इसकी बदली गई वैल्यू जिसे "code_Challenge" कहा जाता है, ऑथराइज़ेशन सर्वर को भेजा जाता है.

कोड की पुष्टि करने वाली सुविधा बनाना

code_verifier एक हाई-एंट्रॉपी क्रिप्टोग्राफ़िक रैंडम स्ट्रिंग है, जिसमें रिज़र्व नहीं किए गए वर्णों [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" का इस्तेमाल किया जाता है. इसमें कम से कम 43 वर्ण और ज़्यादा से ज़्यादा 128 वर्ण होते हैं.

कोड की पुष्टि करने वाले में इतनी एंट्रॉपी होनी चाहिए कि वैल्यू का अनुमान लगाना संभव न हो.

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

कोड चैलेंज बनाने के दो तरीके काम करते हैं.

कोड चैलेंज जनरेट करने के तरीके
S256 (सुझाया गया)	यह कोड चैलेंज, कोड की पुष्टि करने वाले के SHA256 हैश को Base64URL (बिना पैडिंग) के कोड में बदला गया है. `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, Client-ID का रिवर्स डीएनएस नोटेशन होता है.
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 का दस्तावेज़ देखें.

login_hint

ज़रूरी नहीं

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

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

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

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

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

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

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

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

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

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

गड़बड़ियां

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

`admin_policy_enforced`

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

`disallowed_useragent`

ऑथराइज़ेशन एंडपॉइंट, एम्बेड किए गए ऐसे उपयोगकर्ता-एजेंट के अंदर दिखाया जाता है जिसे Google की OAuth 2.0 नीतियों के मुताबिक अनुमति नहीं है.

Android

android.webkit.WebView में अनुमति के अनुरोध खोलते समय, Android डेवलपर को गड़बड़ी का यह मैसेज दिख सकता है. इसके बजाय, डेवलपर को Android लाइब्रेरी का इस्तेमाल करना चाहिए. जैसे, Android के लिए 'Google साइन-इन' या UPI फ़ाउंडेशन का Android के लिए AppAuth.

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

iOS

iOS और macOS डेवलपर को WKWebView में अनुमति के अनुरोध खोलते समय यह गड़बड़ी दिख सकती है. इसके बजाय, डेवलपर को iOS लाइब्रेरी का इस्तेमाल करना चाहिए, जैसे कि iOS के लिए 'Google साइन-इन' या UPI फ़ाउंडेशन के iOS के लिए AppAuth.

जब कोई iOS या macOS ऐप्लिकेशन, एम्बेड किए गए किसी उपयोगकर्ता-एजेंट में कोई सामान्य वेब लिंक खोलता है और कोई उपयोगकर्ता आपकी साइट से, Google के OAuth 2.0 ऑथराइज़ेशन एंडपॉइंट पर नेविगेट करता है, तो वेब डेवलपर को यह गड़बड़ी दिख सकती है. डेवलपर को ऑपरेटिंग सिस्टम के डिफ़ॉल्ट लिंक हैंडलर में सामान्य लिंक खोलने की अनुमति देनी चाहिए. इसमें, Universal लिंक हैंडलर या डिफ़ॉल्ट ब्राउज़र ऐप्लिकेशन, दोनों शामिल हैं. 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 से पता चलता है कि उपयोगकर्ता ने अनुरोध अस्वीकार कर दिया है.

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

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

किसी ऐक्सेस टोकन को ऑथराइज़ेशन कोड से बदलने के लिए, 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"
}

Google API को कॉल करना

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

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

OAuth 2.0 Playground पर, सभी 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 सर्वर से मिलने वाले रिस्पॉन्स को मैनेज करना

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

Google API को कॉल करना

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

curl के उदाहरण

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

टोकन को रद्द करना

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

`admin_policy_enforced`

`disallowed_useragent`

`org_internal`

`invalid_grant`

`redirect_uri_mismatch`

`invalid_request`

`curl` के उदाहरण