หน้านี้ได้รับการแปลโดย Cloud Translation API

วิธีจัดการสิทธิ์แบบละเอียด

ภาพรวม

สิทธิ์แบบละเอียดช่วยให้ผู้บริโภคควบคุมข้อมูลบัญชีที่ต้องการแชร์กับแต่ละแอปได้อย่างละเอียดยิ่งขึ้น ซึ่งจะเป็นประโยชน์ต่อทั้งผู้ใช้และนักพัฒนาแอปด้วยการควบคุม ความโปร่งใส และความปลอดภัยที่มากขึ้น คู่มือนี้จะช่วยให้คุณเข้าใจถึง การเปลี่ยนแปลงและขั้นตอนในการอัปเดตแอปพลิเคชันของคุณให้สำเร็จในการจัดการสิทธิ์แบบละเอียด

สิทธิ์แบบละเอียดคืออะไร

สมมติว่าคุณพัฒนาแอปเพื่อการทำงานที่ขอขอบเขตทั้งอีเมลและปฏิทิน ผู้ใช้ของคุณ อาจต้องการใช้แอปพลิเคชันของคุณกับ Google ปฏิทินเท่านั้น แต่ไม่ใช้กับ Gmail สิทธิ์ OAuth แบบละเอียดช่วยให้ผู้ใช้เลือกที่จะให้สิทธิ์ Google ปฏิทินเท่านั้น โดยไม่ให้สิทธิ์ Gmail ได้ การให้ผู้ใช้ให้สิทธิ์เข้าถึงข้อมูลที่เฉพาะเจาะจงจะช่วยลดการเปิดเผยข้อมูล ซึ่งเป็นการสนับสนุน เชื่อมั่น และช่วยให้ผู้ใช้ควบคุมชีวิตดิจิทัลของตนได้โดยเน้นความเป็นส่วนตัวเป็นอันดับแรก คุณต้อง ออกแบบแอปพลิเคชันให้รองรับสถานการณ์ดังกล่าวได้

เมื่อมีการขอขอบเขตที่ไม่ใช่การลงชื่อเข้าใช้มากกว่า 1 ขอบเขต

สําหรับแอปพลิเคชันที่ขอทั้งขอบเขตการลงชื่อเข้าใช้และขอบเขตที่ไม่ใช่การลงชื่อเข้าใช้ ผู้ใช้จะเห็นหน้าขอความยินยอมสําหรับขอบเขตการลงชื่อเข้าใช้ (email, profile และ openid) ก่อน หลังจากที่ผู้ใช้ให้ความยินยอมในการแชร์ข้อมูลระบุตัวตนพื้นฐาน (ชื่อ อีเมล และรูปโปรไฟล์) ผู้ใช้จะเห็นหน้าจอขอความยินยอมสิทธิ์แบบละเอียดสําหรับขอบเขตที่ไม่ใช่การลงชื่อเข้าใช้ ในกรณีนี้ แอปพลิเคชันต้องตรวจสอบขอบเขตที่ผู้ใช้ให้สิทธิ์ และไม่สามารถถือว่าผู้ใช้ให้สิทธิ์ขอบเขตทั้งหมดที่ขอ ในตัวอย่างต่อไปนี้ เว็บแอปพลิเคชันจะส่งคำขอขอบเขตการลงชื่อเข้าใช้ทั้ง 3 ขอบเขตและ ขอบเขตที่ไม่มีการลงชื่อเข้าใช้ของ Google ไดรฟ์ หลังจากให้ความยินยอมสําหรับขอบเขตการลงชื่อเข้าใช้แล้ว ผู้ใช้จะเห็นหน้าจอขอความยินยอมสิทธิ์แบบละเอียดสําหรับสิทธิ์ Google ไดรฟ์ ดังนี้

ขอบเขตการลงชื่อเข้าใช้และไม่ได้ลงชื่อเข้าใช้

ระบบจะแสดงหน้าจอขอความยินยอมสิทธิ์แบบละเอียดแก่ผู้ใช้เมื่อแอปพลิเคชันขอเพิ่มเติม ขอบเขตที่ไม่ได้อยู่ในการลงชื่อเข้าใช้ 1 ขอบเขต ผู้ใช้สามารถเลือกสิทธิ์ที่ต้องการอนุมัติเพื่อแชร์ได้ กับแอปพลิเคชัน ต่อไปนี้คือตัวอย่างหน้าจอขอความยินยอมแบบละเอียดที่ขอ สิทธิ์เข้าถึงข้อความ Gmail และข้อมูล Google ปฏิทินของผู้ใช้

