विस्तृत अनुमतियों को कैसे मैनेज करें

खास जानकारी

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

अनुमति को कंट्रोल करने की बेहतर सुविधा क्या होती है?

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

जब साइन इन किए बिना इस्तेमाल किए जा सकने वाले एक से ज़्यादा स्कोप का अनुरोध किया जाता है

साइन-इन और बिना साइन-इन वाले स्कोप

जिन ऐप्लिकेशन के लिए साइन-इन और बिना साइन-इन किए ऐक्सेस करने के स्कोप, दोनों का अनुरोध किया जाता है उनके लिए, उपयोगकर्ताओं को सबसे पहले साइन-इन स्कोप (email, profile, और openid) के लिए सहमति पेज दिखता है. जब उपयोगकर्ता अपनी बुनियादी पहचान की जानकारी (नाम, ईमेल पता, और प्रोफ़ाइल फ़ोटो) शेयर करने की सहमति दे देते हैं, तब उन्हें बिना साइन-इन किए ऐक्सेस करने के स्कोप के लिए, अनुमति से जुड़ी सहमति स्क्रीन दिखती है. इस मामले में, ऐप्लिकेशन को यह जांच करनी होगी कि उपयोगकर्ताओं ने किन स्कोप का ऐक्सेस दिया है. साथ ही, यह नहीं माना जा सकता कि उपयोगकर्ताओं ने अनुरोध किए गए सभी स्कोप का ऐक्सेस दिया है. यहां दिए गए उदाहरण में, वेब ऐप्लिकेशन ने साइन-इन के तीनों स्कोप और Google Drive के नॉन-साइन-इन स्कोप का अनुरोध किया है. जब उपयोगकर्ता, साइन-इन के स्कोप के लिए सहमति दे देंगे, तब उन्हें Google Drive की अनुमति के लिए, अनुमतियों की सहमति वाली स्क्रीन दिखेगी:

एक से ज़्यादा ऐसे स्कोप जो साइन इन करने की अनुमति नहीं देते

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

जिन ऐप्लिकेशन को सिर्फ़ साइन-इन स्कोप (email, profile, और openid) की ज़रूरत होती है उनके लिए, अनुमति देने से जुड़ी ज़्यादा जानकारी वाली स्क्रीन लागू नहीं होती. उपयोगकर्ता, साइन-इन करने के पूरे अनुरोध को स्वीकार या अस्वीकार करते हैं. दूसरे शब्दों में कहें, तो अगर ऐप्लिकेशन सिर्फ़ साइन-इन स्कोप (एक, दो या तीनों) का अनुरोध करते हैं, तो अनुमति के लिए सहमति लेने वाली स्क्रीन लागू नहीं होती.

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

यह पता लगाना कि आपके ऐप्लिकेशन पर इसका असर पड़ा है या नहीं

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

यह पता लगाने का तरीका कि आपका ऐप्लिकेशन एक से ज़्यादा स्कोप का इस्तेमाल कर रहा है या नहीं

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

अपने ऐप्लिकेशन कोड की जांच करना

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

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) => {
    ...
  },
});

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'])

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
});

आउटगोइंग नेटवर्क कॉल की जांच करना

नेटवर्क कॉल की जांच करते समय, Google OAuth ऑथराइज़ेशन एंडपॉइंट को भेजे गए अनुरोधों को देखें और scope पैरामीटर की जांच करें.

इन वैल्यू की वजह से, अनुमतियों के लिए सहमति लेने वाली स्क्रीन दिखती है.

• 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

अनुमतियों को ज़्यादा बारीकी से मैनेज करने के सबसे सही तरीके

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

