JavaScript वेब ऐप्लिकेशन के लिए, OAuth 2.0 का इस्तेमाल करना

इस दस्तावेज़ में बताया गया है कि किसी JavaScript वेब ऐप्लिकेशन से, YouTube Analytics API या YouTube Reporting API को ऐक्सेस करने के लिए, OAuth 2.0 को कैसे इस्तेमाल किया जा सकता है. OAuth 2.0, उपयोगकर्ताओं को अपने उपयोगकर्ता नाम, पासवर्ड, और दूसरी जानकारी को निजी रखते हुए, किसी ऐप्लिकेशन के साथ चुनिंदा डेटा शेयर करने की सुविधा देता है. उदाहरण के लिए, कोई ऐप्लिकेशन किसी चैनल का YouTube Analytics डेटा वापस पाने की अनुमति पाने के लिए, OAuth 2.0 का इस्तेमाल कर सकता है.

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

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

Google API क्लाइंट लाइब्रेरी और Google Identity सेवाएं

अगर आपने Google को अनुमति वाले कॉल करने के लिए, JavaScript के लिए Google API क्लाइंट लाइब्रेरी का इस्तेमाल किया है, तो आपको OAuth 2.0 फ़्लो को मैनेज करने के लिए, Google Identity Services की JavaScript लाइब्रेरी का इस्तेमाल करना चाहिए. कृपया Google Identity Services का टोकन मॉडल देखें. यह OAuth 2.0 इंप्लिसिट ग्रांट फ़्लो पर आधारित है.

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

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

Google API को कॉल करने वाले किसी भी ऐप्लिकेशन को उन एपीआई को API Consoleमें चालू करना होगा.

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

  1. Google API Consoleमें Open the API Library .
  2. If prompted, select a project, or create a new one.
  3. YouTube Analytics API और YouTube Reporting API को ढूंढने और चालू करने के लिए, लाइब्रेरी पेज का इस्तेमाल करें. YouTube Analytics का डेटा हासिल करने वाले कई ऐप्लिकेशन, YouTube Data API के साथ भी इंटरफ़ेस करते हैं. ऐसे अन्य एपीआई ढूंढें जिनका इस्तेमाल आपका ऐप्लिकेशन करेगा और उन्हें भी चालू करेगा.

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

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

  1. Go to the Credentials page.
  2. क्रेडेंशियल बनाएं > OAuth क्लाइंट आईडी पर क्लिक करें.
  3. वेब ऐप्लिकेशन ऐप्लिकेशन का टाइप चुनें.
  4. फ़ॉर्म भरें. Google API के लिए अनुमति वाले अनुरोध करने के लिए, JavaScript का इस्तेमाल करने वाले ऐप्लिकेशन को, अनुमति वाले JavaScript ऑरिजिन के बारे में बताना होगा. ऑरिजिन उन डोमेन की पहचान करता है, जिनसे आपका ऐप्लिकेशन OAuth 2.0 सर्वर को अनुरोध भेज सकता है. ये ऑरिजिन, पुष्टि करने के Google के नियमों के मुताबिक होने चाहिए.

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

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

हमारा सुझाव है कि OAuth 2.0 की अनुमति का इस्तेमाल शुरू करने से पहले, आप उन दायरों की पहचान कर लें जिन्हें ऐक्सेस करने के लिए आपके ऐप्लिकेशन को अनुमति की ज़रूरत होगी.

YouTube Analytics API इन दायरों का इस्तेमाल करता है:

कार्यक्षेत्र
https://www.googleapis.com/auth/youtube अपना YouTube खाता प्रबंधित करें
https://www.googleapis.com/auth/youtube.readonly अपना YouTube खाता देखें
https://www.googleapis.com/auth/youtubepartner YouTube पर अपनी संपत्ति और संबंधित सामग्री देखें और प्रबंधित करें
https://www.googleapis.com/auth/yt-analytics-monetary.readonly अपनी YouTube सामग्री के लिए मौद्रिक और गैर-मौद्रिक YouTube Analytics रिपोर्ट देखें
https://www.googleapis.com/auth/yt-analytics.readonly अपनी YouTube सामग्री के लिए YouTube Analytics रिपोर्ट देखें