ขอบเขตที่ไม่มีการลงชื่อเข้าใช้มากกว่า 1 ขอบเขต

สำหรับแอปพลิเคชันที่ขอเฉพาะการลงชื่อเข้าใช้ ขอบเขต (email, profile และ openid) รายละเอียด หน้าจอยินยอมสิทธิ์ไม่เกี่ยวข้อง ผู้ใช้อนุมัติหรือปฏิเสธการลงชื่อเข้าใช้ทั้งหมด อีกครั้ง กล่าวคือ หากแอปพลิเคชันขอเฉพาะขอบเขตการลงชื่อเข้าใช้ (1, 2 หรือทั้ง 3 รายการ) หน้าจอขอความยินยอมสิทธิ์แบบละเอียดจะใช้ไม่ได้

สําหรับแอปพลิเคชันที่ขอขอบเขตที่ไม่ใช่การลงชื่อเข้าใช้เพียงรายการเดียว หน้าจอขอความยินยอมสิทธิ์แบบละเอียดจะใช้ไม่ได้ กล่าวคือ ผู้ใช้อนุมัติหรือ ปฏิเสธคำขอทั้งหมด และไม่มีช่องทำเครื่องหมายในหน้าจอคำยินยอม ตารางต่อไปนี้สรุปกรณีที่หน้าจอขอความยินยอมสิทธิ์แบบละเอียดจะปรากฏขึ้น

จำนวนขอบเขตการลงชื่อเข้าใช้	จำนวนขอบเขตที่ไม่ได้ลงชื่อเข้าใช้	หน้าจอขอความยินยอมสิทธิ์แบบละเอียด
1-3	0	ไม่เกี่ยวข้อง
1-3	1+	ที่เกี่ยวข้อง
0	1	ไม่เกี่ยวข้อง
0	2+	เกี่ยวข้อง

ตรวจสอบว่าแอปพลิเคชันได้รับผลกระทบหรือไม่

ตรวจสอบส่วนต่างๆ ภายในแอปพลิเคชันอย่างละเอียด ซึ่งใช้ปลายทางการให้สิทธิ์ OAuth 2.0 ของ Google สำหรับคำขอสิทธิ์ โปรดทราบ ผู้ใช้ที่ขอขอบเขตหลายรายการเมื่อเปิดใช้งานหน้าจอขอความยินยอมสิทธิ์แบบละเอียด ที่แสดงให้ผู้ใช้เห็น ในกรณีดังกล่าว โปรดตรวจสอบว่าโค้ดของคุณรองรับกรณีที่ผู้ใช้ ให้สิทธิ์ขอบเขตบางส่วน

วิธีตรวจสอบว่าแอปพลิเคชันของคุณใช้หลายขอบเขตหรือไม่

ตรวจสอบโค้ดแอปหรือการเรียกใช้เครือข่ายขาออกเพื่อดูว่าคำขอการให้สิทธิ์ OAuth 2.0 ของ Google ที่แอปส่งจะทำให้หน้าจอขอความยินยอมสิทธิ์แบบละเอียดแสดงหรือไม่

ตรวจสอบโค้ดของแอปพลิเคชัน

ตรวจสอบส่วนของโค้ดแอปพลิเคชันที่คุณใช้เรียกใช้ OAuth ของ Google ปลายทางการให้สิทธิ์เพื่อขอสิทธิ์จากผู้ใช้ หากคุณใช้ Google API รายการใดรายการหนึ่ง ไลบรารีไคลเอ็นต์ คุณมักจะดูขอบเขตที่แอปพลิเคชันร้องขอในไคลเอ็นต์ได้ ขั้นตอนการเริ่มต้นทำงาน ตัวอย่างมีดังต่อไปนี้ คุณควรดู เกี่ยวกับ SDK ที่แอปพลิเคชันของคุณใช้ในการจัดการกับ Google OAuth 2.0 เพื่อดูว่า แอปพลิเคชันของคุณได้รับผลกระทบ ตามคำแนะนำที่แสดงในตัวอย่างต่อไปนี้ ข้อมูลอ้างอิง

บริการ Google Identity

