Does changing scopes for a Google Workspace Marketplace app require admins to grant access again?

[cameron19]

Our Marketplace app GQueues recently updated our integration with Google Drive to use the less permissive drive.file scope instead of the now “restricted” full drive scope. (This is better for our users, and also means we don’t have to go through the very time-intensive and costly third-party security audit).

We refactored our code to only use the drive.file scope and removed the full drive scope on our OAuth Consent Screen, which then was re-verified by the Google Trust and Safety Team. Our Marketplace SDK App Configuration page currently requests both the drive.file and full drive scope. So the last step is to remove the full drive scope from the App Configuration, so the restricted drive permission is no longer requested when Admins install our app.

What we didn’t know, and could not find anywhere in documentation or searching on the web, was whether removing the full drive scope would then make all the other scopes in our App Configuration invalidated as well. Essentially, would all our Google integrations break for existing installations until admins re-granted access to our app?

To answer this question I created a separate Marketplace app so I could test what happens to existing installations when scopes are added and removed. And I decided to share what I discovered here so others don’t have to go through all this effort to know what happens.  Here’s what I learned:

1. Adding a scope to your App Configuration causes existing installations to go into a “Partially granted” state, as shown here when I added a calendar scope. Apps can’t use the new scope until Admins grant access to the newly added scope.
   
2. Removing a scope has NO IMPACT on existing installations, as shown here when I removed the full drive scope on the test app configuration. In fact, the full drive permission stays active for existing installations and can continue to be used. Only new installations are affected - they will not request access to the removed scope.
   
   
   
   Workspace Admin Console...
   
   
   
3. That means the scope removed from the App Configuration will only be removed from existing installations if Admins uninstall the app entirely and reinstall it.

This is all very good news for our situation. This means we can safely remove the full drive scope from our App Configuration so new installs don’t have to grant this permission, while existing installs will continue to work seamlessly, without us having to message Admins to re-grant access to our app.

I recorded a short video where I change scopes in a test app so you can see how this all works with your own eyes.

https://www.youtube.com/watch?v=h1LhuagmP6s

[Shubham18]

Thanks, It is very helpful. I have few more doubts,

If I have added new scopes for a additional feature. But that is not mandatory.

• If new users(admins) will install the app domain wise. They will see the added scope there as well. Is there any way that they can just granted the permission for only those scopes which are mandatory ? 
  
  
• There is other options that they will allow the access on the first place means after installing the app and they admin can revoke that particular permission.
• Is there any way that admin need not have to give the additional permission on the first place?
  Thanks.

[cameron19]

I know granular permissions are supported for consumer accounts, but according to the docs this isn't available for domain-wide delegation.

[martinsus]

This is brilliant, Cameron! Thank you so much for this—it really helped me understand what happens when adding or deleting scopes.

The only thing I’m still unsure about is what happens when our app is already listed and we add a new scope. Specifically:

1. How will the new login process look for the admin?
2. How will they grant access to the new scope?
   • Will they see the OAuth consent screen again? If so, what will be displayed there?
   • Or will they need to manually approve the new scope in the Admin Console to make the app fully granted?

Any insights into this process would be greatly appreciated. Thanks again for your help!

[cameron19]

In my experience, when a new scope is added to an app that is already listed, the Data Access section for the app goes into a "Partially Granted" status as shown in Item 1 of my original post. The new scope cannot be used with the domain until the Admin manually grants access to the new scope.  Trying to make an API call when the scope has not been granted access yet will result in a 403.  Unfortunately the Admin is not notified by Google Workspace that there is a new scope waiting for access to be granted.  So when a new scope is added, it's up the to app developer to communicate with customers/admins about the new scope and recommending they manually grant access.

[kerawill1122]

Hi Cameron,

Thanks for sharing your detailed experience—it’s really insightful and helpful for others navigating similar challenges with Google Workspace Marketplace apps!

To address your primary concern: removing the full drive scope (or any scope) from your App Configuration does not invalidate other scopes for existing installations. Users and admins won’t need to re-grant access as long as your app continues to operate within the remaining authorized scopes. Your integrations should work seamlessly after removing the full drive scope since you’ve already transitioned to using drive.file.

However, here are a couple of points to keep in mind:

1. Scope Removal Impact: Once the full drive scope is removed, your app will no longer have access to data it could previously access under that scope. Make sure all your refactored code and functionality are fully adapted to the drive.file scope before making the change.

2. Testing Is Key: It’s great that you set up a test app to confirm the behavior. Continuing to test in a sandbox or test environment is essential, especially when dealing with live user data and integrations.

3. Communication with Users/Admins: While admins don’t need to re-grant access for scope removals, it’s always a good idea to notify them of the change—especially if there’s any functionality that may be affected during the transition. Transparency helps build trust.