نحوه مدیریت اجازه‌های جزئی

نمای کلی

با اجازه‌های دانه‌ای، مصرف‌کنندگان کنترل دقیق‌تری بر اینکه کدام داده‌های حساب را برای هم‌رسانی با هر برنامه انتخاب کنند به‌دست می‌آورند. این اجازه‌ها با ارائه کنترل، شفافیت، و امنیت بیشتر، هم برای کاربران و هم برای توسعه‌دهندگان مفید هستند. این راهنما به شما کمک می‌کند تغییرات و مراحل لازم را برای به‌روزرسانی موفقیت‌آمیز برنامه‌هایتان جهت مدیریت اجازه‌های ریزدانه درک کنید.

اجازه جزئی چیست؟

تصور کنید برنامه بهره‌وری‌ای توسعه می‌دهید که هم گستره ایمیل و هم گستره تقویم را درخواست می‌کند. ممکن است کاربران شما بخواهند از برنامه شما فقط برای «تقویم Google» استفاده کنند، اما نه Gmail. با اجازه‌های OAuth دانه‌ای، کاربران می‌توانند انتخاب کنند که فقط اجازه «تقویم Google» را اعطا کنند، نه Gmail. با اجازه دادن به کاربران برای اعطای دسترسی به داده‌های خاص، این ویژگی قرار گرفتن داده‌ها درمعرض دید را به‌حداقل می‌رساند، اعتماد را تقویت می‌کند، و با کنترل متمرکز بر حریم خصوصی بر زندگی دیجیتال، کاربران را توانمند می‌سازد. مهم است که برنامه‌تان را طوری طراحی کنید که بتواند چنین سناریوهایی را مدیریت کند.

وقتی بیش‌از یک گستره غیرورود به سیستم درخواست شود

گستره‌های «ورود به سیستم» و غیر «ورود به سیستم»

برای برنامه‌هایی که هم گستره‌های «ورود به سیستم» و هم گستره‌های غیر «ورود به سیستم» را درخواست می‌کنند، کاربران ابتدا صفحه رضایت را برای گستره‌های «ورود به سیستم» (email، profile، و openid) می‌بینند. پس‌از اینکه کاربران با هم‌رسانی اطلاعات هویتی اصلی خود (نام، نشانی ایمیل، و عکس نمایه) موافقت کردند، صفحه رضایت اجازه دانه‌ای را برای گستره‌های غیر «ورود به سیستم» خواهند دید. در این مورد، برنامه باید بررسی کند که کدام گستره‌ها توسط کاربران اعطا شده است و نمی‌تواند فرض کند که کاربران همه گستره‌های درخواستی را اعطا می‌کنند. در مثال زیر، برنامه وب هر سه گستره «ورود به سیستم» و یک گستره غیر«ورود به سیستم» Google Drive را درخواست می‌کند. پس‌از اینکه کاربران با گستره‌های «ورود به سیستم» موافقت کردند، صفحه رضایت اجازه‌های دانه‌ای را برای اجازه Google Drive خواهند دید:

گستره‌های «ورود به سیستم» و غیر «ورود به سیستم»

بیش‌از یک گستره غیرورود به سیستم

وقتی برنامه‌ها بیش‌از یک محدوده غیرورود به سیستم را درخواست کنند، صفحه رضایت اجازه دانه‌ای به کاربران نشان داده می‌شود. کاربران می‌توانند انتخاب کنند که کدام اجازه‌ها را برای هم‌رسانی با برنامه تأیید کنند. در زیر نمونه‌ای از صفحه رضایت اجازه جزئی را می‌بینید که درخواست دسترسی به پیام‌های Gmail و داده‌های «تقویم Google» کاربر را دارد:

بیش‌از یک گستره غیرورود به سیستم

برای برنامه‌هایی که فقط دامنه‌های ورود به سیستم (email، profile، و openid) را درخواست می‌کنند، صفحه رضایت اجازه‌های ریزدانه قابل‌اجرا نیست. کاربران کل درخواست ورود به سیستم را تأیید یا رد می‌کنند. به‌عبارت دیگر، اگر برنامه‌ها فقط درخواست گستره‌های «ورود به سیستم» (یک، دو، یا هر سه) را داشته باشند، صفحه رضایت اجازه دانه‌ای قابل‌اجرا نیست.

برای برنامه‌هایی که فقط یک گستره غیر«ورود به سیستم» درخواست می‌کنند، صفحه رضایت اجازه دانه‌ای قابل‌اعمال نیست. به‌عبارت دیگر، کاربران کل درخواست را تأیید یا رد می‌کنند و هیچ چارگوش انتخابی در صفحه رضایت وجود ندارد. جدول زیر خلاصه می‌کند که چه زمانی صفحه رضایت اجازه‌های ریزدانه نمایش داده می‌شود.

