You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
node-red-node-email
This node will be incapable of using Gmail within the next few months unless modified to connect with OAUTH2.0
Today I received a Google announcement that reads as follows:
Starting September 30, 2024, Google Workspace accounts will only allow access to apps using OAuth. Password-based access (with the exception of App Passwords) will no longer be supported. POP and IMAP are NOT going away and can still be enabled with apps that connect using OAuth.
Dear Administrator,
We’re writing to remind you that as we previously shared in this blog post and in an email sent in mid-January, we’ll be turning off access to less secure apps (LSA) — non-Google apps that can access Google accounts with only a username and password (basic authentication) — starting June 15, 2024.
What do you need to know?
Access through basic authentication makes accounts more vulnerable to hijacking attempts. Moving forward, only apps that support a more modern and secure access method called OAuth will be able to access Google Workspace accounts.
Access to LSAs will be turned off in two stages:
Beginning June 15, 2024 - The LSA settings will be removed from the Admin console and can no longer be changed. Enabled users can connect after that time, but disabled users will no longer be able to access LSAs. This includes all third-party apps that require password-only access to Gmail, Google Calendar, Contacts via protocols such as CalDAV, CardDAV, IMAP, SMTP, and POP.
The IMAP enable/disable settings will be removed from users’ Gmail settings.
If you’ve been using LSAs prior to this date, you can continue using them until September 30, 2024.
Beginning September 30, 2024 - Access to LSAs will be turned off for all Google Workspace accounts. CalDAV, CardDAV, IMAP, and POP will no longer work when signing in with just a password — you will need to login with a more secure type of access called OAuth.
What do you need to do?
In order for your end users to continue using these types of apps with their Google Workspace accounts, they must switch to a more secure type of access called OAuth (a list of affected users is attached). This authentication method allows apps to access accounts with a digital key instead of requiring a user to reveal their username and password. We recommend that you share the user instructions (in this PDF file) with individuals in your organization to help them make the necessary changes. Alternatively, if your organization is using custom tools, you can ask the developer of the tool to update it to use OAuth. Developer instructions are also in this PDF file.
MDM configuration
If your organization uses a mobile device management (MDM) provider to configure IMAP, CalDAV CardDAV, or POP profiles, these services will be phased out according to the timeline below:
Beginning June 15, 2024 - MDM push of password based IMAP, CalDAV, CardDAV, and POP will no longer work for customers who try to connect for the first time. If you use Google MDM, you will not be able to turn on "Custom Push Configuration" settings for CalDAV and CardDAV.
Beginning September 30, 2024 - MDM push of password based IMAP, CalDAV, CardDAV, and POP will no longer work for existing users. Admins will need to push a Google Account using their MDM provider, which will re-add their Google accounts to iOS devices using OAuth. If you use Google MDM, “Custom push configuration-CalDAV” and “Custom push configuration-CardDAV” (more details about the settings here) will stop being effective.
Other less secure apps
For any other LSA, ask the developer of the app you are using to start supporting OAuth.
Scanners and other devices
For scanners or other devices using simple mail transfer protocol (SMTP) or LSAs to send emails, configure to use OAuth, use an alternative method, or configure an App Password for use with the device. If you replace your device, look for one that sends email using OAuth.
Since the node description details how to use OAUTH2.0 for Exchange and Office365, it seems all that should be needed is to check how this code can be used for Gmail IMAP. The announcement contained a link to developer instructions here
What are the steps to reproduce?
N/A
What happens?
N/A
What do you expect to happen?
Hopefully the node will be modified to use OAUTH2.0 with Gmail
Please tell us about your environment:
Node-RED version: V3.0.2
node.js version: v18.19.0
npm version: v10.2.3
Platform/OS: "Alpine Linux v3.19"
Browser: Iron Version 122.0.6200.0 (Official Build) (64-bit)
The text was updated successfully, but these errors were encountered:
the note you copied does say "...or configure an App Password for use with the device..." - so it may still work, but yes we'll have to keep an eye on it .
Yeah, so far app passwords still work, knock on wood :)
I noticed that Auth type XOAuth2 seems to be supported by the email node. I decided to preemtively play around with it, downloaded the oauth2 node, but did not really make any headway.
Anyone had more success? Would be nice to be ahead of the curve with a solve for Oauth2 before September.
Yeah, so far app passwords still work, knock on wood :)
I noticed that Auth type XOAuth2 seems to be supported by the email node. I decided to preemtively play around with it, downloaded the oauth2 node, but did not really make any headway.
Anyone had more success? Would be nice to be ahead of the curve with a solve for Oauth2 before September.
This node was v recently (last week) updated to better handle googles oauth after a separate ticket i raised about it not being supported, so this may work now.
Which node are you reporting an issue on?
node-red-node-email
This node will be incapable of using Gmail within the next few months unless modified to connect with OAUTH2.0
Today I received a Google announcement that reads as follows:
Since the node description details how to use OAUTH2.0 for Exchange and Office365, it seems all that should be needed is to check how this code can be used for Gmail IMAP. The announcement contained a link to developer instructions here
What are the steps to reproduce?
N/A
What happens?
N/A
What do you expect to happen?
Hopefully the node will be modified to use OAUTH2.0 with Gmail
Please tell us about your environment:
The text was updated successfully, but these errors were encountered: