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.
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.
I'm exploring accessing mail (and sending mail) on behalf of other users. I have read about the graph api which would allow me also to handle chat messages later on.
I wanted to start implementing this with my personal account (#outlook.com) and followed basically this tutorial: https://cmatskas.com/create-a-net-core-deamon-app-that-calls-msgraph-with-a-certificate/ (this seems to be the same as the walkthrough in the portal)
I found questions and answers (like Microsoft Graph to send mail with Client Credential Flow (application permission) and personal account) but I do want to create a daemon app which seems not to work with a personal account (which makes sense because I could read Microsoft's end user customers data).
Furthermore, when trying to create such an app there is the following warning:
If I would create a development env for this I am still now working at a verified publisher, so I cannot develop an application to see if it fits our needs?
It is possible to have a developer sandbox from Microsoft for that purpose.
See https://learn.microsoft.com/en-us/office/developer-program/microsoft-365-developer-program-get-started for information on this
We develop .net core based web server app with web browser client. This app will be installed on our client's dedicated servers. Our app will include, among others, contacts and calendars and we want to allow users sharing data between our and cloud agendas (via Azure graph-api, Goods api) .
We registered our app in Azure (for now, we assume it will be very similiar for Google) and got some codes (client, secret etc.). Now, we are not sure, what's corrent auth/usage flow.
Client side - a new browser window will be displayd to the end user, asking for grand types and login, but then the server should ask for an access token, as it will interoperate then. As I understand - this is done by using "redirection_uri" going to the server address.
The main problem here is that when registering our app in cloud environment, limited redirection address list is defined and checked later with "redirect_uri" parameter. Our application will be installed on customers' servers and we don't want to force them to register their own applications in the cloud's administrations as they even will not have their own cloud subscriptions.
Edit 2020-11-18:
I'll try to describe again what is our task we want to find solution for:
We develop web app with browser based clients
We sell this app to other organizations and they will install it on their own servers and will have their own customers (final customers) using this app
These organizations don't have to have O365 subscriptions
We, as developers, want our internal app calendars and contacts (among others) to be connected to final customers' Azure/Google calendard and contacts.
It means, that the synchronization itself will be between organization's instance of our app and their customer's Azure/Google calendars/contacts.
I'm sure this must be quite common problem but I have't found any reliable answer.
What is the best way to do this. I can not find a link. Almost every example is using OAuth2 and native app version of the examples still wants the client app to pop up a browser.
My system does not have a browser. I can make REST requests but that is it.
I just want to use a simple client that can list things on a command line app just by using Outlook.com or Hotmail account. Not for a Work/School account (no Active Directory).
Long story short I don't want to be redirected to a website. I can make http request and parse the response.
These are my limitations. All implementations are in C or c++. Are there an examples with flow diagram?
Technically what you're looking for is the client_credentials grant. You can read about setting this up # Get access without a user.
This grant has some limitations. In particular, it only supports Work/School Accounts. This is because your application will require the consent of an administrator, something not available with a personal Microsoft Account (Outlook.com, XBox Live, etc.). You'll need an Active Directory to authenticate against. You can however set up Azure Active Directory for free.
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.