get google drive scope: drive.file to work with desktop applications

I had developed a desktop application using google drive API v3 back in march this year. google is recommending that I switch the scope from: "auth/drive" to "/auth/drive.file". I believe its to avoid the fee involved with security checks whenever you use any restricted scope.

As per the document at: https://support.google.com/cloud/answer/9110914?hl=en#zippy=%2Cdrive-api
pretty much all of the scopes for drive API are restricted scopes. This was not the case when I first started developing my application last year. this basically leaves me with "drive.file" scope which google is recommending. so now I am trying to figure out how this scope works,especially with a desktop application.

The Questions That I need Help with

1. How does the user give access to a file or folder when the application is using the scope: "drive.file" ?

some articles suggest that this can only be done when a user right clicks on a file or folder on their google drive account through the web interface and clicks on "Open With" and selects your application. Only then will your application get access to the end user's files and folders using the scope: "drive.file". is that correct ?

if it is then how will my desktop application show up in google market place when it has not even been verified yet ?

2. What is the purpose of the drive picker when all it does is the same thing as calling: https://accounts.google.com/o/oauth2/v2/auth and https://oauth2.googleapis.com/token and then working on the drive account using the scope assigned to it ?

Some articles suggested that using the drive picker allows the end users to select files which then can be worked on by applications which are using scope: "drive.file". this lead me to believe that drive picker would somehow act as a delegate handling all the restricted scope operations by itself while working on non-restricted scope but clearly that is not the case.

3. Does the file access that google drive picker gives out only meant to be used inside JS code thats part of a web application. Does it not setup access to application for files and folders that users select so next time when the application runs then it does not have to call the google picker and can straight away access the authorized file using the "drive.file" scope ?

I am trying to avoid using any restricted scope and stick to "drive.file". Any help on how to make this scope work is greatly appreciated. Thanks in advance.

My Setup

1. I have my original desktop client id which I have been using since march 2022.

2. I created a web app client id and have it setup by setting up the "hosts" file for 127.0.0.1 with my test domain: psg.mysite.com

3. I have also setup a API key which can work with google drive picker API.

4. copied the sample code from : https://developers.google.com/drive/picker/guides/sample and have it setup on node.js server listening to port 80

My Testing

1. Desktop Client ID + Scope:drive.file = [] empty file list ==>
   I use the desktop client id, scope: drive.file and drive API:list to get a list of files on one of my test google drive but all I got was an empty list which was expected with "drive.file" scope

2. Web app Client ID + API key + google picker + Scope:drive.file = [] empty file list ==>
   I use the google drive picker using my node.js server. the picker is configured with web app client id and API key generated above along with scope: drive.file (default was set to : "drive.metadata.readonly" but I changed it). I also added a small <p> tag in the default picker code so when I click on "authorize" then I get to see the generated access token

when the access token is generated on the picker page then I copy it and use it towards the REST API:list using POSTMAN and I get the same empty list [] as above and the google drive picker itself was also not able to show any files. it kept on saying that I need to sign into my google account and after two tries it gave errored out

3. Web app Client ID + API key + google picker + Scope:drive.metadata.readonly = Populated file list but error 403 on file download/read ==>
   I changed the scope in drive picker sample code from "drive.file" to its default scope "drive.metadata.readonly" and this time, as expected, the REST API:list gave out all the files present in the drive but the REST API: files/XXXXXX?alt=media gave out error code 403 saying : The user has not granted the app 71721436800 read access to the file XXXXX

4. Web app Client ID + API key + google picker + Scope:drive.metadata.readonly + File selected in google picker = Populated file list but error 403 on file download/read ==>
   I thought selecting the actual file that I need to download using the drive picker code would help so I did. The browser gave out the details of the selected file but when I used the generated access token on the google picker page against the REST API: /files/XXXXX?alt=media, I got the same error 403

5. Web app Client ID + API key + google picker + Scope:drive.readonly = Populated file list + successful file download/read
   I changed the scope in drive picker sample code again from its default scope of "drive.metadata.readonly" to "drive.readonly" and this time I was able to download/read the file.

Conclusion

1. the scope that you provide to google drive picker determines the access that you will get to the user's google drive account.

2. this is the same behavior that you would get if you call: https://accounts.google.com/o/oauth2/v2/auth to get the access code first and then exchange it for a access token from https://oauth2.googleapis.com/token and then use the access token to call the google drive REST API

After a few days of testing, I figured out that you do not need to publish your application on google marketplace in order for a user to be able to install your application on google drive via its web interface.

You can get an end user to install your application using the scope: https://www.googleapis.com/auth/drive.install. Just include this scope in your login request that your end users use like shown below:

https://accounts.google.com/o/oauth2/v2/auth?scope=https://www.googleapis.com/auth/drive.install https://www.googleapis.com/auth/drive.file https://www.googleapis.com/auth/drive.appdata &response_type=code&redirect_uri=http://localhost:80&client_id=XXXXXXXXX

when a user gives their consent to your login request then your application gets installed in their google drive automatically hence avoiding the need to go to google marketplace for app installation.

The next part is what I had problems with before. You would except that after the application has been installed then a user will be able to see your application in the "Open With" context menu but that is not how it works. You need to associate files types with your application in order for the application to show up in the "Open With" context menu and here is how you do this:

1. Log into https://console.cloud.google.com and then go to "APIs & Services" > "Enabled APIs & Service" and click on "Google Drive API"
   

2. Now click on "Drive UI Integration" menu
   

3. Scroll down to the "Authentication" section and then you need to type in all MIME files types one by one that your application will handle. I checked to see if a simple copy and paste from https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types would work but it does not. As far as I know you need to type in those MIME types manually one by one
   

4. The Same is needed to be done to "Extensions" as well
   

5. At the end you need to click on "submit" to save your settings and that is it. The end users will have to refresh their google drive web page in order for your application to show up in the "Open With" context menu

Please note: if a user right clicks on any file which has not been listed under "MIME types" or "Extensions" on your google cloud project then that file will not show your application in the "Open With" context menu