Аутентификация и авторизация запросов REST API Meet

Аутентификация и авторизация — это механизмы, используемые для проверки личности и доступа к ресурсам соответственно. В этом документе описывается, как работают аутентификация и авторизация для запросов REST API Google Meet.

В этом руководстве объясняется, как использовать OAuth 2.0 с учетными данными пользователя Google для доступа к Meet REST API . Аутентификация и авторизация с использованием учетных данных пользователя позволяет приложениям Meet получать доступ к пользовательским данным и выполнять операции от имени аутентифицированного пользователя. Проходя аутентификацию от имени пользователя, приложение имеет те же разрешения, что и этот пользователь, и может выполнять действия, как если бы они были выполнены этим пользователем.

Важная терминология

Ниже приведен список терминов, связанных с аутентификацией и авторизацией:

Аутентификация

Действие по обеспечению того, чтобы принципал , который может быть пользователем

или приложение, действующее от имени пользователя, является тем, кем он себя называет. При написании приложений Google Workspace вы должны знать о следующих типах аутентификации: аутентификация пользователя и аутентификация приложения. Для Meet REST API вы можете пройти аутентификацию только с помощью аутентификации пользователя.

Авторизация

Разрешения или «полномочия», к которым имеет доступ принципал.

данные или выполнять операции. Авторизация осуществляется с помощью кода, который вы пишете в своем приложении. Этот код сообщает пользователю, что приложение желает действовать от его имени, и, если это разрешено, использует уникальные учетные данные вашего приложения для получения токена доступа от Google для доступа к данным или выполнения операций.

Соответствие областям REST API

Области авторизации — это разрешения, которые вы запрашиваете у пользователей для авторизации вашего приложения для доступа к содержимому собрания. Когда кто-то устанавливает ваше приложение, пользователю предлагается проверить эти области. Как правило, вам следует выбирать максимально узконаправленную область действия и избегать запроса областей, которые не требуются вашему приложению. Пользователи с большей готовностью предоставляют доступ к ограниченным, четко описанным областям.

API REST Meet поддерживает следующие области действия OAuth 2.0:

Код области действия Описание Использование
https://www.googleapis.com/auth/meetings.space.readonly Разрешите приложениям считывать метаданные о любом пространстве для встреч, к которому у пользователя есть доступ. Чувствительный
https://www.googleapis.com/auth/meetings.space.created Разрешите приложениям создавать, изменять и читать метаданные о пространствах для встреч, созданных вашим приложением. Чувствительный
https://www.googleapis.com/auth/drive.readonly Разрешить приложениям загружать файлы записей и расшифровок из Google Drive API. Ограниченный

Следующая область действия OAuth 2.0, связанная с Meet, находится в списке областей API Google Диска :

Код области действия Описание Использование
https://www.googleapis.com/auth/drive.meet.readonly Просматривайте файлы на Диске, созданные или отредактированные с помощью Google Meet. Ограниченный

Столбец «Использование» в таблице указывает чувствительность каждой области в соответствии со следующими определениями:

Если вашему приложению требуется доступ к каким-либо другим API Google, вы также можете добавить эти области. Дополнительную информацию об областях API Google см. в разделе Использование OAuth 2.0 для доступа к API Google .

Чтобы определить, какая информация будет отображаться для пользователей и рецензентов приложений, см. раздел Настройка экрана согласия OAuth и выбор областей .

Дополнительную информацию о конкретных областях действия OAuth 2.0 см. в разделе «Области действия OAuth 2.0 для API Google» .

Аутентификация и авторизация с использованием делегирования на уровне домена

Если вы администратор домена, вы можете делегировать полномочия на уровне домена , чтобы разрешить сервисному аккаунту приложения доступ к данным ваших пользователей, не требуя согласия каждого пользователя. После настройки делегирования на уровне домена учетная запись службы может выдавать себя за учетную запись пользователя . Хотя для аутентификации используется учетная запись службы, делегирование на уровне домена выдает себя за пользователя и поэтому считается аутентификацией пользователя . Любая возможность, требующая аутентификации пользователя, может использовать делегирование на уровне домена.