1. Google API सेवाओं की उपयोगकर्ता के डेटा से जुड़ी नीति को पढ़ें और पक्का करें कि आपने इसका पालन किया हो.
2. किसी टास्क के लिए ज़रूरी स्कोप का अनुरोध करें. आपको Google की OAuth 2.0 नीति का पालन करना होगा. इसके तहत, आपको सिर्फ़ उन स्कोप के लिए अनुरोध करना होगा जिनकी आपको ज़रूरत है. आपको साइन-इन के दौरान एक से ज़्यादा स्कोप के लिए अनुरोध नहीं करना चाहिए. हालांकि, अगर आपके ऐप्लिकेशन के मुख्य फ़ंक्शन के लिए ऐसा करना ज़रूरी है, तो किया जा सकता है. कई स्कोप को एक साथ बंडल करने से, खास तौर पर पहली बार ऐप्लिकेशन इस्तेमाल करने वाले उन लोगों को यह समझने में मुश्किल हो सकती है कि इन अनुमतियों की ज़रूरत क्यों है जिन्हें आपके ऐप्लिकेशन की सुविधाओं के बारे में जानकारी नहीं है. इससे उपयोगकर्ताओं को चेतावनी मिल सकती है और वे आपके ऐप्लिकेशन का इस्तेमाल करना बंद कर सकते हैं.
3. अनुमति का अनुरोध करने से पहले, उपयोगकर्ताओं को वजह बताएं. साफ़ तौर पर बताएं कि आपके ऐप्लिकेशन को अनुरोध की गई अनुमति की ज़रूरत क्यों है, उपयोगकर्ता के डेटा का इस्तेमाल किस तरह किया जाएगा, और अनुरोध को स्वीकार करने से उपयोगकर्ता को क्या फ़ायदा मिलेगा. हमारी रिसर्च से पता चलता है कि इन वजहों से, लोगों का भरोसा बढ़ता है और वे ज़्यादा दिलचस्पी दिखाते हैं.
4. जब भी आपका ऐप्लिकेशन स्कोप का अनुरोध करता है, तब इंक्रीमेंटल ऑथराइज़ेशन का इस्तेमाल करें. इससे आपको कई ऐक्सेस टोकन मैनेज नहीं करने पड़ेंगे.
5. देखें कि उपयोगकर्ताओं ने किन स्कोप का ऐक्सेस दिया है. एक साथ कई स्कोप का अनुरोध करने पर, ऐसा हो सकता है कि उपयोगकर्ता आपके ऐप्लिकेशन के अनुरोध किए गए सभी स्कोप की अनुमति न दें. आपके ऐप्लिकेशन को हमेशा यह जांच करनी चाहिए कि उपयोगकर्ता ने किन स्कोप के लिए अनुमति दी है. साथ ही, अगर उपयोगकर्ता किसी स्कोप के लिए अनुमति नहीं देता है, तो उसे उससे जुड़ी सुविधाओं को बंद कर देना चाहिए. Google की OAuth 2.0 नीतियों का पालन करें. ये नीतियां, कई स्कोप के लिए सहमति मैनेज करने से जुड़ी हैं. साथ ही, उपयोगकर्ता से सिर्फ़ तब फिर से सहमति मांगें, जब उन्होंने साफ़ तौर पर यह बता दिया हो कि उन्हें उस सुविधा का इस्तेमाल करना है जिसके लिए स्कोप की ज़रूरत है.

ज़्यादा बारीकी से अनुमतियां मैनेज करने के लिए, अपना ऐप्लिकेशन अपडेट करना

Android ऐप्लिकेशन

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

अगर Google OAuth 2.0 के साथ इंटरैक्ट करने के लिए, Play Services से auth.api.signin SDK का इस्तेमाल किया जाता है, तो ज़रूरी दायरों के सबसे छोटे सेट का अनुरोध करने के लिए, requestPermissions फ़ंक्शन का इस्तेमाल किया जा सकता है. साथ ही, यह देखने के लिए कि अनुमति का अनुरोध करते समय उपयोगकर्ता ने किन दायरों के लिए अनुमति दी थी, hasPermissions फ़ंक्शन का इस्तेमाल किया जा सकता है.

Chrome एक्सटेंशन ऐप्लिकेशन

आपको सबसे सही तरीकों के आधार पर, Google OAuth 2.0 के साथ काम करने के लिए Chrome Identity API का इस्तेमाल करना चाहिए.

यहां दिए गए उदाहरण में, ग्रेन्यूलर अनुमतियों को सही तरीके से मैनेज करने का तरीका बताया गया है.

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"]
  }
}

गलत तरीका

...
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.
            ...
          }
      });
});

सही तरीका

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

अगर Google OAuth 2.0 के साथ इंटरैक्ट करने के लिए, iOS और macOS के लिए Google Sign-In लाइब्रेरी का इस्तेमाल किया जाता है, तो आपको अनुमति से जुड़े दस्तावेज़ की समीक्षा करनी चाहिए.

