Authenticate and authorize Meet REST API requests

Authentication and authorization are mechanisms used to verify identity and access to resources, respectively. This document outlines how authentication and authorization work for Google Meet REST API requests.

This guide explains how to use OAuth 2.0 with a user's Google credentials to access the Meet REST API. Authenticating and authorizing with user credentials lets Meet apps access user data and perform operations on the authenticated user's behalf. By authenticating on a user's behalf, the app has the same permissions as that user and can perform actions as if they were performed by that user.

Important terminology

The following is a list of terms related to authentication and authorization:

Authentication

The act of ensuring that a principal, which can be a user

or an app acting on behalf of a user, is who they say they are. When writing Google Workspace apps, you should be aware of these types of authentication: user authentication and app authentication. For Meet REST API, you can only authenticate using user authentication.

Authorization

The permissions or "authority" the principal has to access

data or perform operations. The authorization is done through code you write in your app. This code informs the user that the app wishes to act on their behalf and, if allowed, uses your app's unique credentials to obtain an access token from Google to access data or perform operations.

Meet REST API scopes

Authorization scopes are the permissions that you request users to authorize for your app to access the meeting content. When someone installs your app, the user is asked to validate these scopes. Generally, you should choose the most narrowly focused scope possible and avoid requesting scopes that your app doesn't require. Users more readily grant access to limited, clearly described scopes.

The Meet REST API supports the following OAuth 2.0 scopes:

Scope code Description Usage
https://www.googleapis.com/auth/meetings.space.readonly Allow apps to read metadata about any meeting space the user has access to. Sensitive
https://www.googleapis.com/auth/meetings.space.created Allow apps to create, modify, and read metadata about meeting spaces created by your app. Sensitive
https://www.googleapis.com/auth/drive.readonly Allow apps to download recording and transcript files from Google Drive API. Restricted

The following Meet-adjacent OAuth 2.0 scope resides in the Google Drive API scopes list:

Scope code Description Usage
https://www.googleapis.com/auth/drive.meet.readonly View Drive files created or edited by Google Meet. Restricted

The Usage column in the table indicates the sensitivity of each scope, according to the following definitions:

  • Sensitive: These scopes provide access to specific Google user data that's authorized by the user for your app. It requires you to go through additional app verification. For information on this requirement, see Sensitive and Restricted Scope Requirements.

  • Restricted: These scopes provide wide access to Google user data and require you to go through a restricted scope verification process. For information on this requirement, see Google API Services User Data Policy and Additional Requirements for Specific API Scopes. If you store restricted scope data on servers (or transmit), then you must go through a security assessment.

If your app requires access to any other Google APIs, you can add those scopes as well. For more information about Google API scopes, see Using OAuth 2.0 to Access Google APIs.

To define what information is displayed to users and app reviewers, see Configure the OAuth consent screen and choose scopes.

For more information about specific OAuth 2.0 scopes, see OAuth 2.0 Scopes for Google APIs.

Authenticate and authorize using domain-wide delegation

If you're a domain administrator, you can grant domain-wide delegation of authority to authorize an application's service account to access your users' data without requiring each user to give consent. After you configure domain-wide delegation, the service account can impersonate a user account. Although a service account is used for authentication, domain-wide delegation impersonates a user and is therefore considered user authentication. Any capability that requires user authentication can use domain-wide delegation.