3

According to https://github.com/firebase/functions-samples/blob/master/email-confirmation/README.md

To be able to send emails with your Gmail account: enable access to Less Secure Apps and Display Unlock Captcha. For accounts with 2-step verification enabled Generate an App Password.

Looking at doc of node mailer, it seems like the most secure way of sending email via Gmail SMTP is http://nodemailer.com/smtp/oauth2/

My question is, assuming I gather all fields required to perform OAuth2 as suggested in send emails from MY gmail account with OAuth2 and nodemailer, is the OAuth2 method incompatible with Cloud Functions?

Will refreshToken be needed to generate a new accessToken on every invocation? That will certainly drive up the cost as the Cloud Function will take much longer to run, am I correct?

Is that the reason why the firebase functions samples in the github repo purposely did not include nor mention the more secure OAuth2 method?

Doug Stevenson
  • 297,357
  • 32
  • 422
  • 441
Henry
  • 32,689
  • 19
  • 120
  • 221

1 Answers1

4

It is possible to use OAuth with Cloud Functions. You can check this link for more information, but here is a little summary from it:

First, you would need to configure an OAuth client ID for its use with the Gmail API. After enabling the API and selecting the region, go to the Cloud Console and create the appropriate credential based on the function you are developing. It should include the application type, a name for your client and some authorized JavaScript origins, as shown in the link above. This will provide you a client secret you should store safely.

You would also need to configure some files based on the settings you applied in the Console, such as index.js and package.json, as well as renaming the client secret you received with the previous configuration. After adding the proper project and region to your files, it is time for deployment, using the commands included in the link to deploy the functions, initiating the deployment in the same directory where the index.js file is located.

As for the need to use the refresh token every time to generate new access tokens on every invocation, that would depend on when the access token is set to expire, or when you consider that your current access token is not secure. Refresh tokens can be used any time you see fit, but not for every invocation to the function as long as the access token is valid.

The costs will vary depending on how many invocations you are performing throughout the month, with the first 2 million being free, while the compute time costs may vary depending on how much memory and CPU are being used. Here you can check how Cloud Functions are currently priced. Operations such as using a refresh token to update an access token do not seem to have much effect on the costs, as far as I know.

All of this I explained is more related to Cloud Functions in general rather than Firebase. I am not familiar with the use of Firebase, but I would assume that since the functions samples are meant to be kept as simple as possible, they would include a more simple way of authentication. Anyway, you can add the OAuth option yourself, as you can see in the Firebase documentation.

I hope all of this helps you understand how to use OAuth with Cloud Functions.

Rodrigo C.
  • 1,114
  • 7
  • 13
  • Thanks! My concern would be the extra cpu time it will take to refresh the token and invoking of the restful api on almost every invocation. Therefore I'm staying with plain username/password with Less Secure Apps enabled right now so cloud function can handle the smtp server directly which should be much faster. – Henry Apr 17 '18 at 18:54
  • I would like to address your concern and comment that you should not worry about the extra CPU time. As you can see [here](https://stackoverflow.com/questions/45787676/how-to-authenticate-google-cloud-functions-for-access-to-secure-app-engine-endpo/46641164#46641164), the authentication process regarding tokens does not happen at instance level, and therefore CPU time is not affected by these operations, the most you would get would be a small impact on end-to-end latency. You can go ahead and keep your current configuration, but please let me know if you try the OAuth approach. – Rodrigo C. Apr 18 '18 at 13:44
  • I have always thought the 'latency' is also count towards cpu time. – Henry Apr 21 '18 at 00:37
  • As it is explained in the link I provided in my latest comment, the additional protection layer may have a small end-to-end latency impact, but this would not be significant as authentication happens outside the instance level. – Rodrigo C. Apr 23 '18 at 08:37