ตรวจสอบสิทธิ์และให้สิทธิ์คำขอ Meet REST API
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
การตรวจสอบสิทธิ์และการให้สิทธิ์เป็นกลไกที่ใช้เพื่อยืนยันตัวตนและ
เข้าถึงทรัพยากรตามลำดับ เอกสารนี้อธิบายวิธีการทำงานของการตรวจสอบสิทธิ์และการให้สิทธิ์สำหรับคำขอ REST API ของ Google Meet
คู่มือนี้อธิบายวิธีใช้ OAuth 2.0 กับข้อมูลเข้าสู่ระบบ Google ของผู้ใช้เพื่อ
เข้าถึง Meet REST API การตรวจสอบสิทธิ์และ
การให้สิทธิ์ด้วยข้อมูลเข้าสู่ระบบของผู้ใช้จะช่วยให้แอป Meet เข้าถึงข้อมูลผู้ใช้
และดำเนินการในนามของผู้ใช้ที่ตรวจสอบสิทธิ์แล้วได้ การตรวจสอบสิทธิ์ในนามของผู้ใช้ทำให้แอปมีสิทธิ์เดียวกับผู้ใช้รายนั้นและสามารถดำเนินการ
เสมือนว่าผู้ใช้รายนั้นเป็นผู้ดำเนินการ
คำศัพท์สำคัญ
รายการคำศัพท์ที่เกี่ยวข้องกับการตรวจสอบสิทธิ์และการให้สิทธิ์มีดังนี้
- การตรวจสอบสิทธิ์
การดำเนินการเพื่อให้มั่นใจว่าผู้ใช้ซึ่งอาจเป็นผู้ใช้
หรือแอปที่ดำเนินการในนามของผู้ใช้เป็นบุคคลที่ระบุไว้ เมื่อเขียนแอป Google Workspace คุณควรทราบเกี่ยวกับการตรวจสอบสิทธิ์ประเภทต่อไปนี้
การตรวจสอบสิทธิ์ผู้ใช้และการตรวจสอบสิทธิ์แอป สำหรับ Meet REST API คุณจะตรวจสอบสิทธิ์ได้โดยใช้การตรวจสอบสิทธิ์ผู้ใช้เท่านั้น
- การให้สิทธิ์
สิทธิ์หรือ "อำนาจ" ที่ผู้ใช้หลักมีในการเข้าถึง
ข้อมูลหรือดำเนินการ การให้สิทธิ์จะดำเนินการผ่านโค้ดที่คุณเขียน
ในแอป โค้ดนี้จะแจ้งให้ผู้ใช้ทราบว่าแอปต้องการดำเนินการในนามของผู้ใช้ และหากได้รับอนุญาต โค้ดจะใช้ข้อมูลเข้าสู่ระบบที่ไม่ซ้ำกันของแอปเพื่อขอโทเค็นเพื่อการเข้าถึงจาก Google เพื่อเข้าถึงข้อมูลหรือดำเนินการ
ขอบเขต REST API ของ Meet
ขอบเขตการให้สิทธิ์คือสิทธิ์ที่คุณขอให้ผู้ใช้ให้สิทธิ์เพื่อให้แอปของคุณเข้าถึงเนื้อหาการประชุมได้ เมื่อมีผู้ติดตั้งแอปของคุณ ระบบจะขอให้ผู้ใช้
ตรวจสอบขอบเขตเหล่านี้ โดยทั่วไป คุณควรเลือกขอบเขตที่แคบที่สุดเท่าที่จะเป็นไปได้ และหลีกเลี่ยงการขอขอบเขตที่แอปไม่จำเป็นต้องใช้ ผู้ใช้จะให้สิทธิ์เข้าถึงขอบเขตที่จำกัดและอธิบายไว้อย่างชัดเจนได้ง่ายขึ้น
Meet REST API รองรับขอบเขต OAuth 2.0 ต่อไปนี้
| รหัสขอบเขต |
คำอธิบาย |
การใช้งาน |
https://www.googleapis.com/auth/meetings.space.settings |
แก้ไขและดูการตั้งค่าสำหรับการโทรผ่าน Google Meet ทั้งหมด |
ไม่ละเอียดอ่อน |
https://www.googleapis.com/auth/meetings.space.created |
อนุญาตให้แอปสร้าง แก้ไข และอ่านข้อมูลเมตาเกี่ยวกับพื้นที่การประชุมที่แอปสร้างขึ้น |
ละเอียดอ่อน |
https://www.googleapis.com/auth/meetings.space.readonly |
อนุญาตให้แอปอ่านข้อมูลเมตาเกี่ยวกับพื้นที่การประชุมที่ผู้ใช้มีสิทธิ์เข้าถึง |
ละเอียดอ่อน |
https://www.googleapis.com/auth/drive.readonly |
อนุญาตให้แอปดาวน์โหลดไฟล์บันทึกและไฟล์ถอดเสียงจาก Google ไดรฟ์ API |
จำกัด |
ขอบเขต OAuth 2.0 ที่เกี่ยวข้องกับ Meet ต่อไปนี้อยู่ใน
รายการขอบเขต Google Drive API
| รหัสขอบเขต |
คำอธิบาย |
การใช้งาน |
https://www.googleapis.com/auth/drive.meet.readonly |
ดูไฟล์ในไดรฟ์ที่ Google Meet สร้างหรือแก้ไข |
จำกัด |
คอลัมน์การใช้งานในตารางจะระบุความละเอียดอ่อนของแต่ละขอบเขตตามคำจำกัดความต่อไปนี้
ไม่ละเอียดอ่อน: ขอบเขตเหล่านี้ให้ขอบเขตการเข้าถึงการให้สิทธิ์ที่เล็กที่สุด
และต้องมีการยืนยันแอปขั้นพื้นฐานเท่านั้น ดูข้อมูลเพิ่มเติมได้ที่
ข้อกำหนด
ในการยืนยัน
มีความละเอียดอ่อน: ขอบเขตเหล่านี้ให้สิทธิ์เข้าถึงข้อมูลผู้ใช้ Google ที่เฉพาะเจาะจง
ซึ่งผู้ใช้ให้สิทธิ์แอปของคุณ และกำหนดให้คุณต้องผ่าน
การยืนยันแอปเพิ่มเติม ดูข้อมูลเพิ่มเติมได้ที่ข้อกำหนดสำหรับขอบเขตที่ละเอียดอ่อนและถูกจำกัด
จำกัด: ขอบเขตเหล่านี้ให้สิทธิ์เข้าถึงข้อมูลผู้ใช้ Google ในวงกว้างและ
กำหนดให้คุณต้องผ่านกระบวนการยืนยันขอบเขตที่จำกัด ดูข้อมูลเพิ่มเติมได้ที่นโยบายข้อมูลผู้ใช้ของบริการ Google API และข้อกำหนดเพิ่มเติมสำหรับขอบเขต API เฉพาะ
หากคุณจัดเก็บ (หรือส่ง) ข้อมูลขอบเขตที่จำกัดไว้ในเซิร์ฟเวอร์ คุณจะต้อง
เข้ารับการประเมินความปลอดภัย
หากแอปของคุณต้องเข้าถึง Google API อื่นๆ คุณก็เพิ่มขอบเขตเหล่านั้นได้เช่นกัน
ดูข้อมูลเพิ่มเติมเกี่ยวกับขอบเขต Google API ได้ที่หัวข้อการใช้ OAuth 2.0 เพื่อ
เข้าถึง Google API
หากต้องการกำหนดข้อมูลที่จะแสดงต่อผู้ใช้และผู้ตรวจสอบแอป โปรดดูหัวข้อกำหนดค่าหน้าจอขอความยินยอม OAuth และเลือกขอบเขต
ดูข้อมูลเพิ่มเติมเกี่ยวกับขอบเขต OAuth 2.0 ที่เฉพาะเจาะจงได้ที่ขอบเขต OAuth 2.0 สำหรับ
Google APIs
ตรวจสอบสิทธิ์และให้สิทธิ์โดยใช้การมอบสิทธิ์ทั่วทั้งโดเมน
หากคุณเป็นผู้ดูแลระบบโดเมน คุณสามารถให้การมอบสิทธิ์ทั่วทั้งโดเมนของ
สิทธิ์เพื่อให้สิทธิ์บัญชีบริการของ
แอปพลิเคชันเข้าถึงข้อมูลของผู้ใช้ได้โดยไม่ต้องขอความยินยอมจากผู้ใช้แต่ละราย หลังจากกำหนดค่าการมอบสิทธิ์ทั่วทั้งโดเมนแล้ว บัญชีบริการ
จะแอบอ้างเป็นบัญชี
ผู้ใช้ได้
แม้ว่าจะใช้บัญชีบริการในการตรวจสอบสิทธิ์ แต่การมอบสิทธิ์ทั่วทั้งโดเมน
จะแอบอ้างเป็นผู้ใช้ จึงถือเป็นการตรวจสอบสิทธิ์ผู้ใช้ ความสามารถใดๆ
ที่ต้องมีการตรวจสอบสิทธิ์ผู้ใช้จะใช้การมอบสิทธิ์ทั่วทั้งโดเมนได้
เนื้อหาของหน้าเว็บนี้ได้รับอนุญาตภายใต้ใบอนุญาตที่ต้องระบุที่มาของครีเอทีฟคอมมอนส์ 4.0 และตัวอย่างโค้ดได้รับอนุญาตภายใต้ใบอนุญาต Apache 2.0 เว้นแต่จะระบุไว้เป็นอย่างอื่น โปรดดูรายละเอียดที่นโยบายเว็บไซต์ Google Developers Java เป็นเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-08-29 UTC
[null,null,["อัปเดตล่าสุด 2025-08-29 UTC"],[],[],null,["# Authenticate and authorize Meet REST API requests\n\nAuthentication and authorization are mechanisms used to verify identity and\naccess to resources, respectively. This document outlines how authentication and\nauthorization work for Google Meet REST API requests.\n\nThis guide explains how to use OAuth 2.0 with a user's Google credentials to\naccess the [Meet REST API](/workspace/meet/api/reference/rest/v2). Authenticating and\nauthorizing with user credentials lets Meet apps access user data\nand perform operations on the authenticated user's behalf. By authenticating on\na user's behalf, the app has the same permissions as that user and can perform\nactions as if they were performed by that user.\n\nImportant terminology\n---------------------\n\nThe following is a list of terms related to authentication and authorization:\n\n*Authentication*\n\n: The act of ensuring that a *principal*, which can be a user\n\n or an app acting on behalf of a user, is who they say they are. When writing\n Google Workspace apps, you should be aware of these types of\n authentication: user authentication and app authentication. For\n Meet REST API, you can only authenticate using user authentication.\n\n*Authorization*\n\n: The permissions or \"authority\" the principal has to access\n\n data or perform operations. The authorization is done through code you write\n in your app. This code informs the user that the app wishes to act on their\n behalf and, if allowed, uses your app's unique credentials to obtain an\n access token from Google to access data or perform operations.\n\nMeet REST API scopes\n--------------------\n\nAuthorization scopes are the permissions that you request users to authorize for\nyour app to access the meeting content. When someone installs your app, the user\nis asked to validate these scopes. Generally, you should choose the most\nnarrowly focused scope possible and avoid requesting scopes that your app\ndoesn't require. Users more readily grant access to limited, clearly described\nscopes.\n\nThe Meet REST API supports the following OAuth 2.0 scopes:\n\n| Scope code | Description | Usage |\n|-----------------------------------------------------------|-------------------------------------------------------------------------------------------|---------------|\n| `https://www.googleapis.com/auth/meetings.space.settings` | Edit and see the settings for all of your Google Meet calls. | Non-sensitive |\n| `https://www.googleapis.com/auth/meetings.space.created` | Allow apps to create, modify, and read metadata about meeting spaces created by your app. | Sensitive |\n| `https://www.googleapis.com/auth/meetings.space.readonly` | Allow apps to read metadata about any meeting space the user has access to. | Sensitive |\n| `https://www.googleapis.com/auth/drive.readonly` | Allow apps to download recording and transcript files from Google Drive API. | Restricted |\n\nThe following Meet-adjacent OAuth 2.0 scope resides in the [Google Drive API scopes list](/workspace/drive/api/guides/api-specific-auth#drive-scopes):\n\n| Scope code | Description | Usage |\n|-------------------------------------------------------|----------------------------------------------------|------------|\n| `https://www.googleapis.com/auth/drive.meet.readonly` | View Drive files created or edited by Google Meet. | Restricted |\n\nThe Usage column in the table indicates the sensitivity of each scope, according\nto the following definitions:\n\n- **Non-sensitive** : These scopes provide the smallest scope of authorization\n access and only require basic app verification. To learn more, see\n [Verification\n requirements](https://support.google.com/cloud/answer/13464321).\n\n- **Sensitive** : These scopes provide access to specific Google user data\n that's authorized by the user for your app. It requires you to go through\n additional app verification. To learn more, see [Sensitive and Restricted\n Scope\n Requirements](https://support.google.com/cloud/answer/13464321#ss-rs-requirements).\n\n- **Restricted** : These scopes provide wide access to Google user data and\n require you to go through a restricted scope verification process. To learn\n more, see [Google API Services User Data\n Policy](/terms/api-services-user-data-policy) and [Additional Requirements\n for Specific API\n Scopes](/terms/api-services-user-data-policy#additional_requirements_for_specific_api_scopes).\n If you store restricted scope data on servers (or transmit), then you must\n go through a security assessment.\n\nIf your app requires access to any other Google APIs, you can add those scopes\nas well. For more information about Google API scopes, see [Using OAuth 2.0 to\nAccess Google APIs](/accounts/docs/OAuth2).\n\nTo define what information is displayed to users and app reviewers, see\n[Configure the OAuth consent screen and choose\nscopes](/workspace/guides/configure-oauth-consent).\n\nFor more information about specific OAuth 2.0 scopes, see [OAuth 2.0 Scopes for\nGoogle APIs](/identity/protocols/oauth2/scopes).\n\nAuthenticate and authorize using domain-wide delegation\n-------------------------------------------------------\n\nIf you're a domain administrator, you can grant [domain-wide delegation of\nauthority](https://support.google.com/a/answer/162106) to authorize an\napplication's service account to access your users' data without requiring each\nuser to give consent. After you configure domain-wide delegation, the [service\naccount can impersonate a user\naccount](https://developers.google.com/identity/protocols/oauth2/service-account#authorizingrequests).\nAlthough a service account is used for authentication, domain-wide delegation\nimpersonates a user and is therefore considered *user authentication*. Any\ncapability that requires user authentication can use domain-wide delegation.\n\nRelated topics\n--------------\n\n- For an overview of authentication and authorization in Google Workspace,\n see [Learn about authentication and\n authorization](/workspace/guides/auth-overview).\n\n- For an overview of authentication and authorization in Google Cloud, see\n [Authentication methods at\n Google](https://cloud.google.com/docs/authentication)."]]
