2
votes

When I sign in an app via Dropbox, it says:

ABC would like access to its own folder, Apps › ABC (emphasis mine)

This is to sign, that the app, ABC, can access only its folder.

However, this folder is normally visible in the Dropbox directory and synced.

Is there a way to achieve this with Google Drive? It seems like using the app-specific data feature prevents users from using the directory in any way except the app. Granting a permission to use the whole Google Drive gives the app way too much permissions. Dropbox has this feature done well. IS there a way to do a sing-up process this way with Google Drive?

2
You want to access to a limited folder on Google Drive using an application. If my understanding is correct, how about using the scope of https://www.googleapis.com/auth/drive.file with Drive API? Ref By using this, the application can access to only the folders and files created by the application. And also, when the service account is used, you can also use the limited drive. But I'm not sure whether this is the direction you want. So I posted this as a comment. If this was not the direction you want, I apologize. - Tanaike

2 Answers

1
votes

When your ABC app calls Google Drive APIs on behalf of a user, you're going to be using oAuth to authorize ABC. From Drive API v3 docs:

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:

  • When your application needs access to user data, it asks Google for a particular scope of access.
  • Google displays a consent screen to the user, asking them to authorize your application to request some of their data.

Google Drive's resource authorization scheme includes a number of "permissive" scopes where your app can (for example) request access to the user's entire Drive and "narrow" scopes. In the latter case your app is restricted to certain Drive files and/or folders. In late 2018 Google announced Project Strobe that promised to tighten restrictions around "permissive" scopes for many Google services, including Drive. In May 2019, they rolled an updated policy for Drive APIs:

With this updated policy, we’ll limit the types of apps that have broad access to content or data via Drive APIs. Apps should move to a per-file user consent model, allowing users to more precisely determine what files an app is allowed to access. This means that only certain types of apps can request restricted scopes from consumer Google accounts. As always, G Suite administrators are in control of their users’ apps.

The more user-friendly, narrower scopes are tagged and referred to as Recommended throughout Google API docs. For Drive you have 3 recommended scopes :

  • 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, and scope needs to be requested

Your use case could fall into either drive.appfolder or drive.file scope. drive.appfolder works well if you're looking to store app-specific data that the user won't and shouldn't touch:

The application data folder is a special hidden folder that your app can use to store application-specific data, such as configuration files. The application data folder is automatically created when you attempt to create a file in it. Use this folder to store any files that the user shouldn't directly interact with. This folder is only accessible by your application and its contents are hidden from the user and from other Drive apps.

The application data folder is deleted when a user uninstalls your app from their MyDrive. Users can also delete your app's data folder manually.

drive.file is applicable if your use case has to do with some data being created by your app on behalf of the user and the user or other users should be able to see/edit/share these documents. The issue with drive.file is that it only applies to "objects" your app creates. If your ABC app creates folder Foo and then creates some files within that folder, your app will be able to access the folder and these and only these files.

With drive.file there's no parent/child ownership semantics and no propagation of permissions from parent to child. The user (in their own browser without your app) could create more files in the Foo folder but your app won't be able to read them.

It's worth noting that drive.file is not granting access to a particular folder...but it sort of amounts to an equivalent end result for a to-be-created (by your app) folder or folders.

If you're looking for a way to get access to an existing folder, you may want to look into one of the Sensitive or Restricted scopes. Using one of these scopes requires your app to go through a security review.

0
votes

Most apps only have permission to store data in the Application Data folder

There is more information about API permissions at About Authorization

The drive.file scope might work for some since it appears to give access to individual files that the user OK'd. How does the user OK a file? According to the post below, they would send a file from the Drive app to my app.

So, unlike Dropbox or OneDrive, Google Drive has only 2 types of permissions: Drive or Drive.File. Simple!