इस दस्तावेज़ में, JavaScript वेब ऐप्लिकेशन से Google API को ऐक्सेस करने के लिए, OAuth 2.0 ऑथराइज़ेशन को लागू करने का तरीका बताया गया है. OAuth 2.0 की मदद से, उपयोगकर्ता किसी ऐप्लिकेशन के साथ चुनिंदा डेटा शेयर कर सकते हैं. साथ ही, अपने उपयोगकर्ता नाम, पासवर्ड, और अन्य जानकारी को निजी रख सकते हैं. उदाहरण के लिए, कोई ऐप्लिकेशन OAuth 2.0 का इस्तेमाल करके, उपयोगकर्ताओं से उनकी Google Drive में फ़ाइलें सेव करने की अनुमति ले सकता है.
इस OAuth 2.0 फ़्लो को इंप्लिसिट ग्रांट फ़्लो कहा जाता है. यह उन ऐप्लिकेशन के लिए डिज़ाइन किया गया है जो एपीआई को सिर्फ़ तब ऐक्सेस करते हैं, जब उपयोगकर्ता ऐप्लिकेशन पर मौजूद होता है. ये ऐप्लिकेशन, गोपनीय जानकारी सेव नहीं कर सकते.
इस फ़्लो में, आपका ऐप्लिकेशन एक Google यूआरएल खोलता है. यह यूआरएल, क्वेरी पैरामीटर का इस्तेमाल करके आपके ऐप्लिकेशन और उसे ज़रूरी एपीआई ऐक्सेस के टाइप की पहचान करता है. यूआरएल को मौजूदा ब्राउज़र विंडो या डायलॉग बॉक्स में खोला जा सकता है. उपयोगकर्ता, Google से पुष्टि कर सकता है और मांगी गई अनुमतियां दे सकता है. इसके बाद, Google उपयोगकर्ता को आपके ऐप्लिकेशन पर वापस रीडायरेक्ट करता है. रीडायरेक्ट में एक ऐक्सेस टोकन शामिल होता है. आपका ऐप्लिकेशन इसकी पुष्टि करता है और फिर एपीआई अनुरोध करने के लिए इसका इस्तेमाल करता है.
Google APIs क्लाइंट लाइब्रेरी और Google Identity Services
अगर Google को अनुमति वाले कॉल करने के लिए, JavaScript के लिए Google API क्लाइंट लाइब्रेरी का इस्तेमाल किया जाता है, तो आपको अनुमति देने के फ़्लो को मैनेज करने के लिए, Google Identity Services JavaScript लाइब्रेरी का इस्तेमाल करना चाहिए. हमारा सुझाव है कि आप Google Identity Services के कोड मॉडल का इस्तेमाल करें. यह मॉडल, PKCE के साथ ऑथराइज़ेशन कोड फ़्लो पर आधारित है, जो कि ज़्यादा सुरक्षित है.
ज़रूरी शर्तें
अपने प्रोजेक्ट के लिए एपीआई चालू करना
Google API को कॉल करने वाले किसी भी ऐप्लिकेशन को, API Console में उन एपीआई को चालू करना होगा.
अपने प्रोजेक्ट के लिए कोई एपीआई चालू करने के लिए:
- Google API Console में एपीआई लाइब्रेरी खोलें.
- अगर कहा जाए, तो कोई प्रोजेक्ट चुनें या नया प्रोजेक्ट बनाएं.
- एपीआई लाइब्रेरी में, उपलब्ध सभी एपीआई की सूची होती है. इन्हें प्रॉडक्ट फ़ैमिली और लोकप्रियता के हिसाब से ग्रुप में बांटा जाता है. अगर आपको सूची में वह एपीआई नहीं दिख रहा है जिसे आपको चालू करना है, तो उसे ढूंढने के लिए खोज सुविधा का इस्तेमाल करें. इसके अलावा, उस प्रॉडक्ट फ़ैमिली में सभी देखें पर क्लिक करें जिससे वह एपीआई जुड़ा है.
- आपको जो एपीआई चालू करना है उसे चुनें. इसके बाद, चालू करें बटन पर क्लिक करें.
- अगर कहा जाए, तो बिलिंग की सुविधा चालू करें.
- अगर कहा जाए, तो एपीआई की सेवा की शर्तें पढ़ें और उन्हें स्वीकार करें.
अनुमति देने के लिए क्रेडेंशियल बनाना
Google API को ऐक्सेस करने के लिए, OAuth 2.0 का इस्तेमाल करने वाले हर ऐप्लिकेशन के पास अनुमति देने वाले क्रेडेंशियल होने चाहिए. इनसे Google के OAuth 2.0 सर्वर को ऐप्लिकेशन की पहचान करने में मदद मिलती है. यहां अपने प्रोजेक्ट के लिए क्रेडेंशियल बनाने का तरीका बताया गया है. इसके बाद, आपके ऐप्लिकेशन उन एपीआई को ऐक्सेस करने के लिए क्रेडेंशियल का इस्तेमाल कर सकते हैं जिन्हें आपने उस प्रोजेक्ट के लिए चालू किया है.
- क्लाइंट पेज पर जाएं.
- क्लाइंट बनाएं पर क्लिक करें.
- ऐप्लिकेशन टाइप के तौर पर, वेब ऐप्लिकेशन चुनें.
- फ़ॉर्म भरें. 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 एंडपॉइंट
https://accounts.google.com/o/oauth2/v2/auth पर Google के OAuth 2.0 एंडपॉइंट से ऐक्सेस का अनुरोध करने के लिए, एक यूआरएल जनरेट करें. इस एंडपॉइंट को एचटीटीपीएस का इस्तेमाल करके ऐक्सेस किया जा सकता है.
एचटीटीपी कनेक्शन को अस्वीकार कर दिया जाता है.
Google का ऑथराइज़ेशन सर्वर, वेब सर्वर ऐप्लिकेशन के लिए इन क्वेरी स्ट्रिंग पैरामीटर के साथ काम करता है:
| पैरामीटर | |||||||
|---|---|---|---|---|---|---|---|
client_id |
ज़रूरी है
आपके ऐप्लिकेशन का क्लाइंट आईडी. यह वैल्यू, Cloud Console के क्लाइंट पेज में देखी जा सकती है. |
||||||
redirect_uri |
ज़रूरी है
इससे यह तय होता है कि अनुमति देने की प्रोसेस पूरी होने के बाद, एपीआई सर्वर उपयोगकर्ता को कहां रीडायरेक्ट करेगा. यह वैल्यू, OAuth 2.0 क्लाइंट के लिए अनुमति वाले किसी एक रीडायरेक्ट यूआरआई से पूरी तरह मेल खानी चाहिए. इसे आपने अपने क्लाइंट के Cloud Console क्लाइंट पेज पर कॉन्फ़िगर किया है. अगर यह वैल्यू, दिए गए ध्यान दें कि |
||||||
response_type |
ज़रूरी है
JavaScript ऐप्लिकेशन को पैरामीटर की वैल्यू |
||||||
scope |
ज़रूरी है
स्कोप की ऐसी सूची जिसमें हर स्कोप को स्पेस से अलग किया गया हो. इससे उन संसाधनों की पहचान की जाती है जिन्हें आपका ऐप्लिकेशन, उपयोगकर्ता की ओर से ऐक्सेस कर सकता है. इन वैल्यू से, सहमति वाली स्क्रीन को जानकारी मिलती है. Google इस स्क्रीन को उपयोगकर्ता को दिखाता है. स्कोप की मदद से, आपका ऐप्लिकेशन सिर्फ़ उन संसाधनों को ऐक्सेस करने का अनुरोध कर सकता है जिनकी उसे ज़रूरत है. साथ ही, उपयोगकर्ता यह कंट्रोल कर सकते हैं कि वे आपके ऐप्लिकेशन को कितना ऐक्सेस दें. इसलिए, अनुरोध किए गए स्कोप की संख्या और उपयोगकर्ता की सहमति मिलने की संभावना के बीच, इन्वर्स रिलेशनशिप होता है. हमारा सुझाव है कि जब भी संभव हो, आपका ऐप्लिकेशन संदर्भ के हिसाब से अनुमति के स्कोप का ऐक्सेस मांगे. इंक्रीमेंटल ऑथराइज़ेशन का इस्तेमाल करके, उपयोगकर्ता के डेटा को ऐक्सेस करने का अनुरोध करने पर, उपयोगकर्ताओं को यह समझने में मदद मिलती है कि आपके ऐप्लिकेशन को ऐक्सेस की ज़रूरत क्यों है. |
||||||
state |
सुझाया गया
यह किसी ऐसी स्ट्रिंग वैल्यू के बारे में बताता है जिसका इस्तेमाल आपका ऐप्लिकेशन, अनुमति के अनुरोध और अनुमति देने वाले सर्वर के जवाब के बीच की स्थिति को बनाए रखने के लिए करता है.
जब उपयोगकर्ता आपके ऐप्लिकेशन के ऐक्सेस के अनुरोध को स्वीकार या अस्वीकार करता है, तो सर्वर वही वैल्यू दिखाता है जो आपने इस पैरामीटर का इस्तेमाल कई कामों के लिए किया जा सकता है. जैसे, उपयोगकर्ता को आपके ऐप्लिकेशन में सही संसाधन पर भेजना, नॉन्स भेजना, और किसी दूसरी साइट से किए गए फ़र्ज़ी अनुरोध को कम करना. आपके |
||||||
include_granted_scopes |
ज़रूरी नहीं
इससे ऐप्लिकेशन, ज़रूरत के मुताबिक ज़्यादा स्कोप का ऐक्सेस पाने के लिए, इंक्रीमेंटल ऑथराइज़ेशन का इस्तेमाल कर सकते हैं. अगर इस पैरामीटर की वैल्यू को |
||||||
enable_granular_consent |
ज़रूरी नहीं
डिफ़ॉल्ट रूप से, यह जब Google किसी ऐप्लिकेशन के लिए, अलग-अलग अनुमतियां चालू करता है, तो इस पैरामीटर का कोई असर नहीं होगा. |
||||||
login_hint |
ज़रूरी नहीं
अगर आपके ऐप्लिकेशन को पता है कि कौनसा उपयोगकर्ता पुष्टि करने की कोशिश कर रहा है, तो वह इस पैरामीटर का इस्तेमाल करके, Google के ऑथेंटिकेशन सर्वर को हिंट दे सकता है. सर्वर, लॉगिन की प्रोसेस को आसान बनाने के लिए हिंट का इस्तेमाल करता है. इसके लिए, वह साइन-इन फ़ॉर्म में ईमेल फ़ील्ड को पहले से भर देता है या सही मल्टी-लॉगिन सेशन चुनता है. पैरामीटर वैल्यू को किसी ईमेल पते या |
||||||
prompt |
ज़रूरी नहीं
उपयोगकर्ता को दिखाने के लिए, स्पेस से अलग किए गए और केस-सेंसिटिव (बड़े और छोटे अक्षरों में अंतर) प्रॉम्प्ट की सूची. अगर आपने यह पैरामीटर तय नहीं किया है, तो उपयोगकर्ता को सिर्फ़ तब सूचना दी जाएगी, जब आपका प्रोजेक्ट पहली बार ऐक्सेस का अनुरोध करेगा. ज़्यादा जानकारी के लिए, फिर से सहमति देने के लिए कहना देखें. इन वैल्यू का इस्तेमाल किया जा सकता है:
|
||||||
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//developers.google.com/oauthplayground& 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/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 नीतियों के तहत नहीं है.
iOS और macOS डेवलपर को WKWebView में अनुमति के अनुरोध खोलते समय यह गड़बड़ी दिख सकती है.
इसके बजाय, डेवलपर को iOS लाइब्रेरी का इस्तेमाल करना चाहिए. जैसे, iOS के लिए Google साइन-इन या OpenID Foundation का iOS के लिए AppAuth.
वेब डेवलपर को यह गड़बड़ी तब दिख सकती है, जब कोई 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 ऑरिजिन यूआरआई से मेल नहीं खाता. Google Cloud Console के क्लाइंट पेज पर जाकर, अनुमति वाले JavaScript ऑरिजिन की समीक्षा करें.
redirect_uri_mismatch
अनुमति के अनुरोध में पास किया गया redirect_uri, OAuth क्लाइंट आईडी के लिए अनुमति वाले रीडायरेक्ट यूआरआई से मेल नहीं खाता. Google Cloud Console के क्लाइंट पेज पर जाकर, अनुमति वाले रीडायरेक्ट यूआरआई देखें.
अनुमति पाने का अनुरोध करने वाले JavaScript की स्कीम, डोमेन, और/या पोर्ट, OAuth क्लाइंट आईडी के लिए रजिस्टर किए गए अनुमति वाले JavaScript ऑरिजिन यूआरआई से मेल नहीं खाता. Google Cloud Console के क्लाइंट पेज पर जाकर, अनुमति वाले JavaScript ऑरिजिन की समीक्षा करें.
redirect_uri पैरामीटर, OAuth आउट-ऑफ़-बैंड (ओओबी) फ़्लो को रेफ़र कर सकता है. इसे बंद कर दिया गया है और अब यह काम नहीं करता. अपने इंटिग्रेशन को अपडेट करने के लिए, माइग्रेट करने से जुड़ी गाइड देखें.
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//developers.google.com/oauthplayground& client_id=client_id
OAuth 2.0 फ़्लो पूरा करने के बाद, आपका ब्राउज़र आपको OAuth 2.0 Playground पर रीडायरेक्ट करता है. यह OAuth फ़्लो की जांच करने वाला टूल है. आपको दिखेगा कि OAuth 2.0 Playground ने ऑथराइज़ेशन कोड को अपने-आप कैप्चर कर लिया है.
चौथा चरण: यह देखना कि उपयोगकर्ताओं ने किन दायरों को ऐक्सेस करने की अनुमति दी है
एक से ज़्यादा अनुमतियों (स्कोप) का अनुरोध करने पर, हो सकता है कि उपयोगकर्ता आपके ऐप्लिकेशन को उन सभी अनुमतियों का ऐक्सेस न दें. आपके ऐप्लिकेशन को यह पुष्टि करनी होगी कि उसे असल में कौनसे स्कोप दिए गए हैं. साथ ही, उसे उन स्थितियों को भी बेहतर तरीके से मैनेज करना होगा जिनमें कुछ अनुमतियां नहीं दी गई हैं. आम तौर पर, ऐसा उन सुविधाओं को बंद करके किया जाता है जो अनुमति न दिए गए स्कोप पर निर्भर करती हैं.
हालांकि, इसके कुछ अपवाद हैं. Google Workspace Enterprise के ऐसे ऐप्लिकेशन जिनके पास डोमेन-वाइड डेलिगेशन ऑफ़ अथॉरिटी है या जिन्हें भरोसेमंद के तौर पर मार्क किया गया है वे अलग-अलग अनुमतियों के लिए सहमति देने वाली स्क्रीन को बायपास कर देते हैं. इन ऐप्लिकेशन के लिए, उपयोगकर्ताओं को अलग-अलग अनुमतियों के लिए सहमति देने वाली स्क्रीन नहीं दिखेगी. इसके बजाय, आपके ऐप्लिकेशन को अनुरोध किए गए सभी स्कोप का ऐक्सेस मिलेगा या किसी का भी नहीं.
ज़्यादा जानकारी के लिए, अलग-अलग अनुमतियों को मैनेज करने का तरीका देखें.
OAuth 2.0 एंडपॉइंट
यह देखने के लिए कि उपयोगकर्ता ने आपके ऐप्लिकेशन को किसी खास दायरे का ऐक्सेस दिया है या नहीं, ऐक्सेस टोकन के जवाब में scope फ़ील्ड की जांच करें. access_token से दिए गए ऐक्सेस के स्कोप, स्पेस-डिलिमिटेड और केस-सेंसिटिव स्ट्रिंग की सूची के तौर पर दिखाए जाते हैं.
उदाहरण के लिए, ऐक्सेस टोकन के जवाब के इस सैंपल से पता चलता है कि उपयोगकर्ता ने आपके ऐप्लिकेशन को, Drive में की गई गतिविधि और कैलेंडर इवेंट को सिर्फ़ पढ़ने की अनुमति दी है:
{ "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 फ़्लो के लिए, पेज इन चरणों का पालन करता है:
- यह उपयोगकर्ता को 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 खाते के अनुमतियां पेज पर जाकर, ऐप्लिकेशन का ऐक्सेस वापस लिया जा सकता है. ऐप्लिकेशन को उस नाम से लिस्ट किया जाता है जो क्लाइंट आईडी बनाते समय, OAuth के लिए सहमति देने वाली स्क्रीन पर ब्रैंडिंग पेज में दिया गया था.
इस कोड को स्थानीय तौर पर चलाने के लिए, आपको YOUR_CLIENT_ID और YOUR_REDIRECT_URI वैरिएबल के लिए वैल्यू सेट करनी होंगी. ये वैल्यू, आपके अनुमति देने वाले क्रेडेंशियल से मेल खानी चाहिए. YOUR_REDIRECT_URI वैरिएबल को उसी यूआरएल पर सेट किया जाना चाहिए जहां पेज दिखाया जा रहा है. यह वैल्यू, OAuth 2.0 क्लाइंट के लिए अनुमति वाले किसी एक रीडायरेक्ट यूआरआई से पूरी तरह मेल खानी चाहिए. इसे आपने Cloud Console के क्लाइंट पेज पर कॉन्फ़िगर किया है. अगर यह वैल्यू, अनुमति वाले यूआरआई से मैच नहीं होती है, तो आपको 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 आईपी पतों को इस नियम से छूट दी गई है. |
| डोमेन |
“googleusercontent.com” नहीं हो सकते.goo.gl) शामिल नहीं हो सकते. हालांकि, अगर ऐप्लिकेशन के पास डोमेन का मालिकाना हक है, तो ऐसा किया जा सकता है. |
| Userinfo |
JavaScript ऑरिजिन में, userinfo सब-कॉम्पोनेंट शामिल नहीं हो सकता. |
| पाथ |
JavaScript ऑरिजिन में पाथ कॉम्पोनेंट शामिल नहीं हो सकता. |
| क्वेरी |
JavaScript ऑरिजिन में क्वेरी कॉम्पोनेंट नहीं हो सकता. |
| फ़्रैगमेंट |
JavaScript ऑरिजिन में फ़्रैगमेंट कॉम्पोनेंट नहीं हो सकता. |
| वर्ण |
JavaScript ऑरिजिन में कुछ वर्ण शामिल नहीं किए जा सकते. जैसे:
|
इंक्रीमेंटल ऑथराइज़ेशन
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
सभी खातों की सुरक्षा की सुविधा को लागू करने के तरीके और उपलब्ध इवेंट की पूरी सूची के बारे में ज़्यादा जानने के लिए, सभी खातों की सुरक्षा की सुविधा की मदद से उपयोगकर्ता खातों को सुरक्षित करना पेज देखें.