บริการ Google Identity ต่อไปนี้ ข้อมูลโค้ดไลบรารี 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 มีพารามิเตอร์ที่ไม่ใช่สําหรับการลงชื่อเข้าใช้ 2 รายการ หน้าจอขอความยินยอมสิทธิ์แบบละเอียดจะแสดงเมื่อเว็บแอป ขอสิทธิ์จากผู้ใช้

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 การวิเคราะห์การเข้าชม HTTP ด้วยเครื่องมือ
แพลตฟอร์ม Universal Windows (UWP) - ตรวจสอบการรับส่งข้อมูลในเครือข่ายใน Visual Studio
แอปบนเดสก์ท็อป - ใช้เครื่องมือจับภาพเครือข่าย พร้อมใช้งานสำหรับระบบปฏิบัติการที่แอปพัฒนาขึ้น

ขณะตรวจสอบการเรียกเครือข่าย ให้มองหาคำขอที่ส่งไปยัง OAuth ของ Google ปลายทางการให้สิทธิ์ และตรวจสอบพารามิเตอร์ scope

ค่าเหล่านี้ทำให้หน้าจอความยินยอมสำหรับสิทธิ์แบบละเอียดแสดง

พารามิเตอร์ scope มีขอบเขตการลงชื่อเข้าใช้และขอบเขตที่ไม่ได้ลงชื่อเข้าใช้

