24/09/2020 Authenticate your users | Google Drive API | Google Developers

Authenticate your users

Every request your application sends to the Drive API must include an authorization token. The token also identifies your
application to Google.

About authorization protocols

Your application must use OAuth 2.0 (https://developers.google.com/identity/protocols/OAuth2) to authorize requests. No other

authorization protocols are supported. If your application uses Google Sign-In (https://developers.google.com/identity/#google-sign-in)
, some aspects of authorization are handled for you.

Authorizing requests with OAuth 2.0

All requests to the Drive API must be authorized by an authenticated user.

The details of the authorization process, or "flow," for OAuth 2.0 vary somewhat depending on what kind of application you're
writing. The following general process applies to all application types:

1. When you create your application, you register it using the Google API Console (https://console.developers.google.com/). Google
then provides information you'll need later, such as a client ID and a client secret.

2. Activate the Drive API in the Google API Console. (If the API isn't listed in the API Console, then skip this step.)

3. When your application needs access to user data, it asks Google for a particular scope of access.

4. Google displays a consent screen to the user, asking them to authorize your application to request some of their data.

5. If the user approves, then Google gives your application a short-lived access token.

6. Your application requests user data, attaching the access token to the request.

7. If Google determines that your request and the token are valid, it returns the requested data.

Some flows include additional steps, such as using refresh tokens to acquire new access tokens. For detailed information about
flows for various types of applications, see Google's OAuth 2.0 documentation
 (https://developers.google.com/identity/protocols/OAuth2).

Here's the OAuth 2.0 scope information for the Drive API:

Scope Meaning Usage

https://www.googleapis.com/auth/ Allows access to the Application Data folder. (/drive/api/v3/appdata) Recommended

drive.appdata

https://www.googleapis.com/auth/ Per-file access to files created or opened by the app. File authorization is Recommended
drive.file granted on a per-user basis and is revoked when the user deauthorizes the app.

https://www.googleapis.com/auth/ Special scope used to let users approve installation of an app, and scope needs Recommended
drive.install to be requested.

https://www.googleapis.com/auth/ Allows read-only access to installed apps. Sensitive

drive.apps.readonly

https://www.googleapis.com/auth/ Allows read-write access to file metadata (excluding downloadUrl and Restricted
drive.metadata contentHints.thumbnail), but does not allow any access to read,
download, write or upload file content. Does not support file creation, trashing
or deletion. Also does not allow changing folders or sharing in order to prevent
access escalation.

https://www.googleapis.com/auth/ Full, permissive scope to access all of a user's files, excluding the Application Restricted
drive Data folder (/drive/web/appdata).

https://www.googleapis.com/auth/ Allows read and write access to the Drive Activity API. Restricted
drive.activity

https://developers.google.com/drive/api/v3/about-auth 1/4
24/09/2020 Authenticate your users | Google Drive API | Google Developers

https://www.googleapis.com/auth/ Allows read-only access to the Drive Activity API. Restricted

drive.activity.readonly

https://www.googleapis.com/auth/ Allows read-only access to file metadata and file content. Restricted
drive.readonly

https://www.googleapis.com/auth/ Allows read-only access to file metadata (excluding downloadUrl and Restricted
drive.metadata.readonly contentHints.thumbnail), but does not allow any access to read or
download file content.

https://www.googleapis.com/auth/ Allows access to Apps Script (/apps-script) files. Restricted

drive.scripts

Where:

Recommended - These scopes provides the smallest scope of authorization access and does not require any app
verification or security assessment.

Sensitive - These scopes allow access to Google User Data and require a sensitive scope verification process. For
information on this requirement, see Google API Services: User Data Policy
 (https://developers.google.com/terms/api-services-user-data-policy). These scopes do not require a security assessment.

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
 (https://developers.google.com/terms/api-services-user-data-policy) and Additional Requirements for Specific API Scopes
 (https://developers.google.com/terms/api-services-user-data-policy#additional-requirements-for-specific-api-scopes). If you store
restricted scope data on servers (or transmit), then you need to go through a security assessment.

Save refresh tokens in long-term storage

You must save refresh tokens in secure long-term storage and continue to use them as long as they remain valid. All Drive apps
should treat all "Create New" and "Open with" events like potential logins.

For more details, see Handle Create New and Open With events (/drive/api/v3/about-auth#potential-logins).

The next section helps you to determine what scopes to use and where to go if you need verification or a security assessment.

Select scopes for a new app

When your app is installed, a user is asked to validate the scopes used by the app. Generally, you do not want users to have to
decide to validate use of restricted scopes. So, when possible, use "recommended" scopes as they narrow access to specific
functionality needed by an app. In most cases, providing narrow access means using the
https://www.googleapis.com/auth/drive.file per-file access scope.

There are only two types of apps where use of restricted scopes might be permitted:

Use of restricted scopes might be permitted for native and web apps that provide local sync or automatic backup of users’
Drive files.

Use of restricted scopes might be permitted for productivity and educational applications whose user interface might
involve interaction with Google Drive. For example, if your app is a chat app that allows a user to paste Drive URL in a
discussion, restricted scopes might be permitted. Productivity applications include task management, note taking,
workgroup communications, and classroom collaboration applications.

If you believe your app requires a restricted scope, refer to Request restricted scope verification and security assessment
 (#assessment).

If you believe your app requires a sensitive scope, refer to How do I submit for verification?
 (https://support.google.com/cloud/answer/9110914#submit-howto).

https://developers.google.com/drive/api/v3/about-auth 2/4
24/09/2020 Authenticate your users | Google Drive API | Google Developers

If you are creating a Google Drive app for use only within your company, you can use restricted scopes without requiring a restricted scope verificatio
ty assessment. Your G Suite administrator has control of your users’ apps and has the ability to whitelist apps as needed for your business. For more
s about whitelists, see Whitelist connected apps (https://support.google.com/a/answer/7281227).

Request restricted scope veri cation and security assessment

For apps using restricted scopes, a restricted scope verification must be performed to comply with the Google API Services: User
Data Policy (https://developers.google.com/terms/api-services-user-data-policy) and Additional Requirements for Specific API Scopes
 (https://developers.google.com/terms/api-services-user-data-policy#additional-requirements-for-specific-api-scopes).

If you store restricted scope data on servers (or transmit), then you need to go through a security assessment. To ensure
confidentiality of your application, Google uses third-party vendors to conduct the security assessment.

1. To request a restricted scope verification, see How do I submit for verification?

 (https://support.google.com/cloud/answer/9110914#submit-howto).

2. Upon passing the restricted scope verification, you are sent an email with third-party security assessors who you can use to
perform your security assessment.

For frequently asked questions about restricted scope verification and the security assessment, refer to OAuth API Application
Verification FAQ (https://support.google.com/cloud/answer/9110914).

If your app does not get approved by the restricted scope verification or security assessment, it is subject to the user cap. For more details, see Unver
(https://support.google.com/cloud/answer/7454865).

Migrate an existing app to a recommended scope

If your app currently uses full Drive scopes, and you want to limit the range of authorization for your app users, you can update
your app to use the https://www.googleapis.com/auth/drive.file recommended scope.

If you've developed a Drive app that uses any of the restricted scopes, we recommend migrating your app to use drive.file
scope. This scope enables users to select the specific files from Google Drive, and through the Google Picker, that they want to
allow your app to access. Apps that use the drive.file scope are not required to go through the restricted scope verification
and third-party security assessment.

Many apps work with per-file access without any changes. If you are currently using your own file picker, we recommend
switching to the Google file picker (/drive/api/v3/picker) which fully supports the drive.file scope.

Add scopes to access other Google APIs

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 (/accounts/docs/OAuth2).

To request access using OAuth 2.0, your application needs the scope information, as well as information that Google supplies
when you register your application (such as the client ID and the client secret).

he Google APIs client libraries can handle some of the authorization process for you. They are available for a variety of programming languages; chec
with libraries and samples (/api-client-library) for more details.

Authenticate users

Use OAuth 2.0 (/identity/protocols/OAuth2) and Google's identity APIs (/identity) to authenticate new and existing users. Whenever
you can avoid it, don't require users to create new passwords for your application.

https://developers.google.com/drive/api/v3/about-auth 3/4
24/09/2020 Authenticate your users | Google Drive API | Google Developers

Handle Create New and Open With events

All Drive apps should treat all "Create New" and "Open with" events like potential logins. Some users may have multiple accounts.
If the user ID in the state parameter does not match the current session, you may need to end the current session for your app
and log in as the requested user.

Handle declined access requests

Users can click No Thanks in the OAuth dialog to decline your app access to their files. If a user declines access, catch the
access_denied string in the query parameter error and display a user-friendly response. For example, you could present a
friendly parting message with a link to your privacy policy and a meaningful explanation of why your app needs certain
information. You can also provide a link back to the OAuth flow.

Pe orm G Suite Domain-Wide Delegation of Authority

In enterprise applications you may want to programmatically access users data without any manual authorization on their part.
In G Suite domains, the domain administrator can grant to third party applications domain-wide access to its users' data — this is
referred as domain-wide delegation of authority. To delegate authority this way, domain administrators can use service accounts
with OAuth 2.0.

ng: Service accounts should only be used for performing delegation where the effective identity is that of an individual user in a domain. Using the se
nt as a common owner to create many shared documents can have severe performance implications. Additionally, service accounts may not acquire
onal storage quota, nor do they act as members of a domain.

For additional detailed information, see Using OAuth 2.0 for Server to Server Applications (/identity/protocols/OAuth2ServiceAccount)

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License
 (https://creativecommons.org/licenses/by/4.0/), and code samples are licensed under the Apache 2.0 License
 (https://www.apache.org/licenses/LICENSE-2.0). For details, see the Google Developers Site Policies (https://developers.google.com/site-policies).
Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2020-02-27 UTC.

https://developers.google.com/drive/api/v3/about-auth 4/4