On July 18, 2017 Google announced new security protections to reduce risk from unverified apps. This announcement came in response to continued work to prevent phishing attacks that have used Google Apps Script. As part of this newly created Apps Script projects in certain circumstances will present the user a “app isn’t verified” screen. The user can take steps to dismiss the warning and authorize the app alternatively the developer can submit their app to Google to become verified. In this post I’ll cover the scenarios, at time of writing, that the unverified app screen appears and legitimate techniques for preventing its display. This post results from a discussion Steve Webster and I had for one of our Totally Unscripted Hangouts On Air.
Scenarios that trigger “app isn’t verified” screen
First rule of unverified app club … if you are publishing an app within a G Suite domain for other users in that G Suite domain you shouldn’t encounter the “unverified app” flow unless of course you get your app verified. My understanding is if you are running multiple domains within your G Suite account the need for verification is based on the organization as a whole, not individual domains.
In a follow up post to the Google Apps Script G+ community Googler Wesley Chun clarified some points from the original Google announcement (emphasis mine):
“unverified app” flow and verification process, applies to all OAuth clients requesting sensitive scopes
If you are unfamiliar with ‘scopes’ when you include services like DriveApp to your script project the service is added to the list of authorizations the user has to give. Essentially rather than the user giving permission to the entire abilities of their account the script is limited to the “scope” of the authorization granted. The official documentation doesn’t detail which scopes are sensitive, I’d imagine in part because Google would want to quickly respond if a scope becomes subject of a vulnerability. Running tests of the core Apps Script G Suite Services the following scopes triggered “unverified app” windows:
- DocumentApp – https://www.googleapis.com/auth/documents
- SlidesApp – https://www.googleapis.com/auth/presentations
- SpreadsheetApp – https://www.googleapis.com/auth/spreadsheets
- DriveApp – https://www.googleapis.com/auth/drive
- GmailApp – https://mail.google.com/
- ContactsApp – https://www.google.com/m8/feeds
- Jdbc – https://www.googleapis.com/auth/sqlservice
Interesting to note that MailApp isn’t at this time classified as sensitive and this may change.
So if your project needs any of the above listed scopes you can expect to hit the “unverified app” flow. However, if your project only uses DocumentApp, SlidesApp or SpreadsheetApp you can avoid the “unverified app” flow if you can limit the scope to the current document using @OnlyCurrentDoc (see authorization scopes documentation).
Existing apps are not yet affected
So existing Apps Script projects don’t need verification … yet. Something to be aware of is if you are distributing Apps Script projects as container bound scripts (the script is part of Google Sheets, Doc, Forms and shared by users making a copy, copies are classified as a new app).
Add-ons that are published to a limited set of users/domains or only to those with the link may present users with the unverified app screen
The above is taken from the developer documentation. For new add-ons verification has been integrated into the add-on review and publication process. However as Steve highlighted in our Totally Unscripted session there are other publication options that allow users to access an add-on that is unlisted and not gone through a review. In these cases if they use sensitive scopes and are being used outwith a G Suite domain that published it users may get the unverified app screen.
The ‘myself’ use case – developer is unverified
Prompted by a comment by Edward Ulle it’s worth remembering that ‘unverified app’ also affects the script owner/developer. Steve Webster illustrates this in the following video where deploying a web app to execute as the developer and only run for the developer can lead to the app verification flow. Something worth remembering during development
Unverified authorization cap
Another clarification from Wesley’s post was:
Per-day authorization throttling was a temporary measure and is being rolled back in favor of the “unverified app” cap
To unpack what this means there was a short period when web app authorizations were capped. The screenshot below was grabbed by Steve Webster from the official Apps Script quotas page.
This has been removed from the page and while the Client Verification documentations states:
The number of users who can authorize an app via the unverified app flow is capped to limit possible abuse. This cap does not apply to verified apps.
The actual cap is currently unknown and doesn’t appear on the quotas page.
Note on libraries and verification
Whilst the use of Apps Script libraries is discouraged in add-ons it is possible to use them. There are also other scenarios such as web apps and container bound scripts where libraries are used. If sensitive scopes are used as part of these libraries and they are being used outwith the authors G Suite domain the unverified app screen may appear. A question you may ask is can a library be verified allowing any script that uses the library to inherit the verification. My understanding is this isn’t possible and any script that uses a library with sensitive scopes will need to be verified itself to avoid the “unverified app” screen.
Getting your app verified
As previously mentioned verification for publicly listed add-ons is now built into the existing publish process. For other Apps Script projects the requesting verification process is documented. I’ve heard mixed experiences from developers getting apps verified but Google appear to be listening and are improving their internal processes. There are a couple of requirements to be aware of before your project can get verified:
Guidance for users encountering unverified apps
For developers I feel it’s always worth familiarising yourself with the user experience including information provided as support. For unverified apps Google have prepared a decide whether to give an app permission page. It’s worth noting that some of the information on this page is contradictory going from:
If the screen says “This app isn’t verified”
Don’t give permission. To leave the app or site, select Back to safety.
Which is then followed by a section on Give permission anyway and then a “if the screen asks for permission. Follow these steps before you decide what to do.” The page provides useful advice but is perhaps not presented in the best way so I’d expect you’ll get questions from confused users. Ultimately the advice is where you can get your Apps Script project verified.
Hopefully this post has provided some useful guidance. Whilst these changes have created some headaches for developers the consensus I’ve picked up from the community is that these developments are welcomed as it strengthens Apps Script as an enterprise solution and maintain the trust of users.