OAuth2 in node-red-node-email

Recently, Microsoft has depreciated the use of basic authentication across a range of protocols on it's Exchange platform:

Microsoft Basic Auth Deprecation

The new method is OAuth2.0, which is not supported by the email node yet. I'd like to make this a feature request / pull request.

I assume many flows make use of the email node, and a decent portion of them will use Office365. Eventually SMTP will be under the hammer too, so updating this node to accommodate all of these protocols seems like a logical step.

The updated nodes would allow OAuth/XOauth2 tokens as a form of authentication for IMAP, POP and SMTP. Looking purely at the documentation for the likes of IMAP, OAuth tokens can already be passed as arguments in the constructor, but this functionality isn't exposed in the email node just yet. So I believe this would require minimal changes.

The process of acquiring tokens would be done by nodes upstream (such as node-red-contrib-oauth2).

For full disclosure I am not a full time developer, but rather focus on integration of services within my industry. So while I can create a branch and update some UI elements, my abilities are sorely lacking beyond that. But I'm happy to try!


My fork is here.

So far have IMAP to MS Exchange working using XOauth2 by pulling the access token from "node-red-contrib-oauth2". Working on POP and SMTP soon after clearing some error messages.

I'm also doing the formatting and base64 encoding internally, but this format only works for the likes of Exchange and GMail. I'll add an option to pass the SASL token instead allowing users to do their own formatting if they want to.


I presume you’re familiar with the MS Graph API.

Well, a while ago I implemented a subflow, that sends email using the API.

It could make for an interesting resource for you.


I built it In view that SMTP isn’t going to be around in the future, with Microsoft pushing the azure platform hard these days.

For our legacy systems, that still use the SMTP protocol, I built a dumb SMTP ingress server in node, that just sends the payload to this subflow.

These legacy systems are using the azure platform without knowing :smiling_imp:


Since basic authentication for SMTP is still supported for now, I had this further down the list - but this is awesome! Most clients I use won't end up supporting modern authentication for a long time, so this is absolutely perfect for me.

My goal is still to update the email node to use continue using these old protocols in a modern way (for however long they stick around for). Ideally flows could be created doing exactly what you've done, but hopefully with far less work :wink:

But perhaps you're right, maybe these standards will disappear and we'll all just be using APIs for emails in future. If we're still using emails at all.

I don't believe SMTP is going anywhere. It is a worldwide standard used by billions of people :grin:

Enable or disable SMTP AUTH in Exchange Online | Microsoft Learn

It is legacy auth that is going because it can't withstand modern attacks.

1 Like

Could you imagine :grimacing:

Probably a wrong choice of words here :sweat_smile:

1 Like

Yes a PR would be most welcome (assumiing it doesn't break existing configs :slight_smile: )
Please go ahead.

1 Like

Hi all,

PR is here. But I do have some problems, and I would welcome the criticism of those more experienced than I to resolve them.

The changes that I have made have been tested against Microsoft Exchange using XOAUTH2 for IMAP and POP. I have also tested against Gmail using passwords for IMAP, POP and SMTP. But I have not been able to try out XOAUTH2 on Gmail, or on SMTP at all. This is mainly because I haven't been able to use the OAuth2 node with Gmail at this stage, since it doesn't support the "Client Credentials" grant type. Perhaps someone else has had some experience with this using "Authorization code"?

I found that the unit tests for email out began failing after I added additional error messages if the username and password were not present. However the tests conducted did specify credentials - but still produced "nouserid" messages. The reason is that the testCredentials parameter (when passed as a function) is turned into Call Back function - so credentials are assigned after the flow is loaded, at which point the node has already thrown errors indicating a lack-therof. The original tests now pass because it looks for its expected error further down the list. Not my favorite solution.

If there are additional steps I need to take to make this work for everyone, I'm still happy to try. I encourage all opinions on operation and usability.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.