I am trying to be able to set up a cron job to read contents from a certain email in my gmail inbox daily. I lookeed up gmail api documentation and noticed that the only way to authenticate my requests to access email data is via OAuth 2.0 which requires user authorization. Is there a way to authorize my app to access emails from a particular email id without the need for the user to manually take any actions.
I found this: https://developers.google.com/identity/sign-in/web/server-side-flow. I was wondering if there is any way to follow this workflow without having to build the UI?
Technically speaking you can use Oauth2 you just have to have the user authentication your application once. You will get a refresh token then you can use the refresh token to get a new access token from cron. Unless this is a Google domain account you cant use service accounts. There is no way to pre authorize a service account to access a normal user gmail.
Alternative: have you considered going directly though the mail server? Skip the rest api. https://developers.google.com/gmail/oauth_overview Note: That page also speaks of XOauth2 I haven't tried it yet you can still access SMTP and IMAP using username and password.
Related
How to send service emails
from my backend with smtp.google.com or Gmail API while making sure
the secret stored on the backend server can only be used to send emails from a specific sender?
Goal
send user account activation emails from my backend
use smtp.google.com or Gmail API (i.e. no own SMTP server)
authenticate with OAuth2.0 (i.e. don't enable "less secure apps")
Current state
implemented the email sending part
for testing, I created a noreply#**.** Google Suite account
for testing, I generated an accessToken via OAuth2 Playground
using the accessToken I can send emails via smtp.googl.com
Problem
Google suggests to use a service account for this
But to send emails from no-reply#x.y I have to enable Domain-wide Delegation
Domain-wide delegation allows to impersonate every domain account
the secret stored on the backend should only allow to send mails from no-reply#**.**
Lets start with send user account activation emails from my server I am gong to assume that you have a web app. This web app allows users to register with your system. Now when a user registers with your system you want to automatically send them an account creation email. Your idea is to use Google rather than setting up your own smtp server and sending these emails from your own system. Not a bad idea really.
Lets think about this for a minute the emails would need to be sent automatically so you need some kind of service sending them. To do that you want to use a service account. Again this is a great idea using a pre authorized service account that you will not need to have a user to authorize the app.
The only issue is that service accounts do not work with normal gmail accounts. To use a service account with Gmail api you need to use a google workspace domain account. The workspace domain admin would then be able to add permissions to the service account letting it act like a user on the domain. In this case your idea of no-reply.
So your workspace domain account would have a user called no-reply. The domain admin would then configure domain wide delegation to the service account allowing it to pretend that it is the user called no-reply. For all intents and purposes the service account is the no-reply user. It will be able to send mails as if they are coming from that user.
For all this to work you will need the workspace account with that user.
Have a look at the following link, it's actually one of Google's better examples it shows how to set up the delegation.
Perform Google Workspace Domain-Wide Delegation of Authority
Here you create a service account with credentials, allow this account to impersonate other users (e.g. the no-reply user), to only use the Gmail API and to only use it to send emails.
the documentation is a bit outdated, you can skip the step Grant users access to this service account and create the service account key afterwards via the service account edit function: Manage keys
in the step Domain wide delegation you need Google Admin not the Google Cloud Platform Admin Console as in the previous step
Just remember to swap out the lines about
https://www.googleapis.com/auth/admin.directory.user,
https://www.googleapis.com/auth/admin.directory.group
and use
https://www.googleapis.com/auth/gmail.send
instead as you want to access the Gmail API and only allow the service account to send (not read) emails
tip
in the sample code in that link
.setServiceAccountUser(userEmail)
userEmail is the email address of the user you want to impersonate in this case no-reply#x.y
So I guess what I am saying is that what you want to do is definitely possible, however, it may be easier just to set up your own SMTP server.
I've found plenty of information on implementing Oauth2 using a user authorization step, but I'm trying to run a container that automatically scrapes a gmail inbox for attachments transforms them, and exports to prometheus, and I'm having trouble figuring out how to implement this library: https://pkg.go.dev/golang.org/x/oauth2/clientcredentials#Config or any other for that matter to retrieve a token without involving a manual user step.
Will doing this in Go require writing direct API calls since I can't find an existing library to handle this scenario? Would it make more sense to create a Google App password and use generic user/pass SMTP authentication?
First off i understand what you are trying to do.
You have a backend system running in a container which will access a single gmail account and process the emails.
Now you need to understand the limitations of the API you are working with.
There are two types of authorization used to access private user data
service account - server to server interaction only works with workspace domains. No authorization popup required.
Oauth2 - authorize normal user gmail accounts, requires user interaction to authorize the consent screen
If you do not have a workspace account and this is a normal gmail user then you have no choice you must use Oauth2, which will require that a user authorize the application at least once.
Using Oauth2 you can request offline access and receive a refresh token which you can use to request new access tokens when ever you wish. The catch is that your application will need to be in production and verified, because your refresh token will only work for seven days and then it will expire. To fix this and get a refresh token that does not expire means that your application must in production and verified. This means you need to go though Googles verification process with a restricted gmail scope which requires third party security check and costs between 15k - 75k depending upon your application.
I understand that this is a single user system but that does not mean that you still need to go though verification. When google added the need for application verification they did not take into account single user systems like yours.
Option
Have you considered going directly though the SMPT server instead of using the Gmail api? If you use an apps password you should bypass everything by loging in using the login and the apps password.
I'm developing an application that utilizes Google sign-in and the Gmail API. My test users, once logged in, keep receiving an email like the attached file.
Other applications with similar functionality (basic email access) do not seem to trigger these emails. Any ideas? It makes my app seem less trustworthy.
One possibility is that you are obtaining tokens with offline=true indicating a requirement to use the refresh token to renew expired access tokens. If you only require short-term access, perhaps you should remove the offline parameter in the construction of your auth request link.
In this scenario once the access token expires, then the scope will no longer be usable or renewable and so your end-users should not receive the alert emails.
I am creating a service where people will send emails to this one email account and this email account will regularly poll for new emails. The problem that I am having is that I will need to authenticate my email account and allow my service to call Google APIs to read it's mail box.
I was wondering if it would be alright to just authenticate myself once before deploying the service and then storing the access and refresh tokens in a database and then using those tokens to make the API calls. Are there any foreseeable problems such as the tokens expiring?
And if there are, do you have any suggestions on making API calls to the account without me having to login to the account to authenticate myself?
What you are wondering is correct. As you are getting a refresh token, you are asking for offline access which means you want make API calls on behalf of the user when is not present.
Access tokens have an expiration time, refresh tokens don't. However, there are some scenarios where refresh tokens could be revoked (and you need to handle them). So you have to use access tokens to make API calls and refresh tokens to generate new access tokens (when those have expired).
I am writing this goroutine that'll call the GMail API and poll my inbox every 2 minutes or so. The problem I am having trouble with is the authentication part because it'll need me to login and authenticate myself and give authorization to the app to read my inbox. I am trying to eliminate the part where I will need to login via the Web UI and give access to my program. Does anyone have any ideas on how to login and authenticate myself programmatically?
You should be able to use the steps here in order to generate and OAuth client ID, then use that to connect using oauth?:
https://github.com/google/GTMAppAuth/blob/master/Example-macOS/README.md
Failing that, you could use IMAP access to bypass the api entirely. Turn on imap in settings and use a library like this to access your messages:
https://github.com/emersion/go-imap/blob/v1/README.md