تعداد دامنه‌های ورود به سیستم تعداد دامنه‌های غیرورود به سیستم صفحه کسب رضایت برای اجازه‌های جزئی
1-3 0 نامربوط
1-3 بیش‌از یک فروشگاه قابل‌اجرا
0 1 نامربوط
0 بیش‌از ۲ بار قابل‌اجرا

مشخص کنید آیا برنامه‌هایتان تحت‌تأثیر قرار گرفته‌اند یا نه

همه بخش‌های برنامه‌تان را که در آن‌ها از نقاط پایانی مجوز Google OAuth 2.0 برای درخواست‌های اجازه استفاده می‌شود به‌طور کامل بررسی کنید. به آن‌هایی که درخواست چندین دامنه می‌کنند توجه کنید، زیرا آن‌ها صفحه‌های رضایت اجازه دانه‌ای را که به کاربران ارائه می‌شود فعال می‌کنند. در چنین مواردی، مطمئن شوید که کد شما می‌تواند شرایطی را که کاربران فقط برخی‌از دامنه‌ها را مجاز می‌کنند مدیریت کند.

چگونه تشخیص دهید که برنامه‌تان از چند دامنه استفاده می‌کند

کد برنامه‌تان یا تماس شبکه خروجی را بررسی کنید تا مشخص شود آیا درخواست‌های مجوز Google OAuth 2.0 که برنامه‌تان ایجاد می‌کند باعث نمایش صفحه رضایت با اجازه‌های ریزدانه می‌شود یا نه.

کد برنامه‌تان را بازرسی کنید

بخش‌هایی از کد برنامه‌تان را که در آن با نقاط پایانی مجوز Google OAuth تماس می‌گیرید تا از کاربران درخواست اجازه کنید مرور کنید. اگر از یکی از «کتابخانه‌های کارخواه Google API» استفاده می‌کنید، اغلب می‌توانید دامنه‌هایی را که برنامه‌تان درخواست می‌کند در مراحل مقداردهی اولیه کارخواه پیدا کنید. چند نمونه در بخش زیر نشان داده شده است. باید به اسناد کیت‌های توسعه نرم‌افزاری که برنامه‌تان برای مدیریت Google OAuth 2.0 استفاده می‌کند مراجعه کنید تا بااستفاده از راهنمایی‌های نشان‌داده‌شده در مثال‌های زیر به‌عنوان مرجع، تعیین کنید که آیا برنامه‌تان تحت‌تأثیر قرار گرفته است یا نه.

سرویس‌های مدیریت هویت Google

تکه‌کد کتابخانه جاوا اسکریپت سرویس‌های هویتی Google زیر 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 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
});

بازرسی تماس شبکه خروجی

روش بازرسی تماس‌های شبکه بسته به نوع برنامه شما متفاوت خواهد بود.

هنگام بازرسی تماس‌های شبکه، درخواست‌های ارسال‌شده به نقطه‌های پایانی مجوز 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 استفاده می‌کنید مشورت کنید و برنامه‌تان را به‌روز کنید تا اجازه‌های ریزدانه را براساس روال‌های مطلوب مدیریت کند.

اگر از کیت توسعه نرم‌افزار auth.api.signin از «خدمات Play» برای تعامل با Google OAuth 2.0 استفاده می‌کنید، می‌توانید از تابع 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 کوچک‌ترین مجموعه دامنه‌های موردنیاز هستند. فایل oauth.js از Chrome Identity API برای شروع فرایند صدور مجوز با Google استفاده می‌کند. باید برای فعال کردن اجازه‌های دانه‌ای موافقت کنید تا کاربران کنترل بیشتری بر اعطای اجازه‌ها به برنامه شما داشته باشند. برنامه شما باید با بررسی اینکه کاربران کدام دامنه‌ها را مجاز می‌کنند، پاسخ کاربران را به‌درستی مدیریت کند.

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 استفاده می‌کنید مشورت کنید و برنامه‌تان را به‌روز کنید تا اجازه‌های ریزدانه را براساس روال‌های مطلوب مدیریت کند.

اگر از کتابخانه ورود به سیستم با Google برای iOS و macOS برای تعامل با Google OAuth 2.0 استفاده می‌کنید، باید مستندات مربوط به مدیریت اجازه‌های ریزدانه را مرور کنید.

برنامه‌های وب

باید با اسناد کیت‌های توسعه نرم‌افزاری که برای تعامل با Google OAuth 2.0 استفاده می‌کنید مشورت کنید و برنامه‌تان را به‌روز کنید تا اجازه‌های ریزدانه را براساس روال‌های مطلوب مدیریت کند.

دسترسی سمت سرور (آفلاین)

حالت دسترسی سمت سرور (آفلاین) مستلزم این است که کارهای زیر را انجام دهید:

  • سروری راه‌اندازی کنید و نقطه پایانی با دسترسی عمومی برای دریافت کد مجوز تعریف کنید.
  • URI هدایت نقطه پایان عمومی‌تان را در صفحه کارخواه‌ها در کنسول Google Cloud پیکربندی کنید.

