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).
Related
I have a web app which sends emails (gmail) in name of my users
When a user registers, she supplies gmail account and password. Also she has to enable access for Less Secure Apps (I recommend to create a new account for this)
Then I can open a gmail session
session = Session.getInstance(props, new javax.mail.Authenticator() {
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication(user.getEmail(), user.getPassword());
}
});
and send emails on her behalf.
Unfortunately this is going to stop working next 30th May, when Google will allow only OAUTH2 access
I have followed Java Quickstart for Gmail API and I have code up and running for sending emails with OAUTH2: enable gmail api, create an application on google cloud platform, grant send permission, oauth2 client id credential created...
The problem I have is I can't see a way to automatize this task because when creating an authorized credential, a consent screen displays on browser and you have to select the account to be granted manually (maybe because my app in google cloud platform is still pending to be reviewed)
Is there a way to infer the gmail account you want to access from the credentials file (client_secret.json)? Is there a way to automatize this?
No, or yes. It depends.
The whole point of OAuth2 is to improve security by working with authorization tokens rather than asking for user credentials. To do this the user has to consent to the app's access request, and thus the OAuth consent screen cannot be bypassed. This is
explained in Google's documentation. It's not related to your app's review status but rather it's the way OAuth works.
You can still work in a similar way, though . Instead of asking for username and password upon the user's registration you can redirect them to the OAuth consent screen so they can authorize your app. Make sure that your app is requesting offline access type and then you can retrieve an access_token and a refresh_token. These will essentially work as your credentials and you can use the refresh token to generate new access tokens when needed without having the user go through the consent screen each time.
The refresh token doesn't have a "natural" expiration so you can keep using it indefinitely, but there are a few scenarios where it will become invalid, such as it not being used for six months, the user changing passwords (if using Gmail scopes), the user manually revoking access, etc. In these cases you will need to direct them to the consent screen again to reauthorize your app.
In this sense, your app can still work automatically without user input except the initial setup, which you already had to deal with when they supplied you with their credentials. The refresh token expiration can even be compared to what you had to do when the users changed their passwords in your current workflow.
One exception to this are service accounts. If you and your users are part of a Google Workspace domain you can delegate domain-wide access to it, then the service account will be able to access user data without any manual input. Of course, this is because as the domain administrator you pretty much own all the accounts under it. But if you're working with a publicly available application you will have to deal with the limitations I mentioned above.
Sources:
Google's auth overview
Using OAuth 2.0 to access Google APIs
OAuth 2.0 for web applications
The OAuth consent screen
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.
In our service, we offer Google Sign-In alongside email/password sign in, and need to know when a user loses access to their Google account so we can disable an integration.
Without forcing the user to re-authenticate with Google Sign-In, how can we detect when they lose access to their connected Google account?
The approach that I am thinking through my search is
obtain access_token and refresh_token through OAuth 2.0 authentication when user signs in on our service with Google Sign-In, save them in our database
periodically, make request to https://www.googleapis.com/oauth2/v3/userinfo using saved access_token (we will get an error if user's google account is closed)
if access_token is expired, retrieve another one using refresh_token, then re-try step 2
Is this the right approach or is there a better way to achieve what we want?
Google OAuth 2.0 Tokens expire in 3,600 seconds. They are valid until they are revoked or expired.
When you request the access token, make note of the expiration time in your database and consider the token valid until expiration.
The other option is to continue validating the access token on every request which takes more time than it is usually worth.
Google does not have a callback mechanism to notify you of expiration or revoking of a token.
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 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.