درخواست‌های Meet REST API را تأیید و تأیید کنید
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
احراز هویت و مجوز مکانیزم هایی هستند که به ترتیب برای تأیید هویت و دسترسی به منابع استفاده می شوند. این سند چگونگی کارکرد احراز هویت و مجوز برای درخواست‌های Google Meet REST API را شرح می‌دهد.
این راهنما نحوه استفاده از OAuth 2.0 با اطلاعات کاربری Google کاربر برای دسترسی به Meet REST API را توضیح می دهد. احراز هویت و تأیید اعتبار با اطلاعات کاربری به برنامه‌های Meet اجازه می‌دهد به داده‌های کاربر دسترسی داشته باشند و عملیات‌ها را از طرف کاربر تأیید شده انجام دهند. با احراز هویت از طرف یک کاربر، برنامه دارای مجوزهای مشابه با آن کاربر است و می تواند اقداماتی را انجام دهد که گویی توسط آن کاربر انجام شده است.
اصطلاحات مهم
در زیر لیستی از اصطلاحات مربوط به احراز هویت و مجوز آمده است:
- احراز هویت
عمل حصول اطمینان از اینکه یک اصل ، که می تواند یک کاربر باشد
یا برنامه ای که از طرف یک کاربر عمل می کند، همان کسی است که آنها می گویند. هنگام نوشتن برنامه‌های Google Workspace، باید از این نوع احراز هویت آگاه باشید: تأیید هویت کاربر و تأیید اعتبار برنامه. برای Meet REST API، فقط می‌توانید با استفاده از احراز هویت کاربر احراز هویت کنید.
- مجوز
مجوزها یا "مرجع" که مدیر اصلی باید به آنها دسترسی داشته باشد
داده یا انجام عملیات مجوز از طریق کدی که در برنامه خود می نویسید انجام می شود. این کد به کاربر اطلاع می‌دهد که برنامه می‌خواهد از طرف او عمل کند و در صورت اجازه، از اعتبارنامه منحصربه‌فرد برنامه شما برای دریافت کد دسترسی از Google برای دسترسی به داده‌ها یا انجام عملیات استفاده می‌کند.
با دامنه های REST API آشنا شوید
محدوده مجوز مجوزهایی هستند که از کاربران درخواست می‌کنید تا برنامه شما به محتوای جلسه اجازه دسترسی داشته باشند. هنگامی که شخصی برنامه شما را نصب می کند، از کاربر خواسته می شود تا این حوزه ها را تأیید کند. به طور کلی، شما باید محدودترین محدوده ممکن را انتخاب کنید و از درخواست دامنه هایی که برنامه شما به آن نیاز ندارد اجتناب کنید. کاربران با سهولت بیشتری به محدوده‌های محدود و به وضوح توضیح داده شده دسترسی می‌دهند.
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 Drive API بارگیری کنند. | محدود شده است |
محدوده OAuth 2.0 مجاور Meet زیر در فهرست حوزه‌های API Google Drive قرار دارد:
| کد محدوده | توضیحات | استفاده |
|---|
https://www.googleapis.com/auth/drive.meet.readonly | مشاهده فایل‌های Drive ایجاد یا ویرایش شده توسط Google Meet. | محدود شده است |
ستون Usage در جدول حساسیت هر محدوده را با توجه به تعاریف زیر نشان می دهد:
غیر حساس : این حوزه‌ها کوچکترین دامنه دسترسی مجوز را ارائه می‌کنند و فقط به تأیید اولیه برنامه نیاز دارند. برای کسب اطلاعات بیشتر، به الزامات تأیید مراجعه کنید.
حساس : این محدوده‌ها دسترسی به داده‌های کاربر خاص Google را که توسط کاربر برای برنامه شما مجاز است، فراهم می‌کنند. از شما می‌خواهد تا از تأیید برنامه اضافی عبور کنید. برای کسب اطلاعات بیشتر، به الزامات محدوده حساس و محدود مراجعه کنید.
محدود شده : این حوزه‌ها دسترسی گسترده‌ای به داده‌های کاربر Google را فراهم می‌کنند و از شما می‌خواهند که یک فرآیند تأیید محدوده محدود را طی کنید. برای کسب اطلاعات بیشتر، به خط‌مشی داده‌های کاربر سرویس‌های Google API و الزامات اضافی برای محدوده‌های API خاص مراجعه کنید. اگر داده‌های محدوده محدود را روی سرورها ذخیره می‌کنید (یا ارسال می‌کنید)، پس باید ارزیابی امنیتی را انجام دهید.
اگر برنامه شما نیاز به دسترسی به سایر APIهای Google دارد، می‌توانید آن محدوده‌ها را نیز اضافه کنید. برای اطلاعات بیشتر در مورد دامنه های Google API، به استفاده از OAuth 2.0 برای دسترسی به Google API مراجعه کنید.
برای تعریف اینکه چه اطلاعاتی برای کاربران و بازبینان برنامه نمایش داده می شود، به پیکربندی صفحه رضایت OAuth مراجعه کنید و دامنه ها را انتخاب کنید .
برای اطلاعات بیشتر درباره حوزه‌های خاص OAuth 2.0، به OAuth 2.0 Scopes برای Google API مراجعه کنید.
با استفاده از تفویض اختیار در سطح دامنه، احراز هویت و مجوز
اگر یک سرپرست دامنه هستید، می‌توانید اختیاری را در سراسر دامنه اعطا کنید تا به حساب سرویس یک برنامه اجازه دسترسی به داده‌های کاربران شما را بدون نیاز به رضایت هر کاربر بدهد. پس از پیکربندی نمایندگی در سراسر دامنه، حساب سرویس می‌تواند هویت یک حساب کاربری را جعل کند . اگرچه یک حساب سرویس برای احراز هویت استفاده می‌شود، اما تفویض اختیار در دامنه، هویت کاربر را جعل می‌کند و بنابراین احراز هویت کاربر در نظر گرفته می‌شود. هر قابلیتی که نیاز به احراز هویت کاربر داشته باشد، می‌تواند از تفویض اختیار در سطح دامنه استفاده کند.
جز در مواردی که غیر از این ذکر شده باشد،محتوای این صفحه تحت مجوز Creative Commons Attribution 4.0 License است. نمونه کدها نیز دارای مجوز Apache 2.0 License است. برای اطلاع از جزئیات، به خطمشیهای سایت Google Developers مراجعه کنید. جاوا علامت تجاری ثبتشده Oracle و/یا شرکتهای وابسته به آن است.
تاریخ آخرین بهروزرسانی 2025-08-29 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2025-08-29 بهوقت ساعت هماهنگ جهانی."],[],[],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)."]]
