Meet REST API 요청 인증 및 승인
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
인증과 승인은 각각 ID와 리소스 액세스를 확인하는 데 사용되는 메커니즘입니다. 이 문서에서는 Google Meet REST API 요청의 인증 및 승인 작동 방식을 설명합니다.
이 가이드에서는 사용자의 Google 사용자 인증 정보로 OAuth 2.0을 사용하여 Meet REST API에 액세스하는 방법을 설명합니다. 사용자 인증 정보로 인증하고 승인하면 Meet 앱이 사용자 데이터에 액세스하고 인증된 사용자를 대신하여 작업을 실행할 수 있습니다. 사용자를 대신하여 인증하면 앱에 해당 사용자와 동일한 권한이 부여되며 해당 사용자가 작업을 실행한 것처럼 작업을 실행할 수 있습니다.
중요한 용어
다음은 인증 및 승인과 관련된 용어 목록입니다.
- 인증
사용자 또는 서비스 계정일 수 있는 주 구성원이
또는 사용자를 대신하여 행동하는 앱이 누구인지 확인합니다. Google Workspace 앱을 작성할 때는 사용자 인증과 앱 인증이라는 두 가지 유형의 인증을 알고 있어야 합니다. 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에서 생성 또는 수정한 Drive 파일을 확인합니다. |
제한됨 |
표의 사용 열은 다음 정의에 따라 각 범위의 민감도를 나타냅니다.
민감하지 않음: 이러한 범위는 가장 작은 승인 액세스 범위를 제공하며 기본 앱 인증만 필요합니다. 자세한 내용은 인증 요구사항을 참고하세요.
민감함: 이러한 범위는 사용자가 앱에 대해 승인한 특정 Google 사용자 데이터에 대한 액세스를 제공합니다. 추가 앱 인증을 거쳐야 합니다. 자세한 내용은 민감한 범위 및 제한된 범위 요구사항을 참고하세요.
제한됨: 이러한 범위는 Google 사용자 데이터에 대한 광범위한 액세스를 제공하며 제한된 범위 확인 절차를 거쳐야 합니다. 자세한 내용은 Google API 서비스 사용자 데이터 정책 및 특정 API 범위의 추가 요구사항을 참고하세요.
제한된 범위 데이터를 서버에 저장하거나 전송하는 경우 보안 평가를 거쳐야 합니다.
앱에 다른 Google API에 대한 액세스 권한이 필요한 경우 해당 범위도 추가할 수 있습니다. Google API 범위에 대한 자세한 내용은 OAuth 2.0을 사용하여 Google API에 액세스하기를 참고하세요.
사용자와 앱 검토자에게 표시되는 정보를 정의하려면 OAuth 동의 화면 구성 및 범위 선택을 참고하세요.
특정 OAuth 2.0 범위에 대한 자세한 내용은 Google API의 OAuth 2.0 범위를 참고하세요.
도메인 전체 위임을 사용하여 인증 및 승인
도메인 관리자는 도메인 전체 권한 위임을 부여하여 각 사용자의 동의 없이도 애플리케이션의 서비스 계정이 사용자 데이터에 액세스할 수 있도록 승인할 수 있습니다. 도메인 전체 위임을 구성한 후에는 서비스 계정이 사용자 계정을 가장할 수 있습니다.
서비스 계정이 인증에 사용되지만 도메인 전체 위임은 사용자를 가장하므로 사용자 인증으로 간주됩니다. 사용자 인증이 필요한 기능은 도메인 전체 위임을 사용할 수 있습니다.
달리 명시되지 않는 한 이 페이지의 콘텐츠에는 Creative Commons Attribution 4.0 라이선스에 따라 라이선스가 부여되며, 코드 샘플에는 Apache 2.0 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 Google Developers 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 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)."]]