About Authorization

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 to authorize requests. No other authorization protocols are supported. If your application uses 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. 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.

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

Scope	Meaning
https://www.googleapis.com/auth/drive	Full, permissive scope to access all of a user's files, excluding the Application Data folder. Request this scope only when it is strictly necessary.
https://www.googleapis.com/auth/drive.readonly	Allows read-only access to file metadata and file content
https://www.googleapis.com/auth/drive.appfolder	Allows access to the Application Data folder
https://www.googleapis.com/auth/drive.file	Per-file access to files created or opened by the app. File authorization is granted on a per-user basis and is revoked when the user deauthorizes the app.
https://www.googleapis.com/auth/drive.install	Special scope used to let users approve installation of an app.
https://www.googleapis.com/auth/drive.metadata	Allows read-write access to file metadata (excluding downloadUrl and 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/drive.metadata.readonly	Allows read-only access to file metadata (excluding downloadUrl and contentHints.thumbnail), but does not allow any access to read or download file content
https://www.googleapis.com/auth/drive.scripts	Allows access to Apps Script files
https://www.googleapis.com/auth/drive.apps.readonly	Allows read-only access to installed apps.

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.

What scope or scopes does my app need?

As a general rule, choose the most restrictive scope possible, and avoid requesting scopes that your app does not actually need. Users more readily grant access to limited, clearly described scopes. Conversely, users may hesitate to grant broad access to their files unless they truly trust your app and understand why it needs the information.

The scope https://www.googleapis.com/auth/drive.file strikes this balance in a practical way. Presumably, users only open or create a file with an app that they trust, for reasons they understand.

Requesting full drive scope for an app

Full access to all files in the user's Drive (https://www.googleapis.com/auth/drive) may be necessary for some apps. An app designed to sync files, for instance, needs this level of access to Drive. Apps with special needs related to listing or reorganizing files might need full scope.

Requesting drive-wide read-only scope for an app

Read-only access to all of a user's Drive files (https://www.googleapis.com/auth/drive.readonly) may be useful for certain apps. For instance, a photo browser might need to reorganize image files in a unique presentation order for a slideshow, or a mobile app might have to work around unique display constraints without needing to write anything. For apps that only need to read file metadata for all files in Drive, there's https://www.googleapis.com/auth/drive.metadata.readonly.

Requesting full drive scope during app development

One common and completely valid case for using full scope is iterative development. It may just be easier to avoid authorization-related constraints and use the full scope while testing your app during development. Then before you actually publish your app, you can back off to the file-level scope or whatever scope you really need for production operation.

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).

Tip: The Google APIs client libraries can handle some of the authorization process for you. They are available for a variety of programming languages; check the page with libraries and samples for more details.

Perform 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.

Warning: Service accounts should only be used for performing delegation where the effective identity is that of an individual user in a domain. Using the service account as a common owner to create many shared documents can have severe performance implications. Additionally, service accounts may not acquire additional 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