Branding the "Authorize access" button for a unverified Gmail add-on app? - gmail-addons

So, I am trying to get my Gmail add-on approved by Google and I am struggling with one last thing.
My app use "sensitive" scopes (such as gmail.addons.current.message.readonly) and therefore the user needs to authorize that my app is allowed to do that. For apps that haven't yet been approved by Google, the user is prompted with an "Authorize access" button (see image and this link https://developers.google.com/gsuite/add-ons/how-tos/authorizing-addons#authorizing_unpublished_g_suite_add-ons).
Now, I have received feedback from the OAuth Verification Dev Team at Google that I have to change this button to the Google brand guidelines. My problem with this is that the screen that needs to be changed is a default Gmail Authorization screen (for unverified apps only) and I dont know how to change that...
Does anyone have any idea how to proceed? I have emailed the OAuth devs mutiple times, but they dont provide me with any pointers, only threats that my app will be rejected if I don't comply.
UPDATE: The full response from the Google team below:
Thank you for your response.
Please note, that since the 'Authorize Access' button initiates the OAuth Sign-in process it is subject to comply with the Google sign-in branding guidelines.
You may refer to Figure 2: Unverified app authorization flow on our
OAuth Client Verification page, which showcases the full OAuth
Sign-in process.
Google Sign-in Branding
In order to proceed with the sensitive scope verification for the project: xxx-xxx, please update the previously flagged Google sign-in button so that it complies with the Google sign-in branding guidelines.
Please reply to this email once you have made the appropriate updates to your site and/or your OAuth Consent Screen so that we may continue with the verification process.
Note: Failure to satisfy/provide the preceding information might
result in a rejection of your request. To avoid this outcome, update
the applicable information in your request to meet our requirements.

Related

How to handle duplicate fields (TOS, Privacy Policy) on OAuth Consent & Marketplace Listing

I'm writing an Apps Script Add-on for Google Sheets. There are duplicate fields on the OAuth consent screen and the Google Workspace Marketplace SDK Store Listing screen. These are "Terms of Service" and "Privacy Policy" URLs.
Do they need to be filled out in both places? It appears that they are optional on the OAuth consent screen since they do not have an asterisk next to them. Is that true?
If they do need to be entered in both places, do they need to match? On the Store Listing, I used URLs pointing to a shared (with everyone) Google Doc. But on the OAuth screen, it appears they are requiring the documents to be on my website, since they are under the App domain section.
I've seen a working tutorial from a few years ago where a shared Google doc was used for the store listing. But has that policy changed and now do they have to be on my website?
If you are planning to make the OAuth Consent Screen for External users you should add the Terms and Conditions as well the Privacy Policy fields, otherwise it's very unlikely that it will be approved in the verification process, if it will be for Internal users you might try to keep these fields empty as in this case the OAuth Consent Screen will not be verified.
Regarding if these fields should match the fields on the Marketplace listing, it will be weird if they doesn't match. AFAIK Google doesn't review exhaustively the Marketplace listings but if users complain the might review it. They might contact you giving some recommendations, disable the Marketplace listing, etc.
If you want to use a Google Editor files for your TOS and Policy files, you might embed them in a Google Site with a custom URL.
Resources
Use a custom domain for your site
I found the following information about the "Privacy Policy" URLs:
Make sure that your app's Privacy Policy meets the following requirements:
The Privacy Policy must be visible to users, hosted within the domain of your website, and linked from the OAuth consent screen on the Google API Console.
The Privacy Policy must disclose the manner in which your application accesses, uses, stores, or shares Google user data. Your use of Google user data must be limited to the practices disclosed in your published Privacy Policy.
Based on the first requirement, I will say they need to be the same URL under the Google Workspace Marketplace SDK Store Listing and the OAuth consent screen in the project.
However, there is no such restriction for the Terms of Service inside Google Documentation.
Reference:
OAuth API verification FAQs.
Getting prepared for verification

OAuth requirement for publishable add-ons that only act as clients to Google

Let's say we're developing an editor add-on (meant for publication) that does not need to interface to third party services (only to a self-developed API server, A). Does A need to implement OAuth i.e. issue tokens and so on, or is it sufficient to use the OpenID token received from Google with ScriptApp.getIdentityToken() as authentication for A (as mentioned at the bottom of [1]) ?
When the users start the plugin, they will anyway be faced with an OAuth consent screen, which mentions the scopes given in the addon's appsscript.json manifest file.
I don't find the requirements listed in the developer guide [1] clear when they mention "non-Google services".
In other words, will the Google security review fail my add-on if my API server A does not implement OAuth?
Thank you for any clarifications.
Edit : I'm not concerned with sensitive scopes.
[1] https://developers.google.com/gsuite/add-ons/how-tos/non-google-services

