क्लाइंट-साइड वेब ऐप्लिकेशन के लिए OAuth 2.0

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

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

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

Google APIs Client Library और Google Identity Services

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

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

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

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

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

  1. Open the API Library में Google API Console.
  2. If prompted, select a project, or create a new one.
  3. API Library में, प्रॉडक्ट फ़ैमिली और लोकप्रियता के हिसाब से ग्रुप किए गए सभी उपलब्ध एपीआई की सूची दी गई है. अगर आपको जिस एपीआई को चालू करना है वह सूची में नहीं दिख रहा है, तो उसे ढूंढने के लिए खोज बार का इस्तेमाल करें. इसके अलावा, उस एपीआई से जुड़े प्रॉडक्ट फ़ैमिली में जाकर, सभी देखें पर क्लिक करें.
  4. वह एपीआई चुनें जिसे आपको चालू करना है. इसके बाद, चालू करें बटन पर क्लिक करें.
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

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

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

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

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

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

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

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

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

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

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

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

OAuth 2.0 एंडपॉइंट

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

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

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

आपके ऐप्लिकेशन का क्लाइंट आईडी. यह वैल्यू आपको में मिलेगी.

redirect_uri ज़रूरी है

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

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

response_type ज़रूरी है

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

scope ज़रूरी है

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

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

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

state सुझाया गया

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

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

include_granted_scopes ज़रूरी नहीं

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

login_hint ज़रूरी नहीं

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

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

prompt ज़रूरी नहीं

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

संभावित वैल्यू ये हैं:

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

Google के अनुमति देने वाले सर्वर पर रीडायरेक्ट करने का उदाहरण

यहां दिए गए उदाहरण में यूआरएल दिखाया गया है. इसे आसानी से पढ़ा जा सके, इसके लिए इसमें लाइन ब्रेक और स्पेस का इस्तेमाल किया गया है.

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly%20https%3A//www.googleapis.com/auth/calendar.readonly&
 include_granted_scopes=true&
 response_type=token&
 state=state_parameter_passthrough_value&
 redirect_uri=https%3A//oauth2.example.com/code&
 client_id=client_id

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

JavaScript का सैंपल कोड

यहां दिए गए JavaScript स्निपेट में, Google APIs Client Library for JavaScript का इस्तेमाल किए बिना, 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/drive.metadata.readonly https://www.googleapis.com/auth/calendar.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 Workspace एडमिन की नीतियों की वजह से, Google खाता अनुरोध किए गए एक या उससे ज़्यादा स्कोप को अनुमति नहीं दे सकता. Google Workspace एडमिन के लिए सहायता लेख यह कंट्रोल करना कि तीसरे पक्ष और आपके डोमेन के मालिकाना हक वाले किन ऐप्लिकेशन की मदद से Google Workspace के डेटा को ऐक्सेस किया जा सकता है पढ़ें. इसमें इस बारे में ज़्यादा जानकारी दी गई है कि एडमिन, सभी स्कोप या संवेदनशील और पाबंदी वाले स्कोप के ऐक्सेस को तब तक सीमित कैसे कर सकता है, जब तक आपके OAuth क्लाइंट आईडी को साफ़ तौर पर ऐक्सेस करने की अनुमति नहीं मिल जाती.

disallowed_useragent

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

Android

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

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

iOS

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

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

org_internal

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

invalid_client

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

deleted_client

अनुरोध करने के लिए इस्तेमाल किए जा रहे OAuth क्लाइंट को मिटा दिया गया है. क्लाइंट को मैन्युअल तरीके से मिटाया जा सकता है. इसके अलावा, इस्तेमाल नहीं किए जा रहे क्लाइंट के मामले में, क्लाइंट अपने-आप मिट जाते हैं. मिटाए गए क्लाइंट को मिटाने के 30 दिनों के अंदर वापस लाया जा सकता है. ज़्यादा जानें .

invalid_grant

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

origin_mismatch

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

redirect_uri_mismatch

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

