खास जानकारी
अनुमतियों की मदद से, उपभोक्ताओं को इस बात पर ज़्यादा कंट्रोल मिलता है कि वे हर ऐप्लिकेशन के साथ कौनसा खाता डेटा शेयर करना चाहते हैं. इनसे उपयोगकर्ताओं और डेवलपर, दोनों को ज़्यादा कंट्रोल, पारदर्शिता, और सुरक्षा मिलती है. इस गाइड से, आपको ज़रूरी बदलावों को समझने और अपने ऐप्लिकेशन को अपडेट करने के तरीके को समझने में मदद मिलेगी. इससे, आपको सभी अनुमतियां मैनेज करने में मदद मिलेगी.
विस्तृत अनुमति क्या है?
मान लें कि आपने बेहतर ढंग से काम करने में मदद करने वाला एक ऐसा ऐप्लिकेशन बनाया है जो ईमेल और कैलेंडर, दोनों के लिए अनुरोध करता है. ऐसा हो सकता है कि आपके उपयोगकर्ता आपके ऐप्लिकेशन का इस्तेमाल सिर्फ़ Google Calendar के लिए करना चाहें, Gmail के लिए नहीं. OAuth अनुमतियों के ज़्यादा विकल्प की मदद से, उपयोगकर्ता सिर्फ़ Google Calendar को अनुमति देने का विकल्प चुन सकते हैं, Gmail को नहीं. उपयोगकर्ताओं को किसी खास डेटा का ऐक्सेस देने से, उनका डेटा कम लोगों तक पहुंचता है और उनका भरोसा बढ़ता है. साथ ही, उपयोगकर्ताओं की डिजिटल लाइफ़ को कंट्रोल करने में मदद मिलती है. यह ज़रूरी है कि ऐसी स्थितियों में अपने ऐप्लिकेशन को इस हिसाब से डिज़ाइन किया जाए.
एक से ज़्यादा गैर-साइन-इन दायरों का अनुरोध करने पर
साइन-इन और साइन-इन न करने के दायरे
ऐसे ऐप्लिकेशन जो साइन-इन और गैर-साइन-इन, दोनों दायरों का अनुरोध करते हैं, उनमें उपयोगकर्ताओं को सबसे पहले साइन-इन के दायरों
(email
, profile
, और openid
) के लिए सहमति वाला पेज दिखता है. उपयोगकर्ताओं को
अपनी पहचान की बुनियादी जानकारी (नाम, ईमेल पता, और प्रोफ़ाइल फ़ोटो) शेयर करने की सहमति मिलने के बाद, उपयोगकर्ताओं को
साइन-इन न करने वाले दायरों के लिए, सहमति वाली स्क्रीन दिखेगी. इस मामले में, ऐप्लिकेशन को यह जांच करनी होगी कि उपयोगकर्ताओं ने कौनसे स्कोप दिए हैं. साथ ही, उसे यह नहीं समझना चाहिए कि उपयोगकर्ता अनुरोध किए गए सभी दायरे देते हैं. नीचे दिए गए उदाहरण में, वेब ऐप्लिकेशन साइन-इन के तीनों दायरों और
Google Drive के, बिना साइन इन वाले तीनों स्कोप के लिए अनुरोध करता है. उपयोगकर्ताओं की सहमति के बाद, उपयोगकर्ताओं को Google Drive की अनुमति के लिए,
सामान्य अनुमतियों वाली सहमति वाली स्क्रीन दिखेगी:
![साइन-इन और साइन-इन न करने के दायरे](https://developers-dot-devsite-v2-prod.appspot.com/static/identity/protocols/oauth2/images/examples/identity-and-nonidentity.png?authuser=7&hl=hi)
एक से ज़्यादा गैर-साइन-इन दायरे
जब ऐप्लिकेशन एक से ज़्यादा गैर-साइन-इन दायरों का अनुरोध करेंगे, तो उपयोगकर्ताओं को अनुमति वाली विस्तृत स्क्रीन दिखेगी. उपयोगकर्ता यह चुन सकते हैं कि उन्हें ऐप्लिकेशन के साथ किन अनुमतियों को शेयर करना है. नीचे, अनुमति के लिए विस्तृत अनुमति वाली स्क्रीन का एक उदाहरण दिया गया है. इसमें, उपयोगकर्ता के Gmail मैसेज और Google Calendar का डेटा ऐक्सेस करने का अनुरोध किया गया है:
![एक से ज़्यादा गैर-साइन-इन दायरे](https://developers-dot-devsite-v2-prod.appspot.com/static/identity/protocols/oauth2/images/examples/two-nonidentity.png?authuser=7&hl=hi)
सिर्फ़ साइन-इन
के दायरे (email
, profile
, और openid
) का अनुरोध करने वाले ऐप्लिकेशन के लिए, विस्तृत
अनुमतियों वाली सहमति स्क्रीन लागू नहीं होती. उपयोगकर्ता या तो पूरे साइन इन के अनुरोध को स्वीकार या अस्वीकार करते हैं. दूसरे शब्दों में, अगर ऐप्लिकेशन सिर्फ़ साइन-इन करने के दायरों (एक, दो या तीनों) का अनुरोध करते हैं, तो अनुमति वाली स्क्रीन पर विस्तृत अनुरोध लागू नहीं होता.
उन ऐप्लिकेशन के लिए जो बिना साइन-इन वाले सिर्फ़ एक दायरे का अनुरोध करते हैं, उनके लिए विस्तृत अनुमति वाली सहमति वाली स्क्रीन नहीं लागू होती है. दूसरे शब्दों में, उपयोगकर्ता या तो पूरे अनुरोध को स्वीकार या अस्वीकार करते हैं, और सहमति वाली स्क्रीन में कोई चेकबॉक्स नहीं होता. इस टेबल में, विस्तृत अनुमतियों के लिए सहमति वाली स्क्रीन दिखने पर खास जानकारी दी गई है.
साइन-इन के दायरों की संख्या | साइन-इन न करने वाले दायरों की संख्या | ऐसी स्क्रीन जहां अनुमतियों के लिए सहमति दी जाती है |
---|---|---|
1-3 | 0 | लागू नहीं |
1-3 | 1+ | लागू है |
0 | 1 | लागू नहीं |
0 | दो साल से ज़्यादा उम्र | लागू है |
देखें कि आपके ऐप्लिकेशन पर असर पड़ा है या नहीं
अपने ऐप्लिकेशन के उन सभी सेक्शन की अच्छी तरह से समीक्षा करें जहां अनुमति का अनुरोध करने के लिए, Google OAuth 2.0 के ऑथराइज़ेशन एंडपॉइंट का इस्तेमाल किया जाता है. उन उपयोगकर्ताओं पर ध्यान दें जो एक से ज़्यादा दायरों का अनुरोध करते हैं. ऐसा इसलिए, क्योंकि ये उपयोगकर्ताओं को दिखने वाली अनुमतियों के लिए, सहमति वाली स्क्रीन चालू करते हैं. ऐसे मामलों में, पक्का करें कि आपका कोड उस मामले को हैंडल कर सकता है जहां उपयोगकर्ता सिर्फ़ कुछ स्कोप को अनुमति देते हैं.
कैसे पता लगाएं कि आपका ऐप्लिकेशन एक से ज़्यादा दायरों का इस्तेमाल कर रहा है या नहीं
अपने ऐप्लिकेशन कोड की जांच करें या आउटगोइंग नेटवर्क कॉल की जांच करें, ताकि यह पता चल सके कि आपके ऐप्लिकेशन के Google OAuth 2.0 अनुमति के अनुरोधों की वजह से, विस्तृत अनुमतियों के लिए सहमति वाली स्क्रीन दिखाई जाएगी या नहीं.
अपने ऐप्लिकेशन कोड की जांच करें
अपने ऐप्लिकेशन कोड के उन सेक्शन की समीक्षा करें जहां उपयोगकर्ताओं से अनुमति मांगने के लिए, Google OAuth ऑथराइज़ेशन एंडपॉइंट को कॉल किया जा रहा है. Google API की क्लाइंट लाइब्रेरी में से किसी एक का इस्तेमाल करने पर, क्लाइंट को शुरू करने के चरणों में, आपको अपने ऐप्लिकेशन अनुरोधों के दायरे की जानकारी मिल सकती है. नीचे दिए गए सेक्शन में कुछ उदाहरण दिए गए हैं. आपका ऐप्लिकेशन, Google OAuth 2.0 को मैनेज करने के लिए जिन SDK टूल का इस्तेमाल करता है उनके दस्तावेज़ देखें. इससे आपको यह जानने में मदद मिलेगी कि आपके ऐप्लिकेशन पर कोई असर पड़ा है या नहीं. इसके लिए, इन उदाहरणों में रेफ़रंस के तौर पर दिए गए निर्देश देखें.
Google Identity सेवाएं
यहां दी गई Google Identity Services
JavaScript लाइब्रेरी कोड स्निपेट, TokenClient
को एक से ज़्यादा
ऐसे दायरों से शुरू करता है जिनमें साइन-इन नहीं होता है. जब वेब ऐप्लिकेशन, उपयोगकर्ताओं से अनुमति पाने का अनुरोध करेगा, तब अनुमति के लिए विस्तृत सहमति वाली स्क्रीन दिखेगी.
const client = google.accounts.oauth2.initTokenClient({ client_id: 'YOUR_CLIENT_ID', scope: 'https://www.googleapis.com/auth/calendar.readonly \ https://www.googleapis.com/auth/contacts.readonly', callback: (response) => { ... }, });
Python
नीचे दिया गया कोड स्निपेट, अनुमति देने का अनुरोध बनाने के लिए, google-auth-oauthlib.flow
मॉड्यूल का इस्तेमाल करता है. scope
पैरामीटर में, साइन इन न करने वाले दो स्कोप शामिल हैं. जब वेब ऐप्लिकेशन, उपयोगकर्ताओं से अनुमति का अनुरोध करेगा, तब अनुमति वाली विस्तृत स्क्रीन दिखेगी.
import google.oauth2.credentials import google_auth_oauthlib.flow # Use the client_secret.json file to identify the application requesting # authorization. The client ID (from that file) and access scopes are required. flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file( 'client_secret.json', scopes=['https://www.googleapis.com/auth/calendar.readonly', 'https://www.googleapis.com/auth/contacts.readonly'])
Node.js
यह कोड स्निपेट, google.auth.OAuth2
ऑब्जेक्ट बनाता है. यह अनुमति पाने के अनुरोध में मौजूद पैरामीटर के बारे में बताता है. इसके scope
पैरामीटर में, साइन इन न करने वाले दो दायरे शामिल होते हैं. जब वेब ऐप्लिकेशन, उपयोगकर्ताओं से अनुमति का अनुरोध करता है, तब अनुमति के लिए विस्तृत सहमति वाली स्क्रीन दिखती है.
const {google} = require('googleapis'); /** * To use OAuth2 authentication, we need access to a CLIENT_ID, CLIENT_SECRET, AND REDIRECT_URI * from the client_secret.json file. To get these credentials for your application, visit * https://console.cloud.google.com/apis/credentials. */ const oauth2Client = new google.auth.OAuth2( YOUR_CLIENT_ID, YOUR_CLIENT_SECRET, YOUR_REDIRECT_URL ); // Access scopes for read-only Calendar and Contacts. const scopes = [ 'https://www.googleapis.com/auth/calendar.readonly', 'https://www.googleapis.com/auth/contacts.readonly'] ]; // Generate a url that asks permissions const authorizationUrl = oauth2Client.generateAuthUrl({ // 'online' (default) or 'offline' (gets refresh_token) access_type: 'offline', /** Pass in the scopes array defined above. * Alternatively, if only one scope is needed, you can pass a scope URL as a string */ scope: scopes, // Enable incremental authorization. Recommended as best practices. include_granted_scopes: true });
आउटगोइंग नेटवर्क कॉल की जांच करें
- वेब ऐप्लिकेशन - Chrome पर नेटवर्क गतिविधि की जांच करें
- Android - नेटवर्क इंस्पेक्टर की मदद से, नेटवर्क ट्रैफ़िक की जांच करें
-
Chrome ऐप्लिकेशन
- Chrome एक्सटेंशन पेज पर जाएं
- एक्सटेंशन पेज पर सबसे ऊपर दाएं कोने में मौजूद, डेवलपर मोड चेकबॉक्स को चुनें
- वह एक्सटेंशन चुनें जिसे मॉनिटर करना है
- एक्सटेंशन पेज के व्यू की जांच करें सेक्शन में बैकग्राउंड पेज लिंक पर क्लिक करें
- इसके बाद, एक डेवलपर टूल पॉप-अप खुलेगा. नेटवर्क टैब में जाकर, नेटवर्क ट्रैफ़िक की निगरानी की जा सकती है
- iOS - इंस्ट्रुमेंट की मदद से एचटीटीपी ट्रैफ़िक का विश्लेषण करना
- Universal Windows Platform (UWP) - Visual Studio में नेटवर्क ट्रैफ़िक की जांच करें
- डेस्कटॉप ऐप्लिकेशन - उस ऑपरेटिंग सिस्टम के लिए उपलब्ध नेटवर्क कैप्चर टूल का इस्तेमाल करते हैं जिसके लिए ऐप्लिकेशन को बनाया गया है
नेटवर्क कॉल की जांच करते समय, Google OAuth
ऑथराइज़ेशन एंडपॉइंट को भेजे गए अनुरोध देखें और scope
पैरामीटर की जांच करें.
ये वैल्यू, विस्तृत अनुमतियों की सहमति वाली स्क्रीन cause की वजह से दिखती हैं.
scope
पैरामीटर में, साइन-इन करने के दायरे और बिना साइन-इन वाले दायरे शामिल हैं.नीचे दिए गए सैंपल अनुरोध में, साइन-इन करने के तीनों दायरे और उपयोगकर्ता की Google Drive की फ़ाइलों का मेटाडेटा देखने के लिए, साइन-इन न करने वाला एक स्कोप शामिल है:
https://accounts.google.com/o/oauth2/v2/auth? access_type=offline& scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile%20openid%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive.metadata.readonly& include_granted_scopes=true& response_type=code& redirect_uri=YOUR_REDIRECT_URL& client_id=YOUR_CLIENT_ID
scope
पैरामीटर में, साइन इन न करने वाले एक से ज़्यादा दायरे शामिल हैं.नीचे दिए गए सैंपल अनुरोध में, साइन इन न करने वाले दो दायरे शामिल हैं. इनकी मदद से, उपयोगकर्ता का Google Drive मेटाडेटा देखा जा सकता है और Google Drive की खास फ़ाइलों को मैनेज किया जा सकता है:
https://accounts.google.com/o/oauth2/v2/auth? access_type=offline& scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive.metadata.readonly%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive.file& include_granted_scopes=true& response_type=code& redirect_uri=YOUR_REDIRECT_URL& client_id=YOUR_CLIENT_ID
विस्तृत अनुमतियों को मैनेज करने के सबसे सही तरीके
अगर आप determine कि विस्तृत अनुमतियों को मैनेज करने के लिए आपके ऐप्लिकेशन को अपडेट करना ज़रूरी है, तो आपको अपने कोड में ज़रूरी बदलाव करने चाहिए. इससे, एक से ज़्यादा दायरों के लिए सहमति को सही तरीके से मैनेज किया जा सकेगा. सभी ऐप्लिकेशन को इन सबसे सही तरीकों का पालन करना चाहिए:
- Google API सेवाएं: उपयोगकर्ता के डेटा से जुड़ी नीति देखें और पक्का करें कि उनका पालन किया जा रहा हो.
- किसी टास्क के लिए, ज़रूरी दायरों का अनुरोध करें. आपको Google OAuth 2.0 की उस नीति का पालन करना होगा जिसके लिए सिर्फ़ उन दायरों का अनुरोध करना है जिनकी आपको ज़रूरत है. साइन-इन करते समय, आपको एक से ज़्यादा दायरों का अनुरोध करने से बचना चाहिए. हालांकि, ऐसा तब ही करना चाहिए, जब आपके ऐप्लिकेशन के मुख्य फ़ंक्शन के लिए यह ज़रूरी हो. कई दायरों को एक साथ शामिल करने से, खास तौर पर उन उपयोगकर्ताओं के लिए इन अनुमतियों की ज़रूरत को समझना मुश्किल हो सकता है जिन्हें आपके ऐप्लिकेशन की सुविधाओं के बारे में नहीं पता है. इससे अलार्म बढ़ सकते हैं और लोगों को आपके ऐप्लिकेशन से जुड़ने से रोका जा सकता है.
- अनुमति पाने का अनुरोध करने से पहले, उपयोगकर्ताओं को वजह बताएं. साफ़ तौर पर बताएं कि आपके ऐप्लिकेशन को अनुरोध की गई अनुमति की ज़रूरत क्यों होगी, उपयोगकर्ता के डेटा का क्या किया जाएगा, और अनुरोध स्वीकार करने पर उपयोगकर्ता को क्या फ़ायदा होगा. हमारी रिसर्च से पता चलता है कि इस जानकारी की मदद से, उपयोगकर्ताओं का भरोसा और उनकी दिलचस्पी बढ़ती है.
- जब भी आपका ऐप्लिकेशन, एक से ज़्यादा ऐक्सेस टोकन को मैनेज करने से बचने का अनुरोध करता है, तब ज़्यादा अनुमति का इस्तेमाल करें.
- देखें कि उपयोगकर्ताओं को कौनसे दायरे दिए गए हैं. जब एक साथ कई दायरों का अनुरोध किया जाता है, तब हो सकता है कि उपयोगकर्ता आपके ऐप्लिकेशन के अनुरोधों के लिए, सभी दायरों का अनुरोध न कर पाएं. आपके ऐप्लिकेशन को हमेशा इस बात की जांच करनी चाहिए कि उपयोगकर्ता ने कौनसे स्कोप तय किए हैं. साथ ही, काम की सुविधाओं को बंद करके, दायरे को अस्वीकार किए जाने से जुड़ी समस्याओं को ठीक करें. एक से ज़्यादा दायरों के लिए सहमति मैनेज करने के बारे में, Google OAuth 2.0 की नीतियों का पालन करें. साथ ही, उपयोगकर्ता को सहमति देने के लिए फिर से तब ही अनुरोध करें, जब उसने साफ़ तौर पर किसी ऐसी सुविधा को इस्तेमाल करने का संकेत दिया हो जिसके लिए दायरे की ज़रूरत है.
विस्तृत अनुमतियों को मैनेज करने के लिए अपना ऐप्लिकेशन अपडेट करें
Android ऐप्लिकेशन
आपको Google OAuth 2.0 के साथ इंटरैक्ट करने के लिए इस्तेमाल किए जाने वाले SDK टूल के दस्तावेज़ देखना चाहिए. साथ ही, सबसे सही तरीकों के हिसाब से, ज़्यादा अनुमतियां देने के लिए अपने ऐप्लिकेशन को अपडेट करना चाहिए.
अगर आपने Google OAuth 2.0 के साथ इंटरैक्ट करने के लिए, Play Services के auth.api.signin SDK टूल का इस्तेमाल किया है, तो सबसे छोटे दायरों का अनुरोध करने के लिए, requestPermissions
फ़ंक्शन का इस्तेमाल किया जा सकता है. साथ ही, hasPermissions
फ़ंक्शन का इस्तेमाल जांच करने के लिए किया जा सकता है.
Chrome एक्सटेंशन ऐप्लिकेशन
आपको Chrome Identity API का इस्तेमाल करना चाहिए, ताकि सबसे सही तरीकों के आधार पर, Google OAuth 2.0 के साथ काम किया जा सके.
नीचे दिए गए उदाहरण में, विस्तृत अनुमतियों को सही तरीके से मैनेज करने का तरीका बताया गया है.
manifest.json
उदाहरण की मेनिफ़ेस्ट फ़ाइल में, Chrome एक्सटेंशन ऐप्लिकेशन के लिए साइन इन न करने वाले दो दायरों के बारे में बताया गया है.
{ "name": "Example Chrome extension application", ... "permissions": [ "identity" ], "oauth2" : { "client_id": "YOUR_CLIENT_ID", "scopes":["https://www.googleapis.com/auth/calendar.readonly", "https://www.googleapis.com/auth/contacts.readonly"] } }
गलत तरीका
सभी या कुछ नहीं
अनुमति देने की प्रोसेस शुरू करने के लिए, उपयोगकर्ता बटन पर क्लिक करते हैं. कोड स्निपेट यह मानता है कि
उपयोगकर्ताओं को manifest.json
फ़ाइल में बताए गए दो स्कोप के लिए,
"सभी या कुछ नहीं" वाली सहमति वाली स्क्रीन दिखती है. यह इस बात की जांच नहीं करता कि उपयोगकर्ताओं ने कौनसा दायरा दिया है.
oauth.js
... document.querySelector('button').addEventListener('click', function () { chrome.identity.getAuthToken({ interactive: true }, function (token) { if (token === undefined) { // User didn't authorize both scopes. // Updating the UX and application accordingly ... } else { // User authorized both or one of the scopes. // It neglects to check which scopes users granted and assumes users granted all scopes. // Calling the APIs, etc. ... } }); });
सही तरीका
सबसे छोटे दायरे
ज़रूरी दायरों का सबसे छोटा सेट चुनें
ऐप्लिकेशन को दायरों के सबसे छोटे सेट का ही अनुरोध करना चाहिए. हमारा सुझाव है कि जब भी किसी टास्क को पूरा करने की ज़रूरत हो, तब आपका ऐप्लिकेशन एक बार में एक ही स्कोप का अनुरोध करे.
इस उदाहरण में, यह माना जाता है कि manifest.json
फ़ाइल में बताए गए दोनों स्कोप, स्कोप के सबसे छोटे सेट हैं. Google से अनुमति लेने की प्रक्रिया शुरू करने के लिए, oauth.js
फ़ाइल Chrome Identity API का इस्तेमाल करती है. आपको
पूरी जानकारी वाली अनुमतियां चालू करने के लिए ऑप्ट-इन करना चाहिए, ताकि उपयोगकर्ताओं को आपके ऐप्लिकेशन को
अनुमतियां देने पर बेहतर कंट्रोल मिल सके. आपके ऐप्लिकेशन को उपयोगकर्ताओं के जवाब को सही तरीके से मैनेज करना चाहिए. इसके लिए, वह जांच करता है कि
उपयोगकर्ताओं ने किन दायरों की अनुमति दी है.
oauth.js
... document.querySelector('button').addEventListener('click', function () { chrome.identity.getAuthToken({ interactive: true, enableGranularPermissions: true }, function (token, grantedScopes) { if (token === undefined) { // User didn't authorize any scope. // Updating the UX and application accordingly ... } else { // User authorized the request. Now, check which scopes were granted. if (grantedScopes.includes('https://www.googleapis.com/auth/calendar.readonly')) { // User authorized Calendar read permission. // Calling the APIs, etc. ... } else { // User didn't authorize Calendar read permission. // Update UX and application accordingly ... } if (grantedScopes.includes('https://www.googleapis.com/auth/contacts.readonly')) { // User authorized Contacts read permission. // Calling the APIs, etc. ... } else { // User didn't authorize Contacts read permission. // Update UX and application accordingly ... } } }); });
iOS, iPadOS, और macOS ऐप्लिकेशन
आपको Google OAuth 2.0 के साथ इंटरैक्ट करने के लिए इस्तेमाल किए जाने वाले SDK टूल के दस्तावेज़ देखना चाहिए. साथ ही, सबसे सही तरीकों के हिसाब से, ज़्यादा अनुमतियां देने के लिए अपने ऐप्लिकेशन को अपडेट करना चाहिए.
अगर Google OAuth 2.0 का इस्तेमाल करने के लिए, iOS और macOS लाइब्रेरी का इस्तेमाल किया जाता है, तो आपको हर तरह की अनुमतियों को मैनेज करने के बारे में दिया गया दस्तावेज़ देखना चाहिए.
वेब ऐप्लिकेशन
आपको Google OAuth 2.0 के साथ इंटरैक्ट करने के लिए इस्तेमाल किए जाने वाले SDK टूल के दस्तावेज़ देखना चाहिए. साथ ही, सबसे सही तरीकों के हिसाब से, ज़्यादा अनुमतियां देने के लिए अपने ऐप्लिकेशन को अपडेट करना चाहिए.
सर्वर-साइड (ऑफ़लाइन) ऐक्सेस
- ऑथराइज़ेशन कोड पाने के लिए, सर्वर बनाएं और सार्वजनिक तौर पर ऐक्सेस किया जा सकने वाला एंडपॉइंट तय करें.
- Google Cloud Console के Credentials page में अपने पब्लिक एंडपॉइंट के रीडायरेक्ट यूआरआई को कॉन्फ़िगर करें.
नीचे दिया गया कोड स्निपेट, NodeJS का उदाहरण दिखाता है. यह उदाहरण दो गैर-साइन-इन दायरों का अनुरोध करता है. उपयोगकर्ताओं को अनुमति के लिए विस्तृत सहमति वाली स्क्रीन दिखेगी.
गलत तरीका
सभी या कुछ नहीं
उपयोगकर्ताओं को अनुमति वाले यूआरएल पर रीडायरेक्ट किया जाता है. कोड स्निपेट यह मानता है कि उपयोगकर्ताओं को
scopes
अरैरी में बताए गए दो स्कोप के लिए,
"सभी-या-कुछ नहीं" वाली सहमति वाली स्क्रीन दिखती है. यह इस बात की जांच नहीं करता कि उपयोगकर्ताओं ने कौनसा दायरा दिया है.
main.js
... const oauth2Client = new google.auth.OAuth2( YOUR_CLIENT_ID, YOUR_CLIENT_SECRET, YOUR_REDIRECT_URL ); // Access scopes for two non-Sign-In scopes - Google Calendar and Contacts const scopes = [ 'https://www.googleapis.com/auth/contacts.readonly', 'https://www.googleapis.com/auth/calendar.readonly' ]; // Generate a url that asks permissions for the Google Calendar and Contacts scopes const authorizationUrl = oauth2Client.generateAuthUrl({ // 'online' (default) or 'offline' (gets refresh_token) access_type: 'offline', // Pass in the scopes array defined above scope: scopes, // Enable incremental authorization. Recommended as best practices. include_granted_scopes: true }); async function main() { const server = http.createServer(async function (req, res) { // Example on redirecting user to Google OAuth 2.0 server. if (req.url == '/') { res.writeHead(301, { "Location": authorizationUrl }); } // Receive the callback from Google OAuth 2.0 server. if (req.url.startsWith('/oauth2callback')) { // Handle the Google OAuth 2.0 server response let q = url.parse(req.url, true).query; if (q.error) { // User didn't authorize both scopes. // Updating the UX and application accordingly ... } else { // User authorized both or one of the scopes. // It neglects to check which scopes users granted and assumes users granted all scopes. // Get access and refresh tokens (if access_type is offline) let { tokens } = await oauth2Client.getToken(q.code); // Calling the APIs, etc. ... } } res.end(); }).listen(80); }
सही तरीका
सबसे छोटा स्कोप
ज़रूरी दायरों का सबसे छोटा सेट चुनें
ऐप्लिकेशन को दायरों के सबसे छोटे सेट का ही अनुरोध करना चाहिए. हमारा सुझाव है कि जब भी किसी टास्क को पूरा करने की ज़रूरत हो, तब आपका ऐप्लिकेशन एक बार में एक ही स्कोप का अनुरोध करे. जब भी आपका ऐप्लिकेशन, दायरे के दायरे में आता है, तब उसे कई ऐक्सेस टोकन को मैनेज करने से बचने के लिए, इंक्रीमेंटल अनुमति का इस्तेमाल करना चाहिए.
अगर आपके ऐप्लिकेशन को एक से ज़्यादा गैर-साइन-इन दायरों के लिए अनुरोध करना चाहिए, तो आपको हमेशा इंक्रीमेंटल अनुमति का इस्तेमाल करना चाहिए. यह अनुरोध करते समय और यह पता करना चाहिए कि उपयोगकर्ताओं ने किन दायरों को अनुमति दी है.
इस उदाहरण में, यह माना जाता है कि ऐप्लिकेशन के सही तरीके से काम करने के लिए, बताए गए दोनों दायरों की ज़रूरत है. आपको पूरी जानकारी वाली अनुमतियां चालू करने के लिए ऑप्ट-इन करना चाहिए, ताकि उपयोगकर्ताओं को आपके ऐप्लिकेशन को अनुमतियां देने पर बेहतर कंट्रोल मिल सके. आपके ऐप्लिकेशन को उपयोगकर्ताओं के जवाब को सही तरीके से मैनेज करना चाहिए. इसके लिए, वह जांच के उन दायरों की जांच कर सकता है जिन्हें उपयोगकर्ताओं ने अनुमति दी है.
main.js
... const oauth2Client = new google.auth.OAuth2( YOUR_CLIENT_ID, YOUR_CLIENT_SECRET, YOUR_REDIRECT_URL ); // Access scopes for two non-Sign-In scopes - Google Calendar and Contacts const scopes = [ 'https://www.googleapis.com/auth/contacts.readonly', 'https://www.googleapis.com/auth/calendar.readonly' ]; // Generate a url that asks permissions for the Google Calendar and Contacts scopes const authorizationUrl = oauth2Client.generateAuthUrl({ // 'online' (default) or 'offline' (gets refresh_token) access_type: 'offline', // Pass in the scopes array defined above scope: scopes, // Enable incremental authorization. Recommended as best practices. include_granted_scopes: true, // Set to true to enable more granular permissions for Google OAuth 2.0 client IDs created before 2019. // No effect for newer Google OAuth 2.0 client IDs, since more granular permissions is always enabled for them. enable_granular_consent: true }); async function main() { const server = http.createServer(async function (req, res) { // Redirect users to Google OAuth 2.0 server. if (req.url == '/') { res.writeHead(301, { "Location": authorizationUrl }); } // Receive the callback from Google OAuth 2.0 server. if (req.url.startsWith('/oauth2callback')) { // Handle the Google OAuth 2.0 server response let q = url.parse(req.url, true).query; if (q.error) { // User didn't authorize both scopes. // Updating the UX and application accordingly ... } else { // Get access and refresh tokens (if access_type is offline) let { tokens } = await oauth2Client.getToken(q.code); oauth2Client.setCredentials(tokens); // User authorized the request. Now, check which scopes were granted. if (tokens.scope.includes('https://www.googleapis.com/auth/calendar.readonly')) { // User authorized Calendar read permission. // Calling the APIs, etc. ... } else { // User didn't authorize Calendar read permission. // Calling the APIs, etc. ... } // Check which scopes user granted the permission to application if (tokens.scope.includes('https://www.googleapis.com/auth/contacts.readonly')) { // User authorized Contacts read permission. // Calling the APIs, etc. ... } else { // User didn't authorize Contacts read permission. // Update UX and application accordingly ... } } } res.end(); }).listen(80); }
सर्वर-आधारित ऐप्लिकेशन से Google API को ऐक्सेस करने के तरीके के बारे में जानने के लिए, सर्वर साइड वेब ऐप्लिकेशन गाइड देखें.
केवल क्लाइंट-साइड ऐक्सेस
- Google OAuth 2.0 के साथ इंटरैक्ट करने के लिए, Google Identity Services की JavaScript लाइब्रेरी का इस्तेमाल करने वाले ऐप्लिकेशन को, पूरी जानकारी वाली अनुमतियों को मैनेज करने के बारे में यह दस्तावेज़ देखना चाहिए.
- ऐसे ऐप्लिकेशन जो JavaScript का इस्तेमाल करके सीधे Google OAuth 2.0 के ऑथराइज़ेशन एंडपॉइंट को कॉल करते हैं, उनके लिए आपको पूरी जानकारी की अनुमतियों को मैनेज करने के बारे में यह दस्तावेज़ देखना चाहिए.
विस्तृत अनुमतियों को मैनेज करने के लिए अपने अपडेट किए गए ऐप्लिकेशन की जांच करें
- उपयोगकर्ता, अनुमति के अनुरोधों और आपके ऐप्लिकेशन से होने वाले व्यवहार के आधार पर, उन सभी मामलों को आउटलाइन कर सकते हैं जहां वे जवाब दे सकते हैं. उदाहरण के लिए, अगर उपयोगकर्ता ने अनुरोध किए गए तीन स्कोप में से सिर्फ़ दो के इस्तेमाल की अनुमति दी है, तो आपके ऐप्लिकेशन को उसके मुताबिक काम करना चाहिए.
-
पूरी जानकारी वाली अनुमति के साथ अपने ऐप्लिकेशन की जांच करें. ज़्यादा जानकारी वाली अनुमतियां
चालू करने के दो तरीके हैं:
- अपने ऐप्लिकेशन की OAuth 2.0 सहमति वाली स्क्रीन देखें और पता करें कि आपके ऐप्लिकेशन के लिए, ज़्यादा जानकारी वाली अनुमतियां पहले से चालू हैं या नहीं. टेस्टिंग के लिए, Google Cloud कंसोल से वेब, Android या iOS पर Google OAuth 2.0 क्लाइंट आईडी का इस्तेमाल करके भी नया वेब, Android या iOS Google OAuth 2.0 क्लाइंट आईडी बनाया जा सकता है. ऐसा इसलिए, क्योंकि इन क्लाइंट के लिए अनुमति हमेशा चालू रहती है.
-
Google OAuth
ऑथराइज़ेशन एंडपॉइंट को कॉल करते समय, पैरामीटर
enable_granular_consent
कोtrue
पर सेट करें. कुछ SDK टूल, इस पैरामीटर के साथ साफ़ तौर पर काम करते हैं. अन्य पैरामीटर और इसकी वैल्यू को मैन्युअल तरीके से कैसे जोड़ा जा सकता है, यह जानने के लिए दस्तावेज़ देखें. अगर आपकी लागू की गई प्रोसेस में पैरामीटर जोड़ने की सुविधा काम नहीं करती है, तो जैसा कि पिछले पॉइंट में बताया गया है, Google Cloud Console से इसकी मदद से वेब, Android या iOS पर Google OAuth 2.0 क्लाइंट आईडी बनाया जा सकता है.
- अपडेट किए गए ऐप्लिकेशन की जांच करते समय, Workspace खाते के बजाय निजी Google खाते (@gmail.com) का इस्तेमाल करें. इसकी वजह यह है कि Workspace Enterprise के उन ऐप्लिकेशन पर, फ़िलहाल अनुमतियों में किए जाने वाले बदलावों का कोई असर नहीं पड़ा है जिन्हें पूरे डोमेन के लोगों को अधिकार का ऐक्सेस देना या भरोसेमंद के तौर पर मार्क किया गया है. इसलिए, हो सकता है कि अपने संगठन के Workspace खाते से टेस्ट करने पर, सहमति वाली नई स्क्रीन न दिखे.