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

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

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

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

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

Google API क्लाइंट लाइब्रेरी और Google Identity Services

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

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

इस पेज के बाकी हिस्से में, किसी भी OAuth 2.0 लाइब्रेरी का इस्तेमाल किए बिना, Google के OAuth 2.0 एंडपॉइंट के साथ सीधे तौर पर इंटरैक्ट करने का तरीका बताया गया है.

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

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

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

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

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

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

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

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

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

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

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

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 Authorization Server को निर्देश देती है कि वह यूआरआई (#) के फ़्रेगमेंट आइडेंटिफ़ायर में ऐक्सेस टोकन को name=value पेयर के तौर पर दिखाए. इस यूआरआई पर, अनुमति की प्रोसेस पूरी करने के बाद उपयोगकर्ता को रीडायरेक्ट किया जाता है.

scope

ज़रूरी है

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

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

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

state

सुझाया गया

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

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

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

include_granted_scopes

ज़रूरी नहीं

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

enable_granular_consent

ज़रूरी नहीं

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

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

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

`disallowed_useragent`

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

Android

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

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

iOS

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

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

redirect_uri पैरामीटर, OAuth के ऐसे फ़्लो का रेफ़रंस दे सकता है जो अब काम नहीं करता. अपने इंटिग्रेशन को अपडेट करने के लिए, माइग्रेशन गाइड देखें.

`invalid_request`

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

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

तीसरा चरण: OAuth 2.0 सर्वर के जवाब को मैनेज करना

OAuth 2.0 एंडपॉइंट

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

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

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

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

OAuth 2.0 एंडपॉइंट

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

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

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

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

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

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

इस कोड को स्थानीय तौर पर चलाने के लिए, आपको YOUR_CLIENT_ID और YOUR_REDIRECT_URI वैरिएबल के लिए वैल्यू सेट करनी होंगी. ये वैल्यू, आपके अनुमति क्रेडेंशियल से जुड़ी होनी चाहिए. YOUR_REDIRECT_URI वैरिएबल को उसी यूआरएल पर सेट किया जाना चाहिए जहां पेज दिखाया जा रहा है. यह वैल्यू, OAuth 2.0 क्लाइंट के लिए, अनुमति वाले रीडायरेक्ट यूआरआई में से किसी एक से पूरी तरह मेल खानी चाहिए. आपने API Console Credentials pageमें इसे कॉन्फ़िगर किया है. अगर यह वैल्यू, अनुमति वाले यूआरआई से मेल नहीं खाती है, तो आपको 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 ऑरिजिन को एचटीटीपीएस स्कीम का इस्तेमाल करना चाहिए, न कि सादे एचटीटीपी का. localhost यूआरआई (इसमें localhost आईपी पते के यूआरआई भी शामिल हैं) पर यह नियम लागू नहीं होता.
होस्ट	होस्ट के तौर पर रॉ आईपी पते इस्तेमाल नहीं किए जा सकते. localhost आईपी पतों पर यह नियम लागू नहीं होता.
डोमेन	होस्ट के टीएलडी (टॉप लेवल डोमेन), सार्वजनिक सफ़िक्स सूची में शामिल होने चाहिए. होस्ट डोमेन `“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 एंडपॉइंट

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

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

Google की क्रॉस-खाता सुरक्षा सेवा, आपके ऐप्लिकेशन पर इस तरह के इवेंट भेजती है:

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

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

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

Google API क्लाइंट लाइब्रेरी और Google Identity Services

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

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

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

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

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

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

OAuth 2.0 एंडपॉइंट

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

JavaScript का सैंपल कोड

दूसरा चरण: Google, उपयोगकर्ता से सहमति मांगता है

गड़बड़ियां

admin_policy_enforced

disallowed_useragent

Android

iOS

org_internal

invalid_client

invalid_grant

origin_mismatch

redirect_uri_mismatch

invalid_request

तीसरा चरण: OAuth 2.0 सर्वर के जवाब को मैनेज करना

OAuth 2.0 एंडपॉइंट

OAuth 2.0 सर्वर रिस्पॉन्स का सैंपल

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

OAuth 2.0 एंडपॉइंट

Google API को कॉल करना

OAuth 2.0 एंडपॉइंट

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

curl के उदाहरण

JavaScript का सैंपल कोड

पूरा उदाहरण

OAuth 2.0 एंडपॉइंट

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

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

OAuth 2.0 एंडपॉइंट

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

OAuth 2.0 एंडपॉइंट

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

`admin_policy_enforced`

`disallowed_useragent`

`org_internal`

`invalid_client`

`invalid_grant`

`origin_mismatch`

`redirect_uri_mismatch`

`invalid_request`

`curl` के उदाहरण