ऐसा हो सकता है कि अनुमति का अनुरोध करने वाले JavaScript का स्कीम, डोमेन, और/या पोर्ट, OAuth क्लाइंट आईडी के लिए रजिस्टर किए गए, अनुमति वाले JavaScript ऑरिजिन यूआरआई से मेल न खाए. में जाकर, अनुमति वाले 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 में मौजूद फ़ाइलों का मेटाडेटा देखने के लिए, सिर्फ़ पढ़ने का ऐक्सेस और आपके Google Calendar इवेंट देखने के लिए, सिर्फ़ पढ़ने का ऐक्सेस मांगता है:

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly%20https%3A//www.googleapis.com/auth/calendar.readonly&
 include_granted_scopes=true&
 response_type=token&
 state=state_parameter_passthrough_value&
 redirect_uri=https%3A//oauth2.example.com/code&
 client_id=client_id

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

चौथा चरण: देखें कि उपयोगकर्ताओं ने किन स्कोप का ऐक्सेस दिया है

एक से ज़्यादा अनुमतियों (स्कोप) का अनुरोध करने पर, ऐसा हो सकता है कि उपयोगकर्ता आपके ऐप्लिकेशन को उन सभी का ऐक्सेस न दें. आपके ऐप्लिकेशन को यह पुष्टि करनी होगी कि कौनसे स्कोप असल में दिए गए थे. साथ ही, उसे उन स्थितियों को आसानी से मैनेज करना होगा जहां कुछ अनुमतियां अस्वीकार कर दी गई हैं. आम तौर पर, ऐसा उन सुविधाओं को बंद करके किया जाता है जो अस्वीकार किए गए स्कोप पर निर्भर करती हैं.

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

ज़्यादा जानकारी के लिए, अनुमति देने के अलग-अलग विकल्पों को मैनेज करने का तरीका लेख पढ़ें.

OAuth 2.0 एंडपॉइंट

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

उदाहरण के लिए, ऐक्सेस टोकन के जवाब के इस सैंपल से पता चलता है कि उपयोगकर्ता ने आपके ऐप्लिकेशन को Drive गतिविधि और Calendar इवेंट की अनुमतियों को सिर्फ़ पढ़ने का ऐक्सेस दिया है:

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
    "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
  }

Google API को कॉल करना

OAuth 2.0 एंडपॉइंट

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

OAuth 2.0 Playground पर जाकर, Google के सभी एपीआई आज़माए जा सकते हैं. साथ ही, उनके स्कोप देखे जा सकते हैं.

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

Authorization: Bearer एचटीटीपी हेडर का इस्तेमाल करके, drive.files एंडपॉइंट (Drive Files API) को कॉल करने का तरीका यहां दिया गया है. ध्यान दें कि आपको अपना ऐक्सेस टोकन डालना होगा:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

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

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

curl के उदाहरण

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

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

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

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

JavaScript का सैंपल कोड

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

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

var xhr = new XMLHttpRequest();
xhr.open('GET',
    'https://www.googleapis.com/drive/v3/about?fields=user&' +
    'access_token=' + params['access_token']);
xhr.onreadystatechange = function (e) {
  console.log(xhr.response);
};
xhr.send(null);

पूरा उदाहरण

OAuth 2.0 एंडपॉइंट

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

OAuth 2.0 फ़्लो के लिए, पेज इन चरणों का पालन करता है:

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

    एपीआई का अनुरोध, Drive API के about.get तरीके को कॉल करता है, ताकि अनुमति पा चुके उपयोगकर्ता के Google Drive खाते की जानकारी वापस पाई जा सके.

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

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