تکه‌کد زیر نمونه 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 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);
}
رویکرد درست

کوچک‌ترین دامنه

کوچک‌ترین مجموعه از دامنه‌های موردنیاز را انتخاب کنید

برنامه باید فقط کوچک‌ترین مجموعه حوزه‌های موردنیاز را درخواست کند. توصیه می‌شود که برنامه‌تان هر بار که برای تکمیل تکلیفی لازم است، یک گستره درخواست کند. هرگاه برنامه‌تان درخواست گستره می‌کند، باید از مجوز افزایشی استفاده کند تا مجبور نباشد چندین کد دسترسی را مدیریت کند.

اگر برنامه شما باید چندین دامنه غیرورود به سیستم را درخواست کند، همیشه باید هنگام درخواست از مجوز افزایشی استفاده کنید و بررسی کنید که کاربران کدام دامنه‌ها را اعطا کرده‌اند.

در این مثال، فرض بر این است که هر دو گستره ذکرشده برای عملکرد صحیح برنامه لازم است. باید با فعال کردن اجازه‌های جزئی موافقت کنید تا کاربران کنترل بیشتری بر اعطای اجازه‌ها به برنامه شما داشته باشند. برنامه شما باید با بررسی اینکه کاربران کدام گستره‌ها را مجاز کرده‌اند، پاسخ کاربران را به‌درستی مدیریت کند.

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 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 APIs از برنامه‌های مبتنی بر سرور مرور کنید.

دسترسی فقط از سمت کارخواه

  • برای برنامه‌هایی که از کتابخانه جاوا اسکریپت سرویس‌های مدیریت هویت Google برای تعامل با Google OAuth 2.0 استفاده می‌کنند، باید این سند را درباره مدیریت اجازه‌های ریزدانه مرور کنید.
  • برای برنامه‌هایی که مستقیماً بااستفاده از جاوا اسکریپت با نقاط پایانی مجوز Google OAuth 2.0 تماس برقرار می‌کنند، باید این سند را درباره مدیریت اجازه‌های ریزدانه مرور کنید.

برنامه به‌روزشده‌تان را برای مدیریت اجازه‌های جزئی آزمایش کنید

  1. همه مواردی را که کاربران می‌توانند به درخواست‌های اجازه پاسخ دهند و رفتار موردانتظار از برنامه‌تان را به‌طور خلاصه شرح دهید. برای مثال، اگر کاربر فقط دو مورد از سه گستره درخواستی را مجاز کند، برنامه شما باید مطابق با آن رفتار کند.
  2. برنامه‌تان را با فعال کردن اجازه جزئی آزمایش کنید. دو روش برای فعال کردن اجازه‌های جزئی وجود دارد:

    1. صفحه‌های کسب رضایت OAuth 2.0 برنامه‌تان را بررسی کنید تا ببینید آیا اجازه‌های ریزدانه قبلاً برای برنامه‌تان فعال شده است یا نه. همچنین می‌توانید شناسه کارخواه Google OAuth 2.0 جدیدی برای وب، Android، یا iOS ازطریق کنسول Google Cloud برای اهداف آزمایشی ایجاد کنید، زیرا اجازه ریزدانه همیشه برای آن‌ها فعال است.
    2. هنگام فراخوانی نقطه پایانی مجوز Google OAuth، پارامتر enable_granular_consent را روی true تنظیم کنید. برخی‌از کیت‌های توسعه نرم‌افزار به‌طور صریح از این پارامتر پشتیبانی می‌کنند. برای سایر پلاتفرم‌ها، اسناد را بررسی کنید تا ببینید چگونه می‌توانید این پارامتر و مقدار آن را به‌صورت دستی اضافه کنید. اگر پیاده‌سازی شما از افزودن پارامتر پشتیبانی نمی‌کند، می‌توانید شناسه کارخواه Google OAuth 2.0 جدیدی برای وب، Android، یا iOS ازطریق کنسول Google Cloud فقط برای اهداف آزمایشی ایجاد کنید، همان‌طور که در نکته قبلی ذکر شد.

  3. هنگام آزمایش برنامه به‌روزشده، از «حساب Google» شخصی (‎@gmail.com) به‌جای حساب Workspace استفاده کنید. دلیلش این است که برنامه‌های Workspace Enterprise با واگذاری اختیارات در سطح دامنه یا برنامه‌هایی که به‌عنوان مورد اعتماد علامت‌گذاری شده‌اند درحال‌حاضر تحت تأثیر تغییرات اجازه‌های ریزدانه قرار نمی‌گیرند. بنابراین، آزمایش با حساب Workspace از سازمانتان ممکن است صفحه رضایت جزئی جدید را طبق انتظار نشان ندهد.