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

खास जानकारी

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

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

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

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

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

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

साइन-इन के अलावा एक से ज़्यादा स्कोप

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

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

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

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

अपने ऐप्लिकेशन के उन सभी सेक्शन की अच्छी तरह से समीक्षा करें जहां अनुमति के अनुरोधों के लिए, 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 earlier.
    * 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 - इंस्ट्रुमेंट की मदद से एचटीटीपी ट्रैफ़िक का विश्लेषण करना
• डेस्कटॉप ऐप्लिकेशन - उस ऑपरेटिंग सिस्टम के लिए उपलब्ध नेटवर्क कैप्चर टूल का इस्तेमाल करें जिसके लिए ऐप्लिकेशन को डेवलप किया गया था

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

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

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

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

सर्वर-साइड (ऑफ़लाइन) ऐक्सेस मोड के लिए, आपको ये काम करने होंगे:

• एक सर्वर सेट अप करें और ऑथराइज़ेशन कोड पाने के लिए, सार्वजनिक तौर पर ऐक्सेस किया जा सकने वाला एंडपॉइंट तय करें.
• Google Cloud Console के क्लाइंट पेज में जाकर, अपने सार्वजनिक एंडपॉइंट के रीडायरेक्ट यूआरआई को कॉन्फ़िगर करें.

नीचे दिया गया कोड स्निपेट, 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 earlier
  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 the Google authorization server.
    if (req.url == '/') {
      res.writeHead(301, { "Location": authorizationUrl });
    }
    // Receive the callback from the Google authorization server.
    if (req.url.startsWith('/oauth2callback')) {
      // Handle the Google authorization 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 earlier
  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 the Google authorization server.
    if (req.url == '/') {
      res.writeHead(301, { "Location": authorizationUrl });
    }
    // Receive the callback from the Google authorization server.
    if (req.url.startsWith('/oauth2callback')) {
      // Handle the Google authorization 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 खाते से जांच करने पर, हो सकता है कि आपको सहमति देने के लिए नई स्क्रीन न दिखे.