इस कोड को स्थानीय तौर पर चलाने के लिए, आपको YOUR_CLIENT_ID और YOUR_REDIRECT_URI वैरिएबल के लिए वैल्यू सेट करनी होंगी. ये वैल्यू, आपके अनुमति क्रेडेंशियल से मेल खानी चाहिए. YOUR_REDIRECT_URI वैरिएबल को उस यूआरएल पर सेट किया जाना चाहिए जहां पेज दिखाया जा रहा है. यह वैल्यू, 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';

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

      trySampleRequest();
    } else {
      console.log('State mismatch. Possible CSRF attack');
    }
  }

  // Function to generate a random state value
  function generateCryptoRandomState() {
    const randomValues = new Uint32Array(2);
    window.crypto.getRandomValues(randomValues);

    // Encode as UTF-8
    const utf8Encoder = new TextEncoder();
    const utf8Array = utf8Encoder.encode(
      String.fromCharCode.apply(null, randomValues)
    );

    // Base64 encode the UTF-8 data
    return btoa(String.fromCharCode.apply(null, utf8Array))
      .replace(/\+/g, '-')
      .replace(/\//g, '_')
      .replace(/=+$/, '');
  }

  // 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']) { 
      // User authorized the request. Now, check which scopes were granted.
      if (params['scope'].includes('https://www.googleapis.com/auth/drive.metadata.readonly')) {
        // User authorized read-only Drive activity permission.
        // Calling the APIs, etc.
        var xhr = new XMLHttpRequest();
        xhr.open('GET',
          'https://www.googleapis.com/drive/v3/about?fields=user&' +
          '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 {
        // User didn't authorize read-only Drive activity permission.
        // Update UX and application accordingly
        console.log('User did not authorize read-only Drive activity permission.');
      }

      // Check if user authorized Calendar read permission.
      if (params['scope'].includes('https://www.googleapis.com/auth/calendar.readonly')) {
        // User authorized Calendar read permission.
        // Calling the APIs, etc.
        console.log('User authorized Calendar read permission.');
      }
      else {
        // User didn't authorize Calendar read permission.
        // Update UX and application accordingly
        console.log('User did not authorize Calendar read permission.');
      } 
    } else {
      oauth2SignIn();
    }
  }

  /*
   * Create form to request access token from Google's OAuth 2.0 server.
   */
  function oauth2SignIn() {
    // create random state value and store in local storage
    var state = generateCryptoRandomState();
    localStorage.setItem('state', state);

    // 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/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly',
                  'state': state,
                  '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 ऑरिजिन के लिए, एचटीटीपीएस स्कीम का इस्तेमाल करना ज़रूरी है. सामान्य एचटीटीपी का इस्तेमाल नहीं किया जा सकता. लोकलहोस्ट यूआरआई (इसमें लोकलहोस्ट आईपी पते वाले यूआरआई भी शामिल हैं) को इस नियम से छूट मिली हुई है.

होस्ट

होस्ट, रॉ आईपी पते नहीं हो सकते. लोकलहोस्ट आईपी पतों को इस नियम से छूट मिली हुई है.

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

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

    पाथ

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

    क्वेरी

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

    फ़्रैगमेंट

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

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

    इंक्रीमेंटल ऑथराइज़ेशन

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

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

    इस मामले में, साइन-इन के समय ऐप्लिकेशन, बुनियादी साइन-इन करने के लिए openid और profile स्कोप का अनुरोध कर सकता है. इसके बाद, मिक्स सेव करने के पहले अनुरोध के समय https://www.googleapis.com/auth/drive.file स्कोप का अनुरोध कर सकता है.

    इंक्रीमेंटल ऑथराइज़ेशन से मिले ऐक्सेस टोकन पर ये नियम लागू होते हैं:

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

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

    OAuth 2.0 एंडपॉइंट

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

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

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

    var SCOPE = 'https://www.googleapis.com/auth/drive.metadata.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 APIs क्लाइंट लाइब्रेरी का इस्तेमाल किए बिना, 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();
    }

    'सभी खातों की सुरक्षा' सुविधा लागू करना

    अपने उपयोगकर्ताओं के खातों को सुरक्षित रखने के लिए, आपको एक और कदम उठाना चाहिए. इसके लिए, Google की Cross-Account Protection Service का इस्तेमाल करके, Cross-Account Protection लागू करें. इस सेवा की मदद से, सुरक्षा से जुड़ी घटनाओं की सूचनाएं पाने के लिए सदस्यता ली जा सकती है. इससे आपके ऐप्लिकेशन को, उपयोगकर्ता के खाते में हुए बड़े बदलावों के बारे में जानकारी मिलती है. इसके बाद, इस जानकारी का इस्तेमाल करके कार्रवाई की जा सकती है. यह इस बात पर निर्भर करता है कि आपको इवेंट का जवाब कैसे देना है.

    Google की Cross-Account Protection Service, आपके ऐप्लिकेशन को इस तरह के इवेंट भेजती है:

    • https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
    • https://schemas.openid.net/secevent/oauth/event-type/token-revoked
    • https://schemas.openid.net/secevent/risc/event-type/account-disabled

    सभी खातों की सुरक्षा की सुविधा लागू करने के तरीके और उपलब्ध इवेंट की पूरी सूची के बारे में ज़्यादा जानने के लिए, सभी खातों की सुरक्षा की सुविधा की मदद से उपयोगकर्ता खातों को सुरक्षित रखें पेज देखें.