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.
Related
I've set up a Google project so that I can allow my users to log in via Google. It's all working but in my consent screen section in the Google developer console it says Verification status: Not published
I can't seem to find any articles to explain what this means. I can find plenty of articles about status Unverified but nothing for Not Published.
I accidentally added a logo at one point which changed the status to Unverified. So then I deleted the project and re-created a new one and it's now Not Published.
My question is what does Not published mean? Can I use it on my website for login with Google or will it give errors or stop working after a while?
Verification status: Not published
It means that the consent screen is new. When you create a new Google Cloud Project, you have to create a new consent screen, which initially exists in an indeterminate state about its verification status, hence the "not published" instead of "not verified".
When you add a sensitive scope and save the consent screen (or upload an icon that the users will see on the screen), it has to be reviewed to ensure you do not have malicious intent, therefore the status changes to "needs verification".
After you go through the OAuth client verification process, the status changes to "published" in case of review success.
To sum up, there are three "states" in which a project verification status can be:
Initial = "not published"
Unverified = "needs verification"
Verified = "published"
Current documented definition of an unverified app confirms that leaving the project in the initial state if one does not have sensitive or restricted scopes should not lead to a warning screen:
An unverified app is an app or Apps Script that requests a sensitive or restricted OAuth scope, but hasn't gone through the Google verification process
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
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.
Background:
This is about using a Gmail Addon created using Google App Script.
When the user installs the addon, there is the OAuth Consent Screen where user provides his consent to allow the "Product name shown to users" (as configured in the OAuth Screen) to allow the access specified.
Now, I read : https://developers.google.com/identity/protocols/CrossClientAuth
which states :
When a user grants access to your app for a particular scope, the user
is looking at the user consent screen, which includes project-level
product branding that you set up in the Google API Console. (For
information about setting up the consent screen, see Setting up OAuth
2.0 in the API Console help.) Therefore, Google considers that when a user has granted access to a particular scope to any client ID in a
project, the grant indicates the user's trust in the whole application
for that scope.
Now, I have a server web component (a lambda) (belonging to the same product) that needs access to the user's email same access that the user provided after installing the addon ("Authorized Access" button).
Question(s) :
Is there a way to have cross-client (a backend server and a gmail addon) in my case to have the backend to just get access to user's data without triggering additional (basically whatever the user has provided consent to)?
Note: Using an additional authorization screen triggered manually using the GAS OAuth library I was able to get the "Auth Code" which I pass to the server using which the server now has access to the consented data (we have used the same client id and secret). However, the problem with this approach is :
User gets 2 emails about the permissions granted. Addon and Manually triggered flow.
User has to authorize the gmail addons for first access and then another which I trigger manually.
Even if there was a way I could get the "Auth Code" when the user installs the addon that would also do.
Apologize in advance there is a lot of scattered documentation and though I went through many it is likely I may have missed something.
We only issue one authorization code (refresh token) in exchange for one user authorization/approval. Your app can get new access tokens on android or web without a user approval. But if it needs a refresh token again, user still need to approve the request.
So if the addon can talk to your server, you could give it a short lived access token or will need to user authorization.
I have been developing an extension, which is using the chrome.identity API (chrome.identity.getAuthToken method) in order to receive the OAuth2 token for signing up extension users via Google+.
I would like to push this extension in a company via Google Admin Console, but when chrome.identity.getAuthToken method is being called, our extension users are present with the "Identity API Scope Approval" screen - the consent screen, where users have to authorize extension's access to scopes we want access to.
I am aware, how process of getting OAuth2 access tokens works in general, and that user's approval is normally required in order to receive the OAuth2 token.
However, is it possible to automatically skip & authorize this OAuth2 consent screen only for users, whose extension was deployed via Google Admin Console?
I've found an interesting on Chromium Bugs list, where OP states:
We are working on integrating Quickoffice for Chrome (which is a chrome extension) with the Drive Web UI. In order to handle OAuth we use chrome.identity, which works great.
and also the following:
since our extension is white listed as a first party app, we by pass the user content screen for the OAuth flow (which is what we want for the seamless integration with drive web ui).
I was not able to find any information, how to neither whitelist the extension as a first party app in order to prevent the consent screen from showing up, nor how to automatically authorize extension's access to those API scopes.
Any ideas?
If you include identity.email in the manifest permissions, and it is a force-installed extension or app through the admin console, then you will be able to get the user's identity and also the auth token without user oauth prompt approval.
However this only allows you to get the user's identity, no extended permissions. Any extended permissions (such as gdrive access, etc) need an oauth prompt.