Drive API Auth Scope Changes - Handling Changing/Remvoing Scopes

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

Solved Solved
2 9 10.8K
1 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.

View solution in original post

9 REPLIES 9
Top Labels in this Space