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
Related
We are integrating the Gmail API with Integromat and, in order to avoid re-authorizing Integromat’s access every 7 days, we need to submit for Google verification.
Now the problem is that the Google verification wants to verify the ownership of each domain. I’m afraid this includes the integromat.com domain (since integromat.com is the authorized domain). That’s a problem since we don’t own the integromat.com domain and we therefore cannot verify domain ownership. Is there a contingency plan for this?
Besides, Google wants a YouTube video showcasing how the permission is being used, which is quite a silly requirement since our Integromat account is only used by us (obviously).
I wonder whether Make/Integromat has some official recommendation/help for this? I couldn’t find any so far.
Note that we are not using Google Workspaces so we can’t use Google’s "internal usage" option.
You have two issues here. The refresh token expiring, and your desire to submit your application for verification.
These are separate issues that are unrelated.
expiring token
Refresh token expiring after seven days is due to the fact that your application is currently in testing phase not that it has not been verified.
refresh token expiration
A Google Cloud Platform project with an OAuth consent screen configured for an external user type and a publishing status of "Testing" is issued a refresh token expiring in 7 days.
On the Ouath2 screen set the project to production and your tokens will stop expiring.
verification
Domain name:
If you are using a domain name either for redirect uri or hosting of your privacy policy. You must verify that you own this domain though though google search console. There is no way around this.
If you don't own integromat.com your not going to be able to use that. Host it on your own domain.
Gmail scopes are one of hardest scopes to be able to get an application verified for.
YouTube Video:
You will need to create a YouTube video and host it public so that the security team can verify what your application is doing and how it its intended to work. It is not a silly requirement. It is there to protect your users data.
Remember the third party security assessment for gmail scopes is going to cost you between 15k-75k dollars a year.
internal
As stated in exceptions-to-verification-requirements
Internal Use: The app is used only by people in your Google Workspace or Cloud Identity organization. Note that your app will not be subject to the unverified app screen or the 100-user cap if it's marked as Internal.
Your last line says.
Note that we are not using Google Workspaces so we can’t use Google’s "internal usage" option
You don't need to be verified. So you dont need to worry about the domain, or the youtube video.
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
My website is a service site, it is separated with Parent company website
I want to use GG calendar API, so i access to https://console.cloud.google.com/apis to set required link.
But after that, i received below email.
I did not create a privacy policy page (because it's involved to with Parent company website).
Can i use privacy policy page on Parent companies'website to reference?
Please note that Google API Service:User Data Policy requires the following:
Your Privacy policy must be visible to users, hosted within the domain of your website, and linked to the OAuth Consent Screen on APIs & Services
on Google Cloud Console.
Your privacy policy and in-product privacy notifications must thoroughly 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 explicitly disclosed in your published privacy policy.
Please make appropriate changes to the privacy policy and/or your app and reply back to us to move forward with the approval process.
When you set up the OAuth 2.0 consent screen for your app, it will look something similar to this:
If you look closely, the 4th element is represented by the app's privacy policy.
Therefore, if you have the necessary access and permissions in order to use them for your own application, it shouldn't be a problem in this sense.
Moreover, since you mentioned you are making use of the Calendar API, you might want to check the Sensitive and restricted scopes of this article here.
Reference
OAuth API verification FAQs.
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.
I'm creating a simple iPhone app. The basic premise is that the app will display some data (That I provide online) on the application. The data changes over time, so the app has to draw the data from online and display it. I don't have a significant programming background so I don't want to use my own server.
Thus, I thought it would be significantly easier to just put the data into some documents on a Google account and then access them programmatically via the Google Drive API. I could then update the data in my Drive account and it would get updated in the application. The key here is that I am ONLY accessing ONE account that I own MYSELF. The users' accounts are not being accessed. Therefore the goal is to never have to log in manually. It should all happen behind the scenes, aka, it should look like a server, not a google doc.
With this in mind, it doesn't make sense to show the Google Accounts sign-in page to my users as the standard OAuth2.0 tutorial shows here:https://developers.google.com/drive/quickstart-ios#step_1_enable_the_drive_api
I should be able to access my own data by somehow hardcoding in my username, password etc. Google agrees here: https://developers.google.com/drive/service-accounts#use_regular_google_accounts_as_application-owned_accounts
The above link mentions a "refresh token" that I'm supposed to save. However, I have no idea how to build and save that token, or even for that matter, where to find it.
I've gone through both the basic tutorial and the Dr. Edit Tutorial for iOS, but they both assume that the application is accessing USER accounts not application-owned accounts.
I'm not asking for someone to write the code for me (though tidbits are nice), but if you can point me to a step-by-step guide or related sample code that would help me get started that would be awesome. I'll even come back and post the code that I use!
EDIT: Since I realized that the Google Drive API wasn't something I could use for what I am trying to do, I eventually found Parse which is an awesome tool that handles all the server backend for me and is free at the basic level.
Google APIs objective-C client library doesn't support service (application-owned) accounts, because they are supposed to be used by a server-side apps, instead of clients -- you shouldn't be distributing your private key as a part of an app.
If you would like to distribute content from a service account, maybe you should write a server leg to do the authentication and pass clients credentials in a secure way for them to talk to the API on the behalf of the service account. Or, use Web publishing to make documents universally accessible without authorization and authentication if privacy is not a concern.