OAuth Verification using chrome.identity.getAuthToken

I have an extension that is working perfectly correctly using chrome.identity.getAuthToken (https://developer.chrome.com/apps/identity#method-getAuthToken). I need to submit the oAuth consent screen for verification as it uses a restricted scope.
I received an email from the Google OAuth certification team about the creating a video showing the step by step of the auth procedure, all fine except for one step that states I need to show the:
URL bar of the OAuth Consent Screen shows the Client ID containing the
project_number fully displayed (Note: this is not required for native
Android and iOS apps)
I am stuck here as the oAuth Indentiy API providor used by chrome.identity.getAuthToken shows the consent screen in a window without any URL bar! I can't see any options to change this or show it....
What should I do?
Refactor the auth to a popup rather than using the
chrome.identity.getAuthToken
Try submitting without and see if it goes through?
Thanks for your advice.
So, I replied to the OAuth verification team an explain that chrome.identity verification screen does not show the URL bar and received an acceptance less than 24 hours later.
My recommendation to anybody requesting verification and worried, is just go for it and explain where you cannot meet what they have asked.
Thanks

How to avoid Restricted Scopes OAuth verification process for private scripts used only by me?

I have received email from Google with subject: [Action Required] Submit your app(s) for Restricted Scopes OAuth verification,
same as many of you.
I'm using GAS only for developing applications for my personal use - not for public. Applications such as sending summary emails to my clients, when they buy a product from my web pages.
Do I have to go through the whole process of verification?
Do I have to create public Terms of Service?
Is there any way how I can explain to google, that my applications are not used by anybody else then by
me?
How to get to know for sure that my app won't stop?
I have read through FAQ (https://support.google.com/cloud/answer/9110914) and many other documents by google about this topic..
I have checked similar questions found on web, but with no luck of answers.. It looks it's pretty new experience for all of us..
Thank you for any advices.
I have personal account, so I can't use "internal apps" selection, this works only for paid G-suite customers which I'm not.
EDIT:
As Yoel Vinitsky stated, app doesn't need verification if it has only one user.
Here at bottom: https://support.google.com/cloud/answer/7454865 is table which shows that there is quota 100 new users in total, once the app presents the unverified app screen.
It seems like that I don't have to worry about verification of my apps at all, because I'm the only one user or maybe I use this app from 2 or 3 more users emails so it should be ok, my question is, is it going to be ok without verification, or not?
EDIT 2:
Google sent clarification email:
NO ACTION is required if:
Only owners use the project: If the project is only used by owners of the project, no action is required.
To determine whether you are an owner (versus an editor or viewer), follow these steps:
Click the project link above to navigate to its OAuth Consent Screen
configuration page.
Click the Navigation Menu button in the
upper-left corner, select IAM & admin, and click IAM. This will show you all project contributors and their roles.
The project doesn’t have users outside of your G Suite domain:If the project owner is using a G Suite account and the project is only used by Google Accounts in the project owner’s domain, no action is required (learn more here).
But the question is how to avoid verification with personal accounts for my own scripts used only by me?
As mentioned in the support FAQ You linked to:
When can I skip publishing my app for a review?
You do not need to request for verification if your app is
going to be used in any of the following scenarios:
1) The app is not shared with anyone else.
2) The app is used to send emails through WordPress, or
3) similar single account SMTP plug-ins.
The only drawbacks should be the warning that your app is unverified and maybe quota limits.

Does submitting consent screen for verification automatically trigger unverified app screen?

Update: I can confirm that simply requesting verification, as long as the scope isn't used in the app, does not trigger the unverified app screen.
The current documentation for when the "unverified app" screen is displayed is slightly confusing.
In particular, what happens when I add a sensitive scope via the Oauth Consent Screen, request verification, but do not use it in the app yet?
The unclear part of the support page is below, in particular point #2:
The app or script might display an "unverified app" screen before it
displays the consent screen. This is based on the specific scopes that
your app includes in the request. This warning will display when:
Your app uses sensitive scopes and you haven't configured your OAuth
Consent Screen and requested verification.
You selected sensitive scopes on the OAuth Consent Screen and requested verification, but the verification is in not yet complete.
Your app uses sensitive scopes that you haven't selected on the OAuth Consent Screen configuration page.
The way bullet #2 is worded reads like this may trigger the unverified app screen for users, even though the scope isn't in use.
I may be missing something, but it feels like the intended behavior is to allow users to request verification and only show the "unverified app" screen if the scope is also in use in the app, so as to allow developers to get a scope verified before using it in the app.
After we went ahead and requested verification I can confirm that simply requesting verification does not trigger the unverified app screen, as long as the scope isn't used in the app until it's verified.