Autenticare e autorizzare le richieste API REST Meet
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
L'autenticazione e l'autorizzazione sono meccanismi utilizzati per verificare l'identità e
l'accesso alle risorse, rispettivamente. Questo documento descrive il funzionamento dell'autenticazione e
dell'autorizzazione per le richieste dell'API REST di Google Meet.
Questa guida spiega come utilizzare OAuth 2.0 con le credenziali Google di un utente per accedere all'API REST di Meet. L'autenticazione e l'autorizzazione con le credenziali utente consentono alle app Meet di accedere ai dati utente ed eseguire operazioni per conto dell'utente autenticato. Eseguendo l'autenticazione per conto di un utente, l'app dispone delle stesse autorizzazioni dell'utente e può eseguire azioni come se fossero eseguite da quell'utente.
Terminologia importante
Di seguito è riportato un elenco di termini relativi ad autenticazione e autorizzazione:
Autenticazione
L'azione di garantire che un principal, che può essere un utente
o un'app che agisce per conto di un utente, sia chi dice di essere. Quando scrivi
app Google Workspace, devi conoscere questi tipi di
autenticazione: autenticazione utente e autenticazione app. Per
l'API REST di Meet, puoi eseguire l'autenticazione solo utilizzando l'autenticazione utente.
Autorizzazione
Le autorizzazioni o l'"autorità" che l'entità ha per accedere
dati o eseguire operazioni. L'autorizzazione viene eseguita tramite il codice che scrivi
nella tua app. Questo codice informa l'utente che l'app vuole agire per suo
conto e, se consentito, utilizza le credenziali uniche dell'app per ottenere un
token di accesso da Google per accedere ai dati o eseguire operazioni.
Rispetta gli ambiti dell'API REST
Gli ambiti di autorizzazione sono le autorizzazioni che richiedi agli utenti di autorizzare per
consentire alla tua app di accedere ai contenuti della riunione. Quando qualcuno installa la tua app, all'utente
viene chiesto di convalidare questi ambiti. In generale, dovresti scegliere l'ambito più
ristretto possibile ed evitare di richiedere ambiti che la tua app
non richiede. Gli utenti concedono più facilmente l'accesso a ambiti limitati e descritti
in modo chiaro.
L'API REST di Meet supporta i seguenti ambiti OAuth 2.0:
Visualizzare i file di Drive creati o modificati da Google Meet.
Con restrizioni
La colonna Utilizzo della tabella indica la sensibilità di ogni ambito, in base
alle seguenti definizioni:
Non sensibili: questi ambiti forniscono il più piccolo ambito di accesso
all'autorizzazione e richiedono solo la verifica di base dell'app. Per saperne di più, consulta i requisiti di verifica.
Sensibili: questi ambiti forniscono l'accesso a dati utente Google specifici
autorizzati dall'utente per la tua app. Richiedono di superare
una verifica aggiuntiva dell'app. Per saperne di più, consulta Requisiti
relativi
all'ambito sensibile e con limitazioni.
Con restrizioni: questi ambiti forniscono un ampio accesso ai dati utente di Google e
richiedono di superare una procedura di verifica degli ambiti con restrizioni. Per saperne
di più, consulta le Norme relative ai dati utente dei servizi API di
Google e i Requisiti aggiuntivi per
gli ambiti API
specifici.
Se memorizzi (o trasmetti) dati con ambiti con restrizioni sui server, devi
sottoporsi a una valutazione della sicurezza.
Se la tua app richiede l'accesso ad altre API di Google, puoi aggiungere anche questi ambiti. Per ulteriori informazioni sugli ambiti delle API di Google, vedi Utilizzare OAuth 2.0 per accedere alle API di Google.
Autenticare e autorizzare utilizzando la delega a livello di dominio
Se sei un amministratore di dominio, puoi concedere la delega a livello di dominio
dell'autorità per autorizzare l'account di servizio di un'applicazione ad accedere ai dati dei tuoi utenti senza richiedere il consenso di ciascun utente. Dopo aver configurato la delega sull'intero dominio, il service
account può rappresentare un
account utente.
Sebbene un service account venga utilizzato per l'autenticazione, la delega sull'intero dominio
impersona un utente ed è quindi considerata autenticazione utente. Qualsiasi
funzionalità che richiede l'autenticazione dell'utente può utilizzare la delega a livello di dominio.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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)."]]
