Drive API Auth Scope Changes - Handling Changing/Remvoing Scopes

[movieghost]

I have an application that is somewhat old.  The application uses Google Drive API, and offline access, to provide a "widget" of sorts for my customers on their websites.  Our CMS allows a user to select a folder from their Drive, then on the website a list of files/sub-folders for the selected folder are displayed.  Our application has a bunch of other integrations, but my current problem is with the changing of the Google Drive API auth scopes.

Our application mainly uses "Get" and "List" functions from the API.  When our application was originally written those functions required "https://www.googleapis.com/auth/drive" and "https://www.googleapis.com/auth/drive.readonly" auth scopes.  We configured everything with those, and our application was approved.  Now, I have hundreds of users on my system that have connections to their Google accounts, with offline access and refresh tokens.

Now those auth scopes are Restricted and my application is going to go unverified (which is my understanding that all those tokens will be revoked when that occurs).  I have looked over the new auth scopes, and the new way of doing what I am doing, and I think I can safely use "https://www.googleapis.com/auth/drive.file" auth scope, as our system uses the Google Picker to have the user select the file or folder, and thus we would be able to get the information required (which is only the name of the file, and the list of files within a folder).

So, what I am trying to solve, is I would like to move our application to the "https://www.googleapis.com/auth/drive.file" auth scope, but I don't know how to handle all the offline tokens I currently have that were authorized with the original (now) Restricted scopes.

It seems, after looking at a bunch of help docs and forums that my only real recourse is to get every user to log into my system, and reauthorize their account with the new scopes.  Then after every authorization is updated, then remove the Restricted scopes from my application.  Either that, or try and get my application verified with the Restricted scopes in place.

Are there any thoughts or ideas on how to solve my issue?

Thanks in advance for any help,

Josh

[nextlevelwebapp]

Hi Josh, I've run into a similar issue.  My workspace addon app created a folder, then copied a template spreadsheet, and organized it into that folder.  I was leveraging the "https://www.googleapis.com/auth/drive" scope, which I have also recently been told that has become restricted. 

There were several problems that I ran into when trying to convert to the unrestricted scopes.  I found that if I used the Drive Service API, I could create a folder, then create a blank spreadsheet and organize it into that folder, but then the document was inaccessible by Apps Script since it wasn't created by that mechanism.

I could create a spreadsheet with Apps Script and not organize it into any folder (just default to the root My Drive), but I couldn't use the copy method and had to build the template spreadsheet from scratch.  That wouldn't have been a big deal, but there was minimal code in the container bound script that got copied during the copy process, which also had an installed library.  That code was used to listen to the webhook so that the user could receive text message responses in their sheet (it's a text message app).  The complication to accomplish all of that programmatically so far feels like too tall of an order, and I'm currently looking at the possibility of having to de-list it from the marketplace.

'Luckily' the app has not been that successful, as it looks like this new requirement might be the death of it.  I don't have a spare $15k+ lying around for the CASA certification, nor the time to go through that (really fun sounding) journey.  There might be other ways of solving it, but I haven't been able to find any so far.

I've been developing a new add-on that doesn't use the DriveApp, but this experience has me concerned that we will get another rug pull in the future.  For example, I'm using the People API.  The scopes aren't terribly granular on that, so I'm worried that they will make that restricted at some point for 'broad access to contacts' and put us right back in this same situation again.

I'm sorry that I don't have a solution for your question on offline tokens, but wanted to share my story in case it helped bring awareness to the situation that you and other developers are facing right now.

[movieghost]

Thanks for the insight.  I have gone through the whole process now, and there is no answer to my question, but I appreciate the answer.  I actually had to remove the functionality from the application, because using "drive.file", then selecting a folder, doesn't give you access to what documents are in that folder.  It only gives access to the folder itself.  We are thinking about possibly using service accounts to give us the access we need to make the feature work, but haven't actually tried it yet, so not sure if that will work.

Good luck in your endeavors.  I feel your pain, it's hard when you become so dependent upon a 3rd party, and that 3rd party changes something.

[movieghost · Accepted solution]

I am going to leave a response to my own question as I have now gone through the whole process and am out the other side.  I know it was really cryptic for me on what the process would actually be, so I hope this helps someone who sees this in the future.

The problem we faced was that Google change most of the Google Drive auth scopes to restricted.  We were using them for some functionality in our software.  As a side note, if you read my post, the "drive.file" auth scope didn't work at all for the functionality we were using it for, so we actually had to pull the functionality from the software.

So, because of the auth changes our app came under review, and was going to be unverified within 90 days.  I went through the app verification process trying to keep the restricted scopes, since I found out the unrestricted "drive.file" wouldn't solve my problem, and was eventually rejected.  Google deemed us not one of the like 4 use cases where the restricted scopes are valid.

During the process you are able to add scopes and get those verified, so that is what we did.  We added the "drive.file" (which did work with 90% of the Google Drive integrations in our software), and was able to get verified.  This put the app into a state where I had the verification for everything except the "drive" and "drive.readonly" auth scopes.  I now have 90 days to update my application, and then remove them from our app.

And as I feared, I will have to get all my users to re-authorize their "offline" authentications, as the old tokens will eventually invalidate, because they were created with the auth scopes that I will have to remove from our app.

We are in the process of making the updates required to make it easy for our users to log in and re-authorize, so it won't be a huge headache for our clients, and the only functionality we truly needed the "offline" access for has been removed because it depended upon the restricted auth scopes.

[miningnews]

Hi Movie Ghost,

I'm in a situation working on an internal app, an AppsScript sidebar for Google Docs. I would prefer to use the narrower drive.file scope, but I don't want to have to present the Google Picker to the user to access the Google Docs file that they already have open.

Now if all the work happened in the AppsScript app that would be fine, but I make requests to a backend app that needs access to export the Docs file. The app has the drive.file scope and OAuth2 credentials, but it can't access the file that AppsScript can access.

From what I've read, the cause of my problem is the restriction Google placed on the drive.file scope. I can only access a file under that scope if:
1. My app created the file; or
2. My app opened the file through Google Picker.

My problem is that my users don't want to create copies of their file with my app, and they don't want to have to pick out their file from an App Picker. After all, they already granted permission to my app for that file by opening the add-on in the Google Docs editor.

You seem to have travelled a similar path, so I wonder what you know about working around these constraints, or finding another way?

[authorspirit]

I am stuck in same process. I have 29 days remaining. Either I have to use Google Drive Picker or send for verification process. I read few comments that they charge $600 to get it verified is it?

[nextlevelwebapp]

Hey authorspirit, just as an FYI when I logged in to complete this, the CASA website did not allow me to create a new case, and had a statement that said: As per guidance from the Google CASA team, we have ceased accepting new CASA requests.

I have emailed Google letting them know that I am blocked and cannot complete the request at this time.  I have not heard back from them yet.  I only have a few days remaining before my deadline.

Also this Medium article has been very helpful for me thus far- https://medium.com/@kelig.lefeuvre/step-by-step-guide-how-to-successfully-complete-casa-tier-2-secur....

[authorspirit]

Oh, I am trying some workaround to make it work without using anything of their restricted scopes. Most of the complaints/feedbacks that I sent them found no response. So without any risk of waiting 3-6 weeks I have to make some tweaks to my app with some limitations.
Thanks for the articles @nextlevelwebapp