I am a teacher preparing for distance learning. Google Forms are awesome, but they have some limitations. I created an old school google form with google sheets to get around a few issues I was having. I used the script from this data entry form
It works great! ...but I'm worried my students won't use it since they will get a warning that says "This app isn't verified." I know for a fact that my students will not click on the "advanced" button to authorize the app.
Is there a way around this?
Answer:
This screen can't be removed without app verification.
More Information:
As per the unverified apps page:
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. Users of unverified apps or your test builds might get warnings based on the OAuth scopes you're using. This is to protect users and their data from deceptive apps.
It's designed this way to stop tricky people with tricky apps blindsiding people by getting them to approve sensitive scopes without too much thought.
Unless you want to verify your app, which will need to be done through the GCP console (instructions on verification can be seen here), your only way around this is to just tell your students to click on the "advanced" button to authorise the app.
Side note: Verification is not required for Apps Script projects whose owner and users belong to the same G Suite domain or customer.
Further Reading:
Google Cloud Platform Projects | Apps Script | Google Developers
References:
Unverified apps - Google Cloud Platform Console Help
OAuth Client Verification | Apps Script | Google Developers
Related
At work we have developed an individual customer specific software application that is in use for a long time. We have a new requirement in this same program to implement an option for sending emails directly from the program.
The user is able to add his own email account with the credentials and login through our program. For Microsoft and Gmail accounts OAUTH is implemented and something here is not very clear.
For Gmail-API we have made an OAUTH Client and Consent screen on Google Cloud Console which we need to publish and verify and here is where the problems start. I am not very clear with the whole process of verifying the app.
In the steps for verifying is stated that we should verify a domain for the app, but this software is not hosted anywhere on internet and is not publicly available, it is available to a number of specific users (2000-3000).
Also Google requires a YouTube video of the software to be available publicly, which we are not able to upload because of customer requirements. Also here is required a Data Protection Policy page for the application which we as a developers don't have because we are only developing the software.
Other thing that is not clear to me, how is this type of software rated by Google, internal or public?
Have anyone experience with this or something similar?
Verifying an app for one of the Gmail scopes is a very complicated process. This process depends upon which scope of authorization you are requesting of the users.
In your case you are trying to send an email so you are using the users.messages.send method from the Gmail api. This uses a restricted scope. Which means you will need to go though the full process.
First of it doesn't matter if your application is hosted or not. It also doesn't matter that you give this app to a limited number of users. What matters is the scopes you are using.
You will need to ensure that your domain has been registered via google search console. So this app will need a domain
Once that is done you will be able to host your website, and the privacy policy on that domain.
You will need to create a YouTube video showing your application running, and how authorization is used.
You will also need to submit to a third party security checkup of your application which is not free and will need to be done once a year.
All of this is needed because of your consent screen it doesn't matter if its hosted any where, It also doesn't matter if this is only available to specific number of users.
If all of the users are part of a single google workspace account, that has created your client id and client secrete then you can set the app to internal and you wont need to be verified. This only works for google workspace domain accounts.
We're implementing Gmail sending in out ASP .NET web application with Gmail .NET SDK.
In order to do this we need all following scopes "email", "profile", "openid",
https://www.googleapis.com/auth/gmail.send" to be granted to us by user.
However, on the consent screen user can untick checkbox "Send email on your behalf" which is not acceptable for us, please see below:
We've seen quite a few examples where there are no enabled checkboxes on the Google consent screen. So, we're truiyng to figure out how to hide/disabled checkboxes in our app, could you please advise?
Probably, this is because of our application is still not verfified, but I'm not sure if this is the reason.
Answer:
These checkboxes are due to the rolling out of a new granular account permission system, they are completely normal, and can not be turned off.
More Information:
After some digging, I discovered this Google Developers blog post from 2018 in which it is discussed that in the new permission system, users will have the ability to grant or deny permissions individually.
From the blog post:
Over the next few months, we'll start rolling out an improvement to our API infrastructure. We will show each permission that an app requests one at a time, within its own dialog, instead of presenting all permissions in a single dialog*. Users will have the ability to grant or deny permissions individually.
*our different login scopes (profile, email, and openid are all combined in the same consent and don't need to be requested separately.
It seems that this is still in the roll-out phase, even though at the time of writing this answer 26 months have passed since the announcement.
Preparing for the change:
The following are guidelines provided by Google as to how to prepare for the changes they are making to the Google Account permission system for OAuth and APIs:
Review the Google API Services: User Data Policy and make sure you are following them.
Before making an API call, check to see if the user has already granted permission to your app. This will help you avoid insufficient permission errors which could lead to unexpected app errors and a bad user experience. Learn more about this by referring to documentation on your platform below:
Documentation for Android
Documentation for the web
Documentation for iOS
Request permissions only when you need them. You'll be able to stage when each permission is requested, and we recommend being thoughtful about doing this in context. You should avoid asking for multiple scopes at sign-in, when users may be using your app for the first time and are unfamiliar with the app's features. Bundling together a request for several scopes makes it hard for users to understand why your app needs the permission and may alarm and deter them from further use of your app.
Provide justification before asking for access. Clearly explain why you need access, what you'll do with a user's data, and how they will benefit from providing access. Our research indicates that these explanations increase user trust and engagement.
You can read the aforelinked blog post for full information about the change.
References:
Google Developers Blog: More granular Google Account permissions with Google OAuth and APIs
Google API Services User Data Policy | Google Developers
GoogleSignIn | Google APIs for Android | Google Developers
Google Sign-In JavaScript client reference
Requesting additional scopes after sign-in | Google Sign-In for iOS
We're implementing Gmail sending in out ASP .NET web application with Gmail .NET SDK.
In order to do this we need all following scopes "email", "profile", "openid",
https://www.googleapis.com/auth/gmail.send" to be granted to us by user.
However, on the consent screen user can untick checkbox "Send email on your behalf" which is not acceptable for us, please see below:
We've seen quite a few examples where there are no enabled checkboxes on the Google consent screen. So, we're truiyng to figure out how to hide/disabled checkboxes in our app, could you please advise?
Probably, this is because of our application is still not verfified, but I'm not sure if this is the reason.
Answer:
These checkboxes are due to the rolling out of a new granular account permission system, they are completely normal, and can not be turned off.
More Information:
After some digging, I discovered this Google Developers blog post from 2018 in which it is discussed that in the new permission system, users will have the ability to grant or deny permissions individually.
From the blog post:
Over the next few months, we'll start rolling out an improvement to our API infrastructure. We will show each permission that an app requests one at a time, within its own dialog, instead of presenting all permissions in a single dialog*. Users will have the ability to grant or deny permissions individually.
*our different login scopes (profile, email, and openid are all combined in the same consent and don't need to be requested separately.
It seems that this is still in the roll-out phase, even though at the time of writing this answer 26 months have passed since the announcement.
Preparing for the change:
The following are guidelines provided by Google as to how to prepare for the changes they are making to the Google Account permission system for OAuth and APIs:
Review the Google API Services: User Data Policy and make sure you are following them.
Before making an API call, check to see if the user has already granted permission to your app. This will help you avoid insufficient permission errors which could lead to unexpected app errors and a bad user experience. Learn more about this by referring to documentation on your platform below:
Documentation for Android
Documentation for the web
Documentation for iOS
Request permissions only when you need them. You'll be able to stage when each permission is requested, and we recommend being thoughtful about doing this in context. You should avoid asking for multiple scopes at sign-in, when users may be using your app for the first time and are unfamiliar with the app's features. Bundling together a request for several scopes makes it hard for users to understand why your app needs the permission and may alarm and deter them from further use of your app.
Provide justification before asking for access. Clearly explain why you need access, what you'll do with a user's data, and how they will benefit from providing access. Our research indicates that these explanations increase user trust and engagement.
You can read the aforelinked blog post for full information about the change.
References:
Google Developers Blog: More granular Google Account permissions with Google OAuth and APIs
Google API Services User Data Policy | Google Developers
GoogleSignIn | Google APIs for Android | Google Developers
Google Sign-In JavaScript client reference
Requesting additional scopes after sign-in | Google Sign-In for iOS
We are facing the below screen when trying to authenticate to Google. The app that we are trying to authenticate is used for internal development and we did not publish it to our users.
Any idea why this occurs?
We faced an Unverified App screen before (as below) but now the authentication is disabled.
OAuth Client Verification
Starting July 18, 2017, Google OAuth clients that request certain sensitive OAuth scopes will be subject to review by Google.
OAuth Client Verification
Starting July 18, 2017, Google OAuth clients that request certain sensitive OAuth scopes will be subject to review by Google.
Review is not required if you are only using it under the same account as created the project in Google Developer console. You can read more about this change in this help center article.
This change applies to Google OAuth web clients, including those used by all Apps Script projects. By verifying your app with Google, you can remove the unverified app screen from your authorization flow and give your users confidence that your app is non-malicious.
Once you have applied for verification it takes around a week and it should start working.
I found this thread some time ago when this happened to us in our development project on Google Cloud Platform.
You can use a project for development without verification. No problem on that. But there are some limitations (more information here and here). Basically, we reached the limit of 100 users accessing the application. It was strange because we were testing with few accounts (5-6) until we found that, if you uninstall and install the application again, it counts as a new user. We were testing incremental authorization, so we uninstalled/installed the application a lot of times and we reached the quota.
When you reach this limit, you will see the message "Sign in with Google temporarily disabled for this app" and only users from the organization where the project is hosted can access the application. So we couldn't make test with our accounts from a demo domain or our Gmail accounts.
The only solution available was to pass the OAuth verification form (even if you didn't want to publish the application), but there were problems to do it. For example, it was mandatory to remove http://localhost from valid OAuth URLs. And more problems related with development.
❗ But this has changed recently. I have accessed to OAuth credentials screen in Google Cloud Platform (APIs & Services > Credentials > OAuth consent screen) during this week and now the page it's different. Now you don't need to specify "Authorised JavaScript origins" and "Authorised redirect URIs", you just need to specify your scopes for Google APIs and the Authorised domains. Then, at the bottom of the page you will find the button "Submit Verification" and the process will start. You will also find some information on the right:
About the consent screen
The consent screen tells your users who is requesting access to their data and what kind of data you're asking to
access.
OAuth Developer Verification
To protect you and your users, your
consent screen may need to be verified by Google. Without
verification, your users will see an additional page indicating that
your app is not verified by Google.
Verification is required if
Your application type is public, and You
add a sensitive scope Verification may take several days to complete.
You will receive email updates as it's processed.
Saving without publishing
Even though your consent screen is
unpublished, you can still test your application with users with the
following limitations:
Sensitive scopes are limited to 100 grant requests before verification
is required
Users see an additional page indicating that your app is
not verified by Google.
To include "Authorised Javascript Origins" and Authorised redirect URIs" you need to go to APIs & Services > Credentials and there click on your OAuth 2.0 client ID. There will be a form where you can add them.
In our case it took 1 day to get a response from Google. In the email there were some instructions to pass the verification. We had to reply the email with a video uploaded on YouTube addressing the following points:
How does user sign-up on your app and grants access to the sensitive scopes requested in verification?
OAuth consent screen as seen by end users
How does your application use the requested scopes to provide services to developers?
A test account email and the password for us to test the user sign-up process and validate the project's functionality.
We recorded a video showing points 1, 2 and 3 and sent them a test account for number 4.
After 1 day, we got another response from Google confirming that our project had been verified.
So finally the problem was solved! 🙂
I hope this could help people in the same situation. It was really annoying for us.
I had to go into my Google Apps Script settings and turn on the "Google Apps Script API" setting. Then I tried again, and the script executed correctly without issue.
I had used the script a couple of weeks ago and it worked fine, so something must have happened between then and now that changed it... Not sure what caused that setting to switch.
We already have a web app that integrate with differente Google services. Right now, you can loguin using a Google account, can import a contact lists from any Google account, and can sync a Google Calendar with our Calendar in the webapp (We implemented all of this using OAuth 2 and invoking the GoogleApi with a REST Client).
We are now trying to publish this app in the GoogleApp Marketplace, but we are failing to comply with the "Use one-click single sign-on" rule (https://developers.google.com/apps-marketplace/practices#5_use_one-click_single_sign-on).
We are believing that the problem is we the way we are solving the fact that we need offline access for all the integrated users in the app. Right now, the only way we found to get the refresh tokens for them, was starting the OAuth2 process with the parameters access_type=offline&approval_prompt=force, but this forces them to enter their credentials.
We aren't using the 'Google+ Domains API', and we are starting to believe that we should. Is the use of this API mandatory for complying with the "Use one-click single sign-on" rule?
Thanks,
Well, we finally figured it out. We had to use the Google Admin SDK in order to implement SSO. We had some troubles with the scopes, but after we polished that, everything seems to be working OK.