Mengautentikasi dan mengizinkan permintaan Meet REST API
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Otentikasi dan otorisasi adalah mekanisme yang digunakan untuk memverifikasi identitas dan
akses ke sumber daya. Dokumen ini menguraikan cara kerja autentikasi dan
otorisasi untuk permintaan Google Meet REST API.
Panduan ini menjelaskan cara menggunakan OAuth 2.0 dengan kredensial Google pengguna untuk
mengakses Meet REST API. Mengautentikasi dan
mengizinkan dengan kredensial pengguna memungkinkan aplikasi Meet mengakses data pengguna
dan melakukan operasi atas nama pengguna yang diautentikasi. Dengan melakukan autentikasi atas nama pengguna, aplikasi memiliki izin yang sama dengan pengguna tersebut dan dapat melakukan tindakan seolah-olah dilakukan oleh pengguna tersebut.
Terminologi penting
Berikut adalah daftar istilah yang terkait dengan autentikasi dan otorisasi:
Autentikasi
Tindakan untuk memastikan bahwa prinsipal, yang dapat berupa pengguna
atau aplikasi yang bertindak atas nama pengguna, adalah orang yang mereka klaim. Saat menulis aplikasi Google Workspace, Anda harus mengetahui jenis autentikasi berikut: autentikasi pengguna dan autentikasi aplikasi. Untuk
Meet REST API, Anda hanya dapat melakukan autentikasi menggunakan autentikasi pengguna.
Otorisasi
Izin atau "otoritas" yang dimiliki akun utama untuk mengakses
data atau melakukan operasi. Otorisasi dilakukan melalui kode yang Anda tulis
di aplikasi Anda. Kode ini memberi tahu pengguna bahwa aplikasi ingin bertindak atas nama mereka
dan, jika diizinkan, menggunakan kredensial unik aplikasi Anda untuk mendapatkan
token akses dari Google guna mengakses data atau melakukan operasi.
Cakupan REST API Meet
Cakupan otorisasi adalah izin yang Anda minta agar pengguna mengizinkan aplikasi Anda mengakses konten rapat. Saat seseorang menginstal aplikasi Anda, pengguna
diminta untuk memvalidasi cakupan ini. Secara umum, Anda harus memilih cakupan yang paling
berfokus sempit dan menghindari permintaan cakupan yang tidak diperlukan oleh aplikasi Anda. Pengguna lebih mudah memberikan akses ke cakupan yang terbatas dan dijelaskan dengan jelas.
Meet REST API mendukung cakupan OAuth 2.0 berikut:
Melihat file Drive yang dibuat atau diedit oleh Google Meet.
Dibatasi
Kolom Penggunaan dalam tabel menunjukkan sensitivitas setiap cakupan, menurut definisi berikut:
Tidak sensitif: Cakupan ini memberikan cakupan akses otorisasi terkecil dan hanya memerlukan verifikasi aplikasi dasar. Untuk mempelajari lebih lanjut, lihat
Persyaratan
verifikasi.
Sensitif: Cakupan ini memberikan akses ke data pengguna Google tertentu yang diizinkan oleh pengguna untuk aplikasi Anda. Anda harus menjalani verifikasi aplikasi tambahan. Untuk mempelajari lebih lanjut, lihat Persyaratan Cakupan Sensitif dan Terlarang.
Dibatasi: Cakupan ini memberikan akses luas ke data pengguna Google dan mengharuskan Anda menjalani proses verifikasi cakupan yang dibatasi. Untuk mempelajari lebih lanjut, lihat Kebijakan Data Pengguna Layanan Google API dan Persyaratan Tambahan untuk Cakupan API Tertentu.
Jika Anda menyimpan data cakupan terbatas di server (atau mengirimkan), Anda harus menjalani penilaian keamanan.
Jika aplikasi Anda memerlukan akses ke Google API lainnya, Anda juga dapat menambahkan cakupan tersebut. Untuk mengetahui informasi selengkapnya tentang cakupan Google API, lihat Menggunakan OAuth 2.0 untuk
Mengakses Google API.
Mengautentikasi dan memberikan otorisasi menggunakan delegasi tingkat domain
Jika Anda adalah administrator domain, Anda dapat memberikan delegasi tingkat domain untuk
otoritas guna mengizinkan akun layanan
aplikasi mengakses data pengguna Anda tanpa mewajibkan setiap
pengguna memberikan izin. Setelah Anda mengonfigurasi delegasi tingkat domain, akun
layanan dapat meniru identitas akun
pengguna.
Meskipun akun layanan digunakan untuk autentikasi, delegasi di seluruh domain
meniru pengguna dan oleh karena itu dianggap sebagai autentikasi pengguna. Setiap
kemampuan yang memerlukan autentikasi pengguna dapat menggunakan delegasi tingkat domain.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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)."]]