ตัวอย่างคำขอต่อไปนี้มีขอบเขตการลงชื่อเข้าใช้ทั้ง 3 ขอบเขต และขอบเขตที่ไม่มีการลงชื่อเข้าใช้ 1 ขอบเขต ในการดูข้อมูลเมตาของไฟล์ Google ไดรฟ์ของผู้ใช้ ให้ทำดังนี้
```
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 มีขอบเขตที่ไม่ใช่การลงชื่อเข้าใช้มากกว่า 1 ขอบเขต

คำขอตัวอย่างต่อไปนี้มีขอบเขตที่ไม่ได้ลงชื่อเข้าใช้ 2 ขอบเขตเพื่อดู Google ไดรฟ์ของผู้ใช้ ข้อมูลเมตาและจัดการไฟล์ Google ไดรฟ์ที่เจาะจง

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

แนวทางปฏิบัติแนะนำในการจัดการสิทธิ์แบบละเอียด

หากคุณพิจารณาแล้วว่าต้องอัปเดตแอปพลิเคชันเพื่อจัดการ คุณควรอัปเดตโค้ดที่จำเป็นเพื่อให้จัดการความยินยอมได้อย่างเหมาะสม สำหรับหลายขอบเขต แอปพลิเคชันทั้งหมดควรสอดคล้องกับแนวทางปฏิบัติแนะนำต่อไปนี้

ตรวจสอบ บริการ Google API: นโยบายข้อมูลผู้ใช้และตรวจสอบว่าคุณปฏิบัติตามนโยบายดังกล่าว
ขอขอบเขตที่เฉพาะเจาะจงซึ่งจําเป็นสําหรับงาน คุณต้องปฏิบัติตามนโยบาย OAuth 2.0 ของ Google ที่ว่าขอเฉพาะขอบเขตที่ต้องใช้ คุณไม่ควรขอ ขอบเขตที่ลงชื่อเข้าใช้ เว้นแต่จำเป็นต่อฟังก์ชันหลักของแอป การรวมกลุ่มอีเมล ร่วมกันในระดับหนึ่ง โดยเฉพาะสำหรับผู้ใช้ครั้งแรกที่ไม่คุ้นเคยกับ ฟีเจอร์ต่างๆ ของแอปพลิเคชัน ก็อาจทำให้พวกเขาเข้าใจความต้องการ สิทธิ์ การทำเช่นนี้จะทำให้การปลุกเกิดขึ้นและทำให้ผู้ใช้ไม่มีส่วนร่วมกับ แอปพลิเคชัน
ระบุเหตุผลให้ผู้ใช้ทราบก่อนที่จะส่งคำขอการให้สิทธิ์ อธิบายให้ชัดเจนว่าเหตุใดแอปพลิเคชันของคุณจึงต้องการสิทธิ์ที่ขอ สิ่งที่คุณจะทำกับข้อมูลของผู้ใช้ และผู้ใช้จะได้รับประโยชน์อย่างไรจากการอนุมัติคำขอ การวิจัยของเราชี้ให้เห็นว่าคำอธิบายเหล่านี้ช่วยเพิ่มความไว้วางใจและการมีส่วนร่วมของผู้ใช้
การใช้งาน การให้สิทธิ์เพิ่มขึ้น ทุกครั้งที่แอปพลิเคชันขอขอบเขตเพื่อหลีกเลี่ยงการจัดการโทเค็นเพื่อการเข้าถึงหลายรายการ
ตรวจสอบขอบเขตที่ผู้ใช้ให้สิทธิ์ เมื่อส่งคำขอหลายรายการ พร้อมกัน ผู้ใช้อาจไม่ให้สิทธิ์ขอบเขตทั้งหมดที่แอปของคุณร้องขอ แอปของคุณควร ตรวจสอบว่าผู้ใช้ให้สิทธิ์ขอบเขตใดและจัดการการปฏิเสธขอบเขตโดยปิดใช้ขอบเขตที่เกี่ยวข้อง ใหม่ๆ ปฏิบัติตามนโยบาย Google OAuth 2.0 ใน การจัดการความยินยอมสำหรับหลายรายการ ขอบเขต และแจ้งผู้ใช้ให้ขอความยินยอมอีกครั้งเมื่อได้ระบุไว้ชัดเจนแล้วเท่านั้น ต้องการใช้ฟีเจอร์เฉพาะที่ต้องมีขอบเขต

อัปเดตแอปพลิเคชันเพื่อจัดการสิทธิ์แบบละเอียด

แอปพลิเคชัน Android

คุณควรอ่านเอกสารประกอบของ SDK ที่คุณใช้เพื่อโต้ตอบกับ Google OAuth 2.0 และ อัปเดตแอปพลิเคชันของคุณเพื่อจัดการการอนุญาตแบบละเอียดตาม แนวทางปฏิบัติแนะนำ

หากคุณใช้ auth.api.signin คุณสามารถใช้ SDK จากบริการ Google Play เพื่อโต้ตอบกับ OAuth 2.0 ของ Google requestPermissions เพื่อขอขอบเขตจำนวนน้อยสุดที่จำเป็น และ hasPermissions เพื่อตรวจสอบขอบเขตที่ผู้ใช้อนุญาตเมื่อ การขอสิทธิ์แบบละเอียด

แอปพลิเคชันส่วนขยายของ Chrome

คุณควรใช้ Chrome Identity API เพื่อทำงานกับ Google OAuth 2.0 โดยอิงตาม แนวทางปฏิบัติแนะนำ

ตัวอย่างต่อไปนี้แสดงวิธีจัดการสิทธิ์แบบละเอียดอย่างถูกต้อง

manifest.json

ไฟล์ Manifest ตัวอย่างแสดงขอบเขตที่ไม่ได้ลงชื่อเข้าใช้ 2 ขอบเขตสำหรับส่วนขยาย 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"]
  }
}

แนวทางที่ไม่ถูกต้อง

ทั้งหมดหรือไม่มีเลย

ผู้ใช้คลิกปุ่มเพื่อเริ่มต้นกระบวนการให้สิทธิ์ ข้อมูลโค้ดจะถือว่า ผู้ใช้จะเห็นปุ่ม "ทั้งหมด" หน้าจอขอความยินยอมสำหรับขอบเขต 2 ขอบเขตที่ระบุ ในไฟล์ 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.
            ...
          }
      });
});

แนวทางที่ถูกต้อง

ขอบเขตขนาดเล็กที่สุด

เลือกขอบเขตชุดที่เล็กที่สุดที่จำเป็น

แอปพลิเคชันควรขอชุดขอบเขตที่น้อยที่สุดเท่าที่จำเป็นเท่านั้น เราขอแนะนำให้แอปพลิเคชันขอขอบเขตครั้งละ 1 รายการเมื่อจําเป็นต้องดําเนินการงานให้เสร็จสมบูรณ์

ในตัวอย่างนี้ สมมติว่าขอบเขตทั้ง 2 รายการที่ประกาศใน 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 Sign-In สำหรับ iOS และ macOS ในการโต้ตอบกับ Google OAuth 2.0 คุณควรตรวจสอบ เอกสารประกอบเกี่ยวกับการจัดการแบบละเอียด สิทธิ์

เว็บแอปพลิเคชัน

คุณควรอ่านเอกสารประกอบของ SDK ที่ใช้เพื่อโต้ตอบกับ Google OAuth 2.0 และอัปเดตแอปพลิเคชันเพื่อจัดการสิทธิ์แบบละเอียดตามแนวทางปฏิบัติแนะนำ

การเข้าถึงฝั่งเซิร์ฟเวอร์ (ออฟไลน์)

โหมดการเข้าถึงฝั่งเซิร์ฟเวอร์ (ออฟไลน์) กำหนดให้คุณต้องดำเนินการต่อไปนี้

ตั้งเซิร์ฟเวอร์และกำหนดปลายทางที่เข้าถึงได้แบบสาธารณะเพื่อรับการให้สิทธิ์ โค้ด
กําหนดค่า URI การเปลี่ยนเส้นทางของปลายทางสาธารณะใน Credentials page ของคอนโซล Google Cloud

ข้อมูลโค้ดต่อไปนี้แสดงตัวอย่าง NodeJS ขอขอบเขตที่ไม่มีการลงชื่อเข้าใช้ 2 ขอบเขต ผู้ใช้จะ ดูหน้าจอคำยินยอมสิทธิ์แบบละเอียด

แนวทางไม่ถูกต้อง

ทั้งหมดหรือไม่มีเลย

ระบบจะเปลี่ยนเส้นทางผู้ใช้ไปยัง URL การให้สิทธิ์ ข้อมูลโค้ดจะถือว่ามีการแสดงให้ผู้ใช้เห็น ไอคอน "ปรับเปลี่ยนทุกอย่าง" หน้าจอขอความยินยอมสำหรับ 2 ขอบเขตที่ระบุไว้ใน การปกครองของ 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);
}

แนวทางที่ถูกต้อง

ขอบเขตเล็กที่สุด

เลือกขอบเขตชุดที่เล็กที่สุดที่จำเป็น

แอปพลิเคชันควรขอชุดขอบเขตที่น้อยที่สุดเท่าที่จำเป็นเท่านั้น ขอแนะนำให้ใช้ ที่แอปพลิเคชันจะขอครั้งละ 1 ขอบเขตเมื่อจำเป็นต้องใช้ในการทำงานให้เสร็จสมบูรณ์ เมื่อใดก็ตามที่แอปพลิเคชันขอขอบเขต ก็ควรใช้การให้สิทธิ์แบบเพิ่มเพื่อหลีกเลี่ยงการจัดการโทเค็นการเข้าถึงหลายรายการ

หากแอปพลิเคชันของคุณต้องขอขอบเขตที่ไม่ได้ลงชื่อเข้าใช้หลายรายการ คุณควรใช้ การให้สิทธิ์ที่เพิ่มขึ้น เมื่อส่งคำขอและตรวจสอบขอบเขตที่ผู้ใช้ให้สิทธิ์

ในตัวอย่างนี้ เราถือว่าทั้ง 2 ขอบเขตที่ระบุไว้จําเป็นต่อการทำงานของแอป คุณควรเลือกใช้ เปิดใช้สิทธิ์แบบละเอียด เพื่อให้ผู้ใช้ควบคุมการมอบสิทธิ์ แอปพลิเคชัน แอปพลิเคชันควรจัดการการตอบกลับจากผู้ใช้อย่างเหมาะสมโดยตรวจสอบขอบเขตที่ผู้ใช้ให้สิทธิ์

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 คุณควรตรวจสอบไลบรารี JavaScript เพื่อโต้ตอบกับ Google OAuth 2.0 เอกสารประกอบ เกี่ยวกับการจัดการสิทธิ์แบบละเอียด
สำหรับแอปพลิเคชันที่โทรออกโดยตรงโดยใช้ JavaScript ไปยังการให้สิทธิ์ Google OAuth 2.0 ปลายทาง คุณควรตรวจสอบ เอกสารประกอบ เกี่ยวกับการจัดการสิทธิ์แบบละเอียด

ทดสอบแอปพลิเคชันที่อัปเดตเกี่ยวกับการจัดการสิทธิ์แบบละเอียด

สรุปกรณีทั้งหมดที่ผู้ใช้สามารถตอบสนองต่อคำขอสิทธิ์และ จากแอปพลิเคชันของคุณ เช่น หากผู้ใช้อนุญาตเพียง 2 ส่วน จากขอบเขตที่ขอ 3 ขอบเขต แอปพลิเคชันของคุณควรจะทำงานตามนั้น
ทดสอบแอปพลิเคชันโดยเปิดใช้สิทธิ์แบบละเอียด คุณเปิดใช้ได้ 2 วิธี สิทธิ์แบบละเอียด
1. ตรวจสอบหน้าจอคำยินยอม OAuth 2.0 ของแอปพลิเคชันเพื่อดูว่า สิทธิ์แบบละเอียดเปิดอยู่แล้วสำหรับ แอปพลิเคชัน คุณยังสามารถสร้างรหัสไคลเอ็นต์ Google OAuth 2.0 ใหม่สำหรับเว็บ, Android หรือ iOS ได้ด้วย ผ่านคอนโซล Google Cloud เพื่อการทดสอบ เนื่องจากสิทธิ์แบบละเอียด เปิดใช้ให้
2. ตั้งค่าพารามิเตอร์ enable_granular_consent ไปยัง true เมื่อเรียกใช้ Google OAuth ปลายทางการให้สิทธิ์ SDK บางรายการมีการสนับสนุนอย่างชัดแจ้งสำหรับการดำเนินการนี้ พารามิเตอร์ สำหรับเครื่องมืออื่นๆ โปรดดูเอกสารประกอบเพื่อดูวิธีเพิ่มพารามิเตอร์นี้และ ด้วยตนเอง หากการใช้งานของคุณไม่รองรับการเพิ่มพารามิเตอร์ดังกล่าว คุณจะสร้างเว็บใหม่ได้ รหัสไคลเอ็นต์ Google OAuth 2.0 ของ Android หรือ iOS ผ่านคอนโซล Google Cloud สำหรับการทดสอบ ตามวัตถุประสงค์ที่ระบุไว้ก่อนหน้านี้เท่านั้น
  สำคัญ: เมื่อ Google เปิดใช้สิทธิ์แบบละเอียดสำหรับแอปพลิเคชัน พารามิเตอร์ enable_granular_consent จะไม่มีผลอีกต่อไป
เมื่อทดสอบแอปพลิเคชันที่อัปเดตแล้ว ให้ใช้บัญชี Google ส่วนบุคคล (@gmail.com) แทนบัญชี Workspace เนื่องจากแอปของ Workspace Enterprise ที่ดำเนินการ การมอบสิทธิ์ทั่วทั้งโดเมน หรือทำเครื่องหมายเป็น เชื่อถือได้ จะไม่ได้รับผลกระทบจากการเปลี่ยนแปลงสิทธิ์แบบละเอียดในขณะนี้ ดังนั้นการทดสอบด้วย Workspace บัญชีจากองค์กรอาจไม่แสดงหน้าจอขอความยินยอมแบบละเอียดใหม่ตามที่ต้องการ

วิธีจัดการสิทธิ์แบบละเอียด

ภาพรวม

สิทธิ์แบบละเอียดคืออะไร

เมื่อมีการขอขอบเขตที่ไม่ใช่การลงชื่อเข้าใช้มากกว่า 1 ขอบเขต

ขอบเขตการลงชื่อเข้าใช้และไม่ได้ลงชื่อเข้าใช้

ขอบเขตที่ไม่มีการลงชื่อเข้าใช้มากกว่า 1 ขอบเขต

ตรวจสอบว่าแอปพลิเคชันได้รับผลกระทบหรือไม่

วิธีตรวจสอบว่าแอปพลิเคชันของคุณใช้หลายขอบเขตหรือไม่

ตรวจสอบโค้ดของแอปพลิเคชัน

บริการ Google Identity

Python

Node.js

ตรวจสอบสายที่โทรออกผ่านเครือข่าย

แนวทางปฏิบัติแนะนำในการจัดการสิทธิ์แบบละเอียด

อัปเดตแอปพลิเคชันเพื่อจัดการสิทธิ์แบบละเอียด

แอปพลิเคชัน Android

แอปพลิเคชันส่วนขยายของ Chrome

แนวทางที่ไม่ถูกต้อง

ทั้งหมดหรือไม่มีเลย

แนวทางที่ถูกต้อง

ขอบเขตขนาดเล็กที่สุด

เลือกขอบเขตชุดที่เล็กที่สุดที่จำเป็น

แอปพลิเคชัน iOS, iPadOS และ macOS

เว็บแอปพลิเคชัน

การเข้าถึงฝั่งเซิร์ฟเวอร์ (ออฟไลน์)

แนวทางไม่ถูกต้อง

ทั้งหมดหรือไม่มีเลย

แนวทางที่ถูกต้อง

ขอบเขตเล็กที่สุด

เลือกขอบเขตชุดที่เล็กที่สุดที่จำเป็น

สิทธิ์การเข้าถึงฝั่งไคลเอ็นต์เท่านั้น

ทดสอบแอปพลิเคชันที่อัปเดตเกี่ยวกับการจัดการสิทธิ์แบบละเอียด