YouTube Reporting API इन स्कोप का इस्तेमाल करता है:

कार्यक्षेत्र
https://www.googleapis.com/auth/yt-analytics-monetary.readonly अपनी YouTube सामग्री के लिए मौद्रिक और गैर-मौद्रिक YouTube Analytics रिपोर्ट देखें
https://www.googleapis.com/auth/yt-analytics.readonly अपनी YouTube सामग्री के लिए YouTube Analytics रिपोर्ट देखें

OAuth 2.0 एपीआई का दायरा दस्तावेज़ में, उन दायरों की पूरी सूची दी गई है जिनका इस्तेमाल, Google API को ऐक्सेस करने के लिए किया जा सकता है.

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

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

पहला चरण: Google के OAuth 2.0 सर्वर पर रीडायरेक्ट करना

किसी उपयोगकर्ता के डेटा को ऐक्सेस करने की अनुमति मांगने के लिए, उसे Google के OAuth 2.0 सर्वर पर रीडायरेक्ट करें.

OAuth 2.0 एंडपॉइंट

ऐक्सेस का अनुरोध करने के लिए, https://accounts.google.com/o/oauth2/v2/auth पर Google के OAuth 2.0 एंडपॉइंट से यूआरएल जनरेट करें. इस एंडपॉइंट को एचटीटीपीएस पर ऐक्सेस किया जा सकता है; सामान्य एचटीटीपी कनेक्शन अस्वीकार किए जाते हैं.

Google का ऑथराइज़ेशन सर्वर, वेब सर्वर ऐप्लिकेशन के लिए नीचे दिए गए क्वेरी स्ट्रिंग पैरामीटर के साथ काम करता है:

पैरामीटर
client_id ज़रूरी

आपके ऐप्लिकेशन का क्लाइंट आईडी. यह वैल्यू API Console Credentials pageमें देखी जा सकती है.

redirect_uri ज़रूरी

यह तय करता है कि उपयोगकर्ता के ऑथराइज़ेशन फ़्लो को पूरा करने के बाद, एपीआई सर्वर उपयोगकर्ता को कहां रीडायरेक्ट करता है. यह वैल्यू उस OAuth 2.0 क्लाइंट के लिए तय किए गए किसी ऐसे रीडायरेक्ट यूआरआई से पूरी तरह मेल खानी चाहिए जिसे आपने अपने क्लाइंट के API Console Credentials pageमें कॉन्फ़िगर किया है. अगर यह वैल्यू, दिए गए client_id के लिए अनुमति वाले रीडायरेक्ट यूआरआई से मेल नहीं खाती है, तो आपको redirect_uri_mismatch गड़बड़ी मिलेगी.

ध्यान रखें कि http या https स्कीम, केस, और ट्रेलिंग स्लैश ('/') सभी मेल खाने चाहिए.

response_type ज़रूरी