वेब ऐप्लिकेशन

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

सर्वर-साइड (ऑफ़लाइन) ऐक्सेस

नीचे दिए गए कोड स्निपेट में, NodeJS का एक उदाहरण दिखाया गया है. इसमें साइन इन न करने के दो स्कोप का अनुरोध किया गया है. उपयोगकर्ताओं को अनुमति के लिए सहमति वाली स्क्रीन दिखेगी.

गलत तरीका

...
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);
}

सही तरीका

...
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 लाइब्रेरी का इस्तेमाल करने वाले ऐप्लिकेशन के लिए, आपको अनुमति देने से जुड़े इस दस्तावेज़ को पढ़ना चाहिए.
• ऐसे ऐप्लिकेशन जो Google OAuth 2.0 ऑथराइज़ेशन एंडपॉइंट को सीधे तौर पर कॉल करने के लिए JavaScript का इस्तेमाल करते हैं उन्हें अनुमति से जुड़ी ज़्यादा जानकारी देने वाले इस दस्तावेज़ को पढ़ना चाहिए.

अनुमति को कंट्रोल करने की बेहतर सुविधा के साथ अपडेट किए गए ऐप्लिकेशन को टेस्ट करें

1. आउटलाइन में उन सभी मामलों के बारे में बताएं जिनमें उपयोगकर्ता, अनुमति के अनुरोधों का जवाब दे सकते हैं. साथ ही, यह भी बताएं कि आपके ऐप्लिकेशन से किस तरह के व्यवहार की उम्मीद की जाती है. उदाहरण के लिए, अगर उपयोगकर्ता ने अनुरोध किए गए तीन स्कोप में से सिर्फ़ दो को अनुमति दी है, तो आपके ऐप्लिकेशन को उसी के मुताबिक काम करना चाहिए.
2. अनुमति को कंट्रोल करने की बेहतर सुविधा चालू करके, अपने ऐप्लिकेशन की जांच करें. अनुमति देने के ज़्यादा विकल्प चालू करने के दो तरीके हैं:
   1. अपने ऐप्लिकेशन की OAuth 2.0 सहमति स्क्रीन देखें. इससे यह पता चलेगा कि आपके ऐप्लिकेशन के लिए, ज़्यादा कंट्रोल वाली अनुमतियां पहले से चालू हैं या नहीं. टेस्टिंग के लिए, Google Cloud Console के ज़रिए नया वेब, Android या iOS Google OAuth 2.0 क्लाइंट आईडी भी बनाया जा सकता है. ऐसा इसलिए, क्योंकि इनके लिए अनुमति देने की सुविधा हमेशा चालू रहती है.
   2. Google OAuth ऑथराइज़ेशन एंडपॉइंट को कॉल करते समय, enable_granular_consent पैरामीटर को true पर सेट करें. कुछ एसडीके में, इस पैरामीटर के लिए खास तौर पर सहायता उपलब्ध होती है. अन्य के लिए, दस्तावेज़ देखें और जानें कि इस पैरामीटर और इसकी वैल्यू को मैन्युअल तरीके से कैसे जोड़ा जा सकता है. अगर आपका लागू किया गया तरीका, पैरामीटर जोड़ने की सुविधा के साथ काम नहीं करता है, तो Google Cloud Console के ज़रिए नया वेब, Android या iOS Google OAuth 2.0 क्लाइंट आईडी बनाया जा सकता है. हालांकि, इसका इस्तेमाल सिर्फ़ टेस्टिंग के लिए किया जा सकता है.
3. अपडेट किए गए ऐप्लिकेशन की जांच करते समय, Workspace खाते के बजाय निजी Google खाते (@gmail.com) का इस्तेमाल करें. ऐसा इसलिए है, क्योंकि पूरे डोमेन के लिए अधिकार सौंपने की सुविधा वाले Workspace Enterprise ऐप्लिकेशन या भरोसेमंद के तौर पर मार्क किए गए ऐप्लिकेशन पर, फ़िलहाल अनुमतियों में हुए बदलावों का कोई असर नहीं पड़ता. इसलिए, हो सकता है कि आपके संगठन के Workspace खाते से टेस्टिंग करने पर, सहमति लेने के लिए बनी नई स्क्रीन, उम्मीद के मुताबिक न दिखे.