Meet REST API リクエストの認証と承認
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
認証と認可は、それぞれ ID とリソースへのアクセスを検証するために使用されるメカニズムです。このドキュメントでは、Google Meet REST API リクエストの認証と認可の仕組みについて説明します。
このガイドでは、ユーザーの Google 認証情報で OAuth 2.0 を使用して Meet REST API にアクセスする方法について説明します。ユーザー認証情報を使用して認証と認可を行うと、Meet 用アプリはユーザーデータにアクセスし、認証されたユーザーの代わりにオペレーションを実行できます。ユーザーの代わりに認証を行うことで、アプリはユーザーと同じ権限を持ち、ユーザーが実行したかのようにアクションを実行できます。
重要な用語
認証と認可に関連する用語の一覧は次のとおりです。
- 認証
ユーザーなどのプリンシパルが、
またはユーザーに代わって動作するアプリが、そのユーザーであるかどうかを確認します。Google Workspace アプリを作成する際は、ユーザー認証とアプリ認証という 2 種類の認証について理解しておく必要があります。Meet REST API の場合、ユーザー認証を使用してのみ認証できます。
- 認可
プリンシパルがアクセスできる権限または「権限」
データを取得したり、オペレーションを実行したりできます。認証は、アプリで記述したコードを通じて行われます。このコードは、アプリがユーザーに代わって操作を行うことをユーザーに通知し、許可された場合は、アプリの一意の認証情報を使用して Google からアクセス トークンを取得し、データにアクセスしたりオペレーションを実行したりします。
REST API スコープについて
認可スコープは、会議のコンテンツにアクセスするためにアプリの認可をユーザーにリクエストする権限です。アプリをインストールする際に、ユーザーはこれらのスコープを検証するよう求められます。一般的に、できる限り狭い範囲のスコープを選択し、アプリで必要ないスコープはリクエストしないようにします。ユーザーは、明確に説明された限定的なスコープに対してアクセス権限を付与する傾向があります。
Meet REST API は、次の OAuth 2.0 スコープをサポートしています。
| スコープコード |
説明 |
用途 |
https://www.googleapis.com/auth/meetings.space.settings |
編集および Google Meet 通話すべての設定の表示。 |
機密情報ではない |
https://www.googleapis.com/auth/meetings.space.created |
アプリで作成した会議スペースに関するメタデータの作成、変更、読み取りをアプリに許可します。 |
デリケートなコンテンツ |
https://www.googleapis.com/auth/meetings.space.readonly |
ユーザーがアクセスできる会議スペースに関するメタデータをアプリが読み取れるようにします。 |
デリケートなコンテンツ |
https://www.googleapis.com/auth/drive.readonly |
アプリが Google Drive API から録音ファイルと文字起こしファイルをダウンロードできるようにします。 |
制限付き |
次の Meet 関連の OAuth 2.0 スコープは、
Google Drive API スコープのリストにあります。
| スコープコード |
説明 |
用途 |
https://www.googleapis.com/auth/drive.meet.readonly |
Google Meet で作成または編集されたドライブ ファイルの参照。 |
制限付き |
表の [使用状況] 列は、次の定義に従って、各スコープの機密性を示します。
センシティブでない: これらのスコープは、最小限の認可アクセスを提供し、基本的なアプリの確認のみを必要とします。詳しくは、確認の要件をご覧ください。
機密情報: これらのスコープは、ユーザーがアプリに対して承認した特定の Google ユーザーデータへのアクセスを提供します。追加のアプリ検証を受ける必要があります。詳しくは、機密情報と制限付きスコープの要件をご覧ください。
制限付き: これらのスコープは Google ユーザーデータへの広範なアクセスを提供するため、制限付きスコープの確認プロセスを完了する必要があります。詳しくは、Google API サービスのユーザーデータに関するポリシーと特定の API スコープの追加要件をご覧ください。制限付きスコープのデータをサーバーに保存（または送信）する場合は、セキュリティ評価を受ける必要があります。
アプリが他の Google API へのアクセスを必要とする場合は、それらのスコープも追加できます。Google API スコープの詳細については、OAuth 2.0 を使用した Google API へのアクセスをご覧ください。
ユーザーとアプリの審査担当者に表示する情報を定義するには、OAuth 同意画面を構成し、スコープを選択するをご覧ください。
特定の OAuth 2.0 スコープの詳細については、Google API の OAuth 2.0 スコープをご覧ください。
ドメイン全体の委任を使用して認証と認可を行う
ドメイン管理者は、ドメイン全体の権限委任を付与して、アプリケーションのサービス アカウントがユーザーの同意を必要とせずにユーザーのデータにアクセスできるようにすることができます。ドメイン全体の委任を構成すると、サービス アカウントはユーザー アカウントの権限を借用できます。サービス アカウントは認証に使用されますが、ドメイン全体の委任はユーザーを偽装するため、ユーザー認証と見なされます。ユーザー認証を必要とする機能は、ドメイン全体の委任を使用できます。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-08-29 UTC。
[null,null,["最終更新日 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)."]]
