Autenticare e autorizzare le richieste API REST Meet

L'autenticazione e l'autorizzazione sono meccanismi utilizzati rispettivamente per verificare l'identità e l'accesso alle risorse. Questo documento illustra 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 e di eseguire operazioni per conto dell'utente autenticato. Se si autentica per conto di un utente, l'app dispone delle stesse autorizzazioni dell'utente e può eseguire azioni come se fossero state eseguite dall'utente.

Terminologia importante

Di seguito è riportato un elenco di termini relativi ad autenticazione e autorizzazione:

Autenticazione

L'atto di garantire che un principale, che può essere un utente

o un'app che agisce per conto di un utente, è chi dice di essere. Quando scrivi app di 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à" di cui l'entità dispone per accedere

dati o eseguire operazioni. L'autorizzazione viene eseguita tramite il codice scritto nella tua app. Questo codice informa l'utente che l'app vuole agire per suo conto e, se consentito, utilizza le credenziali univoche della tua app per ottenere un token di accesso da Google per accedere ai dati o eseguire operazioni.

Conoscere gli ambiti dell'API REST

Gli ambiti di autorizzazione sono le autorizzazioni che chiedi agli utenti di autorizzare per consentire alla tua app di accedere ai contenuti della riunione. Quando un utente installa la tua app, gli viene chiesto di convalidare questi ambiti. In genere, devi scegliere l'ambito più specifico possibile ed evitare di richiedere ambiti non necessari per la tua app. 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:

Codice ambito Descrizione Utilizzo
https://www.googleapis.com/auth/meetings.space.settings Modifica e visualizza le impostazioni di tutte le tue chiamate di Google Meet. Non sensibili
https://www.googleapis.com/auth/meetings.space.created Consenti alle app di creare, modificare e leggere i metadati degli spazi di riunione creati dalla tua app. Sensibile
https://www.googleapis.com/auth/meetings.space.readonly Consenti alle app di leggere i metadati di qualsiasi spazio di riunione a cui l'utente ha accesso. Sensibile
https://www.googleapis.com/auth/drive.readonly Consenti alle app di scaricare file di registrazione e trascrizione dall'API Google Drive. Con restrizioni

Il seguente ambito OAuth 2.0 adiacente a Meet si trova nell' elenco degli ambiti dell'API Google Drive:

Codice ambito Descrizione Utilizzo
https://www.googleapis.com/auth/drive.meet.readonly Visualizzare i file di Drive creati o modificati da Google Meet. Con restrizioni

La colonna Utilizzo nella tabella indica la sensibilità di ogni ambito, in base alle seguenti definizioni:

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, consulta l'articolo Utilizzare OAuth 2.0 per accedere alle API di Google.

Per definire le informazioni da mostrare agli utenti e ai revisori delle app, consulta Configurare la schermata per il consenso OAuth e scegliere gli ambiti.

Per ulteriori informazioni su ambiti OAuth 2.0 specifici, consulta Ambiti OAuth 2.0 per le API di Google.

Autentica e autorizza utilizzando la delega a livello di dominio

Se sei un amministratore di dominio, puoi concedere la delega dell'autorità a livello di dominio per autorizzare l'account di servizio di un'applicazione ad accedere ai dati dei tuoi utenti senza che sia necessario il consenso di ciascun utente. Dopo aver configurato la delega a livello di dominio, il service account può rubare l'identità di un account utente. Sebbene per l'autenticazione venga utilizzato un account di servizio, la delega a livello di dominio assume l'identità di un utente ed è quindi considerata autenticazione utente. Qualsiasi funzionalità che richiede l'autenticazione utente può utilizzare la delega a livello di dominio.