Аутентификация и авторизация — это механизмы, используемые для проверки личности и доступа к ресурсам соответственно. В этом документе описывается, как работают аутентификация и авторизация для запросов REST API Google Meet.
В этом руководстве объясняется, как использовать OAuth 2.0 с учетными данными пользователя Google для доступа к Meet REST API . Аутентификация и авторизация с использованием учетных данных пользователя позволяет приложениям Meet получать доступ к пользовательским данным и выполнять операции от имени аутентифицированного пользователя. Проходя аутентификацию от имени пользователя, приложение имеет те же разрешения, что и этот пользователь, и может выполнять действия, как если бы они были выполнены этим пользователем.
Важная терминология
Ниже приведен список терминов, связанных с аутентификацией и авторизацией:
- Аутентификация
- Проверка того, что принципал , которым может быть пользователь или приложение, действующее от имени пользователя, является тем, кем он себя называет. При написании приложений Google Workspace вы должны знать о следующих типах аутентификации: аутентификация пользователя и аутентификация приложения. Для Meet REST API вы можете пройти аутентификацию только с помощью аутентификации пользователя.
- Авторизация
- Разрешения или «полномочия», которые принципал имеет для доступа к данным или выполнения операций. Авторизация осуществляется с помощью кода, который вы пишете в своем приложении. Этот код сообщает пользователю, что приложение желает действовать от его имени, и, если это разрешено, использует уникальные учетные данные вашего приложения для получения токена доступа от Google для доступа к данным или выполнения операций.
- Сервисный аккаунт
- Особый тип учетной записи Google, предназначенный для представления пользователя, не являющегося человеком, которому необходимо пройти аутентификацию и авторизоваться для доступа к облачным данным и операциям. Ваше приложение предполагает идентификацию учетной записи службы для вызова API Google, поэтому пользователи не участвуют напрямую. Сами по себе сервисные учетные записи не могут использоваться для доступа к пользовательским данным. Однако сервисный аккаунт может получить доступ к пользовательским данным, реализовав делегирование полномочий на уровне домена . Подробности см. в разделе Обзор учетных записей служб .
- Делегирование полномочий на уровне домена
- Функция администрирования, которая может разрешить приложению доступ к пользовательским данным от имени пользователей в организации Google Workspace. Делегирование на уровне домена можно использовать для выполнения задач администрирования над пользовательскими данными. Чтобы таким образом делегировать полномочия, администраторы Google Workspace используют сервисные аккаунты с OAuth 2.0. Благодаря возможностям этой функции только суперадминистраторы домена могут включить делегирование полномочий на уровне домена. Дополнительные сведения см. в разделе Делегирование полномочий на уровне домена сервисному аккаунту .
Соответствие областям 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. | Ограниченный |
Столбец «Использование» в таблице указывает чувствительность каждой области в соответствии со следующими определениями:
Рекомендуемый/конфиденциальный : эти области обеспечивают доступ к определенным пользовательским данным Google, которые разрешены пользователем для вашего приложения. Вам потребуется пройти дополнительную проверку приложения. Информацию об этом требовании см. в разделе «Требования к конфиденциальной информации и ограниченной области применения» .
Ограничено : эти области обеспечивают широкий доступ к пользовательским данным Google и требуют от вас пройти процесс проверки с ограниченной областью. Информацию об этом требовании см. в разделе «Политика пользовательских данных служб Google API» и «Дополнительные требования для конкретных областей API» . Если вы храните данные ограниченного объема на серверах (или передаете), вам необходимо пройти оценку безопасности.
Если вашему приложению требуется доступ к каким-либо другим API Google, вы также можете добавить эти области. Дополнительную информацию об областях API Google см. в разделе Использование OAuth 2.0 для доступа к API Google .
Чтобы определить, какая информация будет отображаться для пользователей и рецензентов приложений, см. раздел Настройка экрана согласия OAuth и выбор областей .
Дополнительную информацию о конкретных областях действия OAuth 2.0 см. в разделе «Области действия OAuth 2.0 для API Google» .
Аутентификация и авторизация с использованием делегирования на уровне домена
Если вы администратор домена, вы можете делегировать полномочия на уровне домена, чтобы разрешить сервисному аккаунту приложения доступ к данным ваших пользователей, не требуя согласия каждого пользователя. После настройки делегирования на уровне домена учетная запись службы может выдавать себя за учетную запись пользователя . Хотя для аутентификации используется учетная запись службы, делегирование на уровне домена олицетворяет пользователя и поэтому считается аутентификацией пользователя. Любая возможность, обеспечивающая аутентификацию пользователя, может использовать делегирование на уровне домена.
похожие темы
Обзор аутентификации и авторизации в Google Workspace см. в статье Подробнее об аутентификации и авторизации .
Обзор аутентификации и авторизации в Google Cloud см. в разделе Методы аутентификации в Google .