This screenshot shows the new OAuth consent screen, which lets the user provide consent for a subset of the requested OAuth scopes. (Image credit: Google)
Earlier this year, we launched an improved version of the OAuth consent screen to the Apps Script IDE and unpublished Editor Add-ons that allows users to specify which individual scopes they would like to authorize for that script. For example, if a script requests access to a user’s Sheets and Forms files, and the users only intends to use the script with Sheets files, they can decide to only allow access to their spreadsheets and not their forms.
Google is continuing to enhance user privacy and control by extending the granular OAuth consent screen to published Editor Add-ons. This latest move builds upon the changes first introduced to the Apps Script IDE back in January, which we covered in detail at the time.
For those who missed it, this feature allows users to choose exactly which permissions (scopes) an application can access, rather than being forced into an “all-or-nothing” decision.
What’s Changing Now?
This more granular consent experience will now be presented to users when they install or re-authorize published Editor Add-ons from the Google Workspace Marketplace. When an add-on requests access, for instance to both a user’s Docs and Sheets, the user can now choose to approve one, both, or neither of those permissions.
While Google notes that “Pre-existing scope grants will not be affected”, it’s crucial for publishers of existing add-ons to understand that this new consent screen will appear if a user needs to re-consent. This can happen for several reasons, such as a user manually revoking the add-on’s access from their Google Account, or if a refresh token expires (e.g., after six months of inactivity). In these cases, existing users will be presented with the new granular options, and developers must be prepared for the possibility of partial authorisation.
A Reminder for Developers
As this functionality rolls out, starting on August 19 2025, it’s crucial for developers to ensure their add-ons can handle partial consent. If a user denies a specific scope that is essential for a feature, the add-on should fail gracefully without breaking.
As we detailed in our January post, the ScriptApp and AuthorizationInfo classes are your key tools for managing this. These allow you to programmatically check the granted scopes and build safeguards into your code. For a deeper dive into the methods and a guide on handling these scenarios, we recommend reviewing our original article.