JavaScript ऐप्लिकेशन को पैरामीटर का मान token पर सेट करना होगा. यह वैल्यू, Google की अनुमति देने वाले सर्वर को, यूआरआई (#) के फ़्रैगमेंट आइडेंटिफ़ायर में name=value पेयर के तौर पर ऐक्सेस टोकन देने का निर्देश देती है. अनुमति देने की प्रोसेस पूरी करने के बाद, उपयोगकर्ता को इस फ़्रैगमेंट में रीडायरेक्ट किया जाता है.

scope ज़रूरी

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

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

YouTube Analytics API इन दायरों का इस्तेमाल करता है:

कार्यक्षेत्र
https://www.googleapis.com/auth/youtube अपना YouTube खाता प्रबंधित करें
https://www.googleapis.com/auth/youtube.readonly अपना YouTube खाता देखें
https://www.googleapis.com/auth/youtubepartner YouTube पर अपनी संपत्ति और संबंधित सामग्री देखें और प्रबंधित करें
https://www.googleapis.com/auth/yt-analytics-monetary.readonly अपनी YouTube सामग्री के लिए मौद्रिक और गैर-मौद्रिक YouTube Analytics रिपोर्ट देखें
https://www.googleapis.com/auth/yt-analytics.readonly अपनी YouTube सामग्री के लिए YouTube Analytics रिपोर्ट देखें

YouTube Reporting API इन स्कोप का इस्तेमाल करता है:

कार्यक्षेत्र
https://www.googleapis.com/auth/yt-analytics-monetary.readonly अपनी YouTube सामग्री के लिए मौद्रिक और गैर-मौद्रिक YouTube Analytics रिपोर्ट देखें
https://www.googleapis.com/auth/yt-analytics.readonly अपनी YouTube सामग्री के लिए YouTube Analytics रिपोर्ट देखें

OAuth 2.0 एपीआई का दायरा दस्तावेज़, उन दायरों की पूरी सूची देता है जिनका इस्तेमाल, Google API को ऐक्सेस करने के लिए किया जा सकता है.

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

state सुझाया गया

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

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

include_granted_scopes ज़रूरी नहीं

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

login_hint ज़रूरी नहीं

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

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

prompt ज़रूरी नहीं

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

आपको ये वैल्यू दिख सकती हैं:

none पुष्टि करने वाली या सहमति वाली कोई स्क्रीन न दिखाएं. दूसरी वैल्यू के साथ जानकारी नहीं दी जानी चाहिए.
consent उपयोगकर्ता को सहमति के लिए अनुरोध भेजें.
select_account उपयोगकर्ता से खाता चुनने का अनुरोध करें.

Google के ऑथराइज़ेशन सर्वर पर रीडायरेक्ट करने वाला सैंपल

नीचे दिए गए सैंपल यूआरएल में ऑफ़लाइन ऐक्सेस (access_type=offline) का अनुरोध किया गया है. यह ऐक्सेस ऐसे स्कोप के ज़रिए दिया गया है जिससे उपयोगकर्ता की YouTube Analytics रिपोर्ट को फिर से पाने का ऐक्सेस मिलता है. यह इंक्रीमेंटल ऑथराइज़ेशन का इस्तेमाल करता है, ताकि यह पक्का किया जा सके कि नए ऐक्सेस टोकन में वे सभी स्कोप शामिल हों जिनके लिए उपयोगकर्ता ने पहले ऐप्लिकेशन का ऐक्सेस दिया था. यूआरएल, ज़रूरी redirect_uri, response_type, और client_id पैरामीटर के साथ-साथ state पैरामीटर के लिए भी वैल्यू सेट करता है. यूआरएल में लाइन ब्रेक और स्पेस होते हैं, ताकि उन्हें आसानी से पढ़ा जा सके.

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly&
 include_granted_scopes=true&
 state=state_parameter_passthrough_value&
 redirect_uri=http%3A%2F%2Flocalhost%2Foauth2callback&
 response_type=token&
 client_id=client_id

अनुरोध का यूआरएल बनाने के बाद, उपयोगकर्ता को उस पर रीडायरेक्ट करें.

JavaScript सैंपल कोड

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

/*
 * Create form to request access token from Google's OAuth 2.0 server.
 */
function oauthSignIn() {
  // Google's OAuth 2.0 endpoint for requesting an access token
  var oauth2Endpoint = 'https://accounts.google.com/o/oauth2/v2/auth';

  // Create <form> element to submit parameters to OAuth 2.0 endpoint.
  var form = document.createElement('form');
  form.setAttribute('method', 'GET'); // Send as a GET request.
  form.setAttribute('action', oauth2Endpoint);

  // Parameters to pass to OAuth 2.0 endpoint.
  var params = {'client_id': 'YOUR_CLIENT_ID',
                'redirect_uri': 'YOUR_REDIRECT_URI',
                'response_type': 'token',
                'scope': 'https://www.googleapis.com/auth/yt-analytics.readonly',
                'include_granted_scopes': 'true',
                'state': 'pass-through value'};

  // Add form parameters as hidden input values.
  for (var p in params) {
    var input = document.createElement('input');
    input.setAttribute('type', 'hidden');
    input.setAttribute('name', p);
    input.setAttribute('value', params[p]);
    form.appendChild(input);
  }

  // Add form to page and submit it to open the OAuth 2.0 endpoint.
  document.body.appendChild(form);
  form.submit();
}

दूसरा चरण: 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_client

जिस ऑरिजिन से अनुरोध किया गया था उसे इस क्लाइंट के लिए अनुमति नहीं है. origin_mismatch देखें.

invalid_grant

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

origin_mismatch

अनुमति देने के अनुरोध की शुरुआत होने वाली JavaScript की स्कीम, डोमेन, और/या पोर्ट शायद OAuth क्लाइंट आईडी के लिए रजिस्टर किए गए अनुमति वाले JavaScript ऑरिजिन यूआरआई से मेल न खाए. Google API Console Credentials pageमें अनुमति वाले JavaScript ऑरिजिन की समीक्षा करें.

redirect_uri_mismatch

अनुमति देने के अनुरोध में पास किया गया redirect_uri, OAuth क्लाइंट आईडी के आधिकारिक रीडायरेक्ट यूआरआई से मेल नहीं खाता. Google API Console Credentials pageमें अनुमति वाले रीडायरेक्ट यूआरआई की समीक्षा करें.

अनुमति देने के अनुरोध की शुरुआत होने वाली JavaScript की स्कीम, डोमेन, और/या पोर्ट शायद OAuth क्लाइंट आईडी के लिए रजिस्टर किए गए अनुमति वाले JavaScript ऑरिजिन यूआरआई से मेल न खाए. Google API Console Credentials pageमें अनुमति वाले JavaScript ऑरिजिन की समीक्षा करें.

redirect_uri पैरामीटर, OAuth आउट-ऑफ़-बैंड (OOB) फ़्लो के बारे में बता सकता है. यह फ़्लो अब काम नहीं करता. अपना इंटिग्रेशन अपडेट करने के लिए, डेटा को दूसरी जगह भेजने से जुड़ी गाइड देखें.

invalid_request

आपने जो अनुरोध किया था उसमें कोई गड़बड़ी है. ऐसा कई वजहों से हो सकता है:

  • अनुरोध सही तरीके से फ़ॉर्मैट नहीं किया गया था
  • अनुरोध में ज़रूरी पैरामीटर मौजूद नहीं हैं
  • अनुरोध के लिए, अनुमति देने के किसी ऐसे तरीके का इस्तेमाल किया गया है जो Google पर काम नहीं करता. पुष्टि करें कि आपका OAuth इंटिग्रेशन, इंटिग्रेशन के लिए सुझाए गए तरीके का इस्तेमाल करता है

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

OAuth 2.0 एंडपॉइंट

OAuth 2.0 सर्वर, आपके ऐक्सेस टोकन अनुरोध में बताए गए redirect_uri को रिस्पॉन्स भेजता है.

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

  • ऐक्सेस टोकन से मिलने वाला रिस्पॉन्स:

    https://oauth2.example.com/callback#access_token=4/P7q7W91&token_type=Bearer&expires_in=3600

    access_token पैरामीटर के अलावा, फ़्रैगमेंट स्ट्रिंग में token_type पैरामीटर भी होता है. यह पैरामीटर हमेशा Bearer पर सेट होता है. साथ ही, expires_in पैरामीटर भी होता है, जो टोकन के इस्तेमाल की अवधि सेकंड में बताता है. अगर ऐक्सेस टोकन के अनुरोध में state पैरामीटर की जानकारी दी गई थी, तो रिस्पॉन्स में इसकी वैल्यू भी शामिल की जाती है.

  • गड़बड़ी का जवाब:
    https://oauth2.example.com/callback#error=access_denied

OAuth 2.0 सर्वर के रिस्पॉन्स का उदाहरण

नीचे दिए गए सैंपल यूआरएल पर क्लिक करके, इस फ़्लो की जांच की जा सकती है. यह यूआरएल, आपकी Google Drive में मौजूद फ़ाइलों का मेटाडेटा देखने के लिए, रीड ओनली ऐक्सेस का अनुरोध करता है:

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly&
 include_granted_scopes=true&
 state=state_parameter_passthrough_value&
 redirect_uri=http%3A%2F%2Flocalhost%2Foauth2callback&
 response_type=token&
 client_id=client_id

OAuth 2.0 फ़्लो को पूरा करने के बाद, आपको http://localhost/oauth2callback पर रीडायरेक्ट कर दिया जाएगा. अगर आपकी लोकल मशीन, उस पते पर फ़ाइल दिखाने के लिए तैयार नहीं है, तो यूआरएल 404 NOT FOUND गड़बड़ी दिखाएगा. अगले चरण में, उपयोगकर्ता को आपके ऐप्लिकेशन पर वापस रीडायरेक्ट किए जाने पर, यूआरआई में वापस की गई जानकारी के बारे में ज़्यादा जानकारी दी जाती है.

Google API को कॉल करना

OAuth 2.0 एंडपॉइंट

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

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

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

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

Authorization: Bearer एचटीटीपी हेडर का इस्तेमाल करके reports.query एंडपॉइंट (YouTube Analytics एपीआई) को किया जाने वाला कॉल कुछ ऐसा दिख सकता है. ध्यान दें कि आपको अपना ऐक्सेस टोकन खुद तय करना होगा:

GET /youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

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

GET https://www.googleapis.com/youtube/analytics/v1/reports?access_token=access_token&ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views

curl के उदाहरण

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

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views

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

curl https://www.googleapis.com/youtube/analytics/v1/reports?access_token=access_token&ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views

JavaScript सैंपल कोड

नीचे दिए गए कोड स्निपेट में बताया गया है कि Google API को अनुरोध भेजने के लिए, सीओआरएस (क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग) का इस्तेमाल कैसे किया जाता है. इस उदाहरण में JavaScript के लिए, Google API क्लाइंट लाइब्रेरी का इस्तेमाल नहीं किया गया है. हालांकि, अगर क्लाइंट लाइब्रेरी का इस्तेमाल नहीं किया जा रहा है, तब भी लाइब्रेरी के दस्तावेज़ में मौजूद सीओआरएस सहायता गाइड से, आपको इन अनुरोधों को बेहतर तरीके से समझने में मदद मिल सकती है.

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

var xhr = new XMLHttpRequest();
xhr.open('GET',
    'https://www.googleapis.com/youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views&' +
    'access_token=' + params['access_token']);
xhr.onreadystatechange = function (e) {
  console.log(xhr.response);
};
xhr.send(null);

उदाहरण को पूरा करें

OAuth 2.0 एंडपॉइंट

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

OAuth 2.0 फ़्लो के लिए, पेज पर यह तरीका अपनाएं:

  1. यह उपयोगकर्ता को Google के OAuth 2.0 सर्वर पर भेजता है, जो https://www.googleapis.com/auth/yt-analytics.readonly स्कोप के ऐक्सेस का अनुरोध करता है.
  2. अनुरोध किए गए एक या उससे ज़्यादा दायरों का ऐक्सेस देने (या अस्वीकार करने) के बाद, उपयोगकर्ता को ओरिजनल पेज पर रीडायरेक्ट किया जाता है. यह पेज, फ़्रैगमेंट आइडेंटिफ़ायर स्ट्रिंग से ऐक्सेस टोकन को पार्स करता है.
  3. यह पेज, एपीआई के सैंपल का अनुरोध करने के लिए, ऐक्सेस टोकन का इस्तेमाल करता है.

    यह एपीआई अनुरोध, YouTube Analytics API के reports.query तरीके को कॉल करता है, ताकि अनुमति वाले उपयोगकर्ता के YouTube चैनल पर व्यू की संख्या वापस पाई जा सके.

  4. अनुरोध लागू होने पर, एपीआई से मिला रिस्पॉन्स, ब्राउज़र के डीबग कंसोल में लॉग कर दिया जाता है.

अपने Google खाते के लिए अनुमतियां पेज पर जाकर, ऐप्लिकेशन का ऐक्सेस वापस लिया जा सकता है. ऐप्लिकेशन को Google API Docs के लिए OAuth 2.0 Demo के तौर पर सूची में शामिल किया जाएगा.

इस कोड को स्थानीय तौर पर चलाने के लिए, आपको YOUR_CLIENT_ID और YOUR_REDIRECT_URI वैरिएबल के लिए वैल्यू सेट करनी होंगी, जो आपके ऑथराइज़ेशन क्रेडेंशियल से मेल खाती हों. YOUR_REDIRECT_URI वैरिएबल उसी यूआरएल पर सेट होना चाहिए जिस पर पेज दिखाया जा रहा है. यह वैल्यू, API Console Credentials pageमें कॉन्फ़िगर किए गए OAuth 2.0 क्लाइंट के लिए, अनुमति वाले किसी एक आधिकारिक रीडायरेक्ट यूआरआई से पूरी तरह मेल खानी चाहिए. अगर यह वैल्यू, अनुमति वाले यूआरआई से मेल नहीं खाती है, तो आपको redirect_uri_mismatch गड़बड़ी मिलेगी. आपके प्रोजेक्ट में, इस अनुरोध के लिए सही एपीआई चालू होना भी चाहिए.

<html><head></head><body>
<script>
  var YOUR_CLIENT_ID = 'REPLACE_THIS_VALUE';
  var YOUR_REDIRECT_URI = 'REPLACE_THIS_VALUE';
  var fragmentString = location.hash.substring(1);

  // Parse query string to see if page request is coming from OAuth 2.0 server.
  var params = {};
  var regex = /([^&=]+)=([^&]*)/g, m;
  while (m = regex.exec(fragmentString)) {
    params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
  }
  if (Object.keys(params).length > 0) {
    localStorage.setItem('oauth2-test-params', JSON.stringify(params) );
    if (params['state'] && params['state'] == 'try_sample_request') {
      trySampleRequest();
    }
  }

  // If there's an access token, try an API request.
  // Otherwise, start OAuth 2.0 flow.
  function trySampleRequest() {
    var params = JSON.parse(localStorage.getItem('oauth2-test-params'));
    if (params && params['access_token']) {
      var xhr = new XMLHttpRequest();
      xhr.open('GET',
          'https://www.googleapis.com/youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views&' +
          'access_token=' + params['access_token']);
      xhr.onreadystatechange = function (e) {
        if (xhr.readyState === 4 && xhr.status === 200) {
          console.log(xhr.response);
        } else if (xhr.readyState === 4 && xhr.status === 401) {
          // Token invalid, so prompt for user permission.
          oauth2SignIn();
        }
      };
      xhr.send(null);
    } else {
      oauth2SignIn();
    }
  }

  /*
   * Create form to request access token from Google's OAuth 2.0 server.
   */
  function oauth2SignIn() {
    // Google's OAuth 2.0 endpoint for requesting an access token
    var oauth2Endpoint = 'https://accounts.google.com/o/oauth2/v2/auth';

    // Create element to open OAuth 2.0 endpoint in new window.
    var form = document.createElement('form');
    form.setAttribute('method', 'GET'); // Send as a GET request.
    form.setAttribute('action', oauth2Endpoint);

    // Parameters to pass to OAuth 2.0 endpoint.
    var params = {'client_id': YOUR_CLIENT_ID,
                  'redirect_uri': YOUR_REDIRECT_URI,
                  'scope': 'https://www.googleapis.com/auth/yt-analytics.readonly',
                  'state': 'try_sample_request',
                  'include_granted_scopes': 'true',
                  'response_type': 'token'};

    // Add form parameters as hidden input values.
    for (var p in params) {
      var input = document.createElement('input');
      input.setAttribute('type', 'hidden');
      input.setAttribute('name', p);
      input.setAttribute('value', params[p]);
      form.appendChild(input);
    }

    // Add form to page and submit it to open the OAuth 2.0 endpoint.
    document.body.appendChild(form);
    form.submit();
  }
</script>

<button onclick="trySampleRequest();">Try sample request</button>
</body></html>

JavaScript के ऑरिजिन की पुष्टि करने के नियम

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

सत्यापन नियम
स्कीम

JavaScript के ऑरिजिन को एचटीटीपीएस स्कीम का इस्तेमाल करना चाहिए, न कि सामान्य एचटीटीपी का. लोकल होस्ट यूआरआई (इसमें लोकल होस्ट के आईपी पते के यूआरआई शामिल हैं) पर यह नियम लागू नहीं होता.

होस्ट

होस्ट, रॉ आईपी पते नहीं हो सकते. Localhost के आईपी पतों को यह नियम लागू करने की ज़रूरत नहीं है.

डोमेन
  • होस्ट टीएलडी (टॉप लेवल डोमेन) सार्वजनिक सफ़िक्स सूची से जुड़े होने चाहिए.
  • होस्ट डोमेन “googleusercontent.com” नहीं हो सकते.
  • जब तक ऐप्लिकेशन के पास डोमेन का मालिकाना हक न हो, तब तक JavaScript ऑरिजिन में यूआरएल छोटा करने वाले डोमेन (जैसे, goo.gl) शामिल नहीं हो सकते.
  • उपयोगकर्ता की जानकारी

    JavaScript के ऑरिजिन में, userinfo सबकॉम्पोनेंट शामिल नहीं हो सकता.

    पाथ

    JavaScript के ऑरिजिन में, पाथ कॉम्पोनेंट शामिल नहीं किया जा सकता.

    क्वेरी

    JavaScript के ऑरिजिन में, क्वेरी कॉम्पोनेंट शामिल नहीं किया जा सकता.

    फ़्रैगमेंट

    JavaScript के ऑरिजिन में, फ़्रैगमेंट कॉम्पोनेंट शामिल नहीं हो सकता.

    वर्ण JavaScript के ऑरिजिन में कुछ वर्ण नहीं हो सकते. जैसे:
    • वाइल्डकार्ड वर्ण ('*')
    • प्रिंट न किए जा सकने वाले ASCII वर्ण
    • अमान्य प्रतिशत एन्कोडिंग (कोई भी प्रतिशत एन्कोडिंग जो प्रतिशत चिह्न के यूआरएल-एन्कोडिंग फ़ॉर्म के बाद दो हेक्साडेसिमल अंकों का पालन नहीं करती)
    • शून्य वर्ण (एनकोड किया गया NULL वर्ण, उदाहरण के लिए, %00, %C0%80)

    इंक्रीमेंटल अनुमति

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

    उदाहरण के लिए, मान लें कि किसी ऐप्लिकेशन को YouTube Analytics की रिपोर्ट मिलती हैं. इनमें से कुछ रिपोर्ट, पैसों से जुड़ी रिपोर्ट होती हैं. इन्हें ऐक्सेस करने के लिए, ऐसे अतिरिक्त दायरे की ज़रूरत होती है जिसकी दूसरी रिपोर्ट की ज़रूरत नहीं होती. इस मामले में, साइन इन करते समय ऐप्लिकेशन, सिर्फ़ https://www.googleapis.com/auth/yt-analytics.readonly के स्कोप का ऐक्सेस मांग सकता है. हालांकि, अगर उपयोगकर्ता ने पैसों की रिपोर्ट को वापस पाने की कोशिश की, तो ऐप्लिकेशन https://www.googleapis.com/auth/yt-analytics-monetary.readonly के दायरे के ऐक्सेस का अनुरोध भी कर सकता है.

    इंक्रीमेंटल अनुमति से मिलने वाले ऐक्सेस टोकन पर ये नियम लागू होते हैं:

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

    नीचे दिए गए कोड सैंपल, मौजूदा ऐक्सेस टोकन में स्कोप जोड़ने का तरीका दिखाते हैं. इस तरीके से, आपका ऐप्लिकेशन कई ऐक्सेस टोकन को मैनेज करने से बच सकता है.

    OAuth 2.0 एंडपॉइंट

    इस उदाहरण में, कॉल करने के लिए ऐप्लिकेशन, उपयोगकर्ता के YouTube Analytics के डेटा को ऐक्सेस करने का अनुरोध करता है. इसके अलावा, उपयोगकर्ता ने ऐप्लिकेशन को पहले से जो ऐक्सेस भी दिया है उसे ऐक्सेस करने का अनुरोध भी किया जाता है.

    किसी मौजूदा ऐक्सेस टोकन में स्कोप जोड़ने के लिए, Google के OAuth 2.0 सर्वर पर अनुरोध में include_granted_scopes पैरामीटर शामिल करें.

    नीचे दिए गए कोड स्निपेट में बताया गया है कि ऐसा कैसे किया जा सकता है. स्निपेट यह मानता है कि आपने वे स्कोप सेव किए हैं जिनके लिए आपका ऐक्सेस टोकन, ब्राउज़र के लोकल स्टोरेज में मान्य है. (इस सभी उदाहरण में दिए गए कोड में, उन दायरों की एक सूची सेव की जाती है जिनके लिए ऐक्सेस टोकन मान्य है. इसके लिए, ब्राउज़र के लोकल स्टोरेज में oauth2-test-params.scope प्रॉपर्टी को सेट किया जाता है.

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

    var SCOPE = 'https://www.googleapis.com/auth/yt-analytics.readonly';
    var params = JSON.parse(localStorage.getItem('oauth2-test-params'));
    
    var current_scope_granted = false;
    if (params.hasOwnProperty('scope')) {
      var scopes = params['scope'].split(' ');
      for (var s = 0; s < scopes.length; s++) {
        if (SCOPE == scopes[s]) {
          current_scope_granted = true;
        }
      }
    }
    
    if (!current_scope_granted) {
      oauth2SignIn(); // This function is defined elsewhere in this document.
    } else {
      // Since you already have access, you can proceed with the API request.
    }

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

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

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

    OAuth 2.0 एंडपॉइंट

    प्रोग्राम की मदद से किसी टोकन को रद्द करने के लिए, आपका ऐप्लिकेशन 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, गड़बड़ी कोड के साथ दिखाया जाता है.

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

    function revokeAccess(accessToken) {
      // Google's OAuth 2.0 endpoint for revoking access tokens.
      var revokeTokenEndpoint = 'https://oauth2.googleapis.com/revoke';
    
      // Create <form> element to use to POST data to the OAuth 2.0 endpoint.
      var form = document.createElement('form');
      form.setAttribute('method', 'post');
      form.setAttribute('action', revokeTokenEndpoint);
    
      // Add access token to the form so it is set as value of 'token' parameter.
      // This corresponds to the sample curl request, where the URL is:
      //      https://oauth2.googleapis.com/revoke?token={token}
      var tokenField = document.createElement('input');
      tokenField.setAttribute('type', 'hidden');
      tokenField.setAttribute('name', 'token');
      tokenField.setAttribute('value', accessToken);
      form.appendChild(tokenField);
    
      // Add form to page and submit it to actually revoke the token.
      document.body.appendChild(form);
      form.submit();
    }