Why is OAUTH not being more actively developed for SMTP and IMAP authentication?

Forums › IT Pro and developers › Why is OAUTH not being more actively developed for SMTP and IMAP authentication?

Aaroona

3196 posts

Uber Geek

#318698 12-Feb-2025 20:06

I'm aware that these protocols are very old, but they are two of the most used protocols (well, certainly SMTP is) on the planet I would say. Yet, it seems that the authentication for these services have not moved with the times.

Webmail clients now use oauth, allowing for 2FA/MFA options to be used. Microsoft have implemented oauth flows for all of their services - using outlook, Mac Mail and the iOS mail apps, you are redirected to their oauth flow to sign in.

Yet all other mail providers haven't even touched it. Zoho still allow username/password combo to sign in (not even using app passwords).

I believe the IMAP standard actually has an AUTH=External option, and I've seen auth=xoauth2, which suggests it might even be possible, but I've seen no actual implementation of it. And there is unknown support from clients (presumably none, beyond Microsoft's proprietary connections).

Email isn't secure at the best of times, but it seems that only putting 2FA on the web interface while allowing username/password combos on all other services like IMAP/CardDav/CalDav/SMTP, it's barely worth having, if you can just bypass the need for it?

marpada

476 posts

Ultimate Geek

#3342176 12-Feb-2025 20:30

Not a huge incentive for companies to adopt it, specially for the ones that offer free email as a loss leader, and its not something the average Joe would care about.

richms

28176 posts

Uber Geek

Trusted

Lifetime subscriber

#3342199 12-Feb-2025 23:03

Because they would rather that you were in their apps where they control the whole experience.

Richard rich.ms

SomeoneSomewhere

1804 posts

Uber Geek

Lifetime subscriber

#3342201 12-Feb-2025 23:21

Yup. Same reason reddit nuked all the third party apps. They can't serve adds or do nearly as much spying via an API (and IMAP etc. is basically a standard API) as they can via a web interface or native app.

BlakJak

1275 posts

Uber Geek

Trusted

#3342626 13-Feb-2025 21:23

I don't want to use MFA for SMTP or IMAP, as a rule.

I'd rather have standalone creds specifically for those protocols, that I can configure in the app(s) that'll use it, and that are invalid everywhere else, so i'm never gonna get phished into giving them away and thus the exposure is low...

I think i'd get exasperated if I had to MFA when running up Thunderbird on a machine I use infrequently but which is configured to talk to my IMAP account.

Whereas things entered via a browser can happen on untrusted devices, or be prompted via phishing or similar, this feels more like 'the right place'.

Bring on app and protocol-specific authentication, perhaps...

No signature to see here, move along...

Aaroona

3196 posts

Uber Geek

#3342627 13-Feb-2025 21:30

BlakJak:

I don't want to use MFA for SMTP or IMAP, as a rule.

I'd rather have standalone creds specifically for those protocols, that I can configure in the app(s) that'll use it, and that are invalid everywhere else, so i'm never gonna get phished into giving them away and thus the exposure is low...

I think i'd get exasperated if I had to MFA when running up Thunderbird on a machine I use infrequently but which is configured to talk to my IMAP account.

Whereas things entered via a browser can happen on untrusted devices, or be prompted via phishing or similar, this feels more like 'the right place'.

Bring on app and protocol-specific authentication, perhaps...

If you consider how Microsoft do it with OAUTH, you don't constantly get pinged. You have trusted devices once you have passed through MFA and login process, which then stores a token on your machine and it refreshes, without the need for interaction.

Still far superior to username/password only, even with app specific passwords. But app specific passwords are definitely better than using your usual username/password combo for webmail. Moving to oauth then allows you to use things like conditional access (if your auth platform supports it) to control the connections and reprompt for auth under certain conditions, but that is far more advanced than what even the usual pro-sumer would likely use. The main benefit imo, is the ability to use MFA to generate the token.

It just surprises me that the standards haven't really evolved to a point where Oauth is the defacto authentication mechanism, allowing for better security and control. As some have pointed out, for free services that makes sense since it costs money to invest, but for paid plans (which I use), it seems it should be in place imo. But the only provider I know doing it, and enforcing it, is Microsoft.

K8Toledo

1014 posts

Uber Geek

#3342628 13-Feb-2025 21:30

I removed 2FA on a client's xtramail account today (while migrating to gmail). Overkill and a PITA, also Spark CSR implied 2FA would prevent phishing attacks.

Side note, xtramail collected addresses totalled 1538

SirHumphreyAppleby

2844 posts

Uber Geek

#3342702 14-Feb-2025 07:05

Adoption is low because using OAuth2 with e-mail is a terrible idea. OAuth2 is an authorisation protocol, not an authentication protocol. Google and Microsoft are pushing it because it gives them control over what software you can use on their platforms.

Aaroona:

I believe the IMAP standard actually has an AUTH=External option, and I've seen auth=xoauth2, which suggests it might even be possible, but I've seen no actual implementation of it. And there is unknown support from clients (presumably none, beyond Microsoft's proprietary connections).

There are two SASL AUTH options for SMTP and IMAP, XOAUTH2 and OATHBEARER. Using these requires an OAuth2 token and that's where everything falls to pieces. There is no token exchange mechanism defined within SMTP or IMAP, so in order to obtain a token (and refresh token), you must use HTTPS. Adding a dependency on another protocol introduces a potential point of failure. If you receive an authentication error at the client end (with a GUI), the user can go in and fix it, but if your SMTP server relays via another that requires OAuth2 authentication, then it may go unnoticed.

Assuming you already have a token and refresh token, it's not much different from a normal password, with the exception that you must refresh the token (using HTTPS) when it expires. This leads to another problem... the refresh token also expires and it doesn't tell you when. Even if you know this (from the provider documentation), your e-mail software would need to ensure it keeps tokens alive, otherwise your e-mail again stops flowing. If, for example, you want to use a command line tool (that isn't running constantly in the background) to send a notification e-mail in response to some event, don't count on it working, period.

Beyond that, how OAuth2 is managed by each provider varies significantly. Applications need to be registered within each platform, either by the user or the developers. The provider may also limit API access based on the client ID or simply decide they do not like the software and block access. At least one provider invalidates tokens when you change your password, so a seemingly innocent (and security conscious) act could have unexpected consequences for e-mail delivery.

Over the years I've had many people ask about implementing OAuth2 in CMail. CMail is written in C and there was no suitably licensed OAuth2 implementation for C-based applications. C++ yes, but not C. I finally decided to try and tackle the issue myself, but it's proven to be a difficult task.

I published a version of CMail that implemented support for native 'apps', as that is the only type of access I can test with a free GMail account. In theory, with the right settings, it would work with Microsoft as well, but despite all the requests I have had over the years to implement OAuth2, in the seven months since publishing that build, I've had zero users give any feedback on the implementation or offer to assist with testing other 'app' types.

Almost every post on Reddit regarding sending e-mail recommends simply setting up an account with SMTP2Go instead of trying to tackle OAuth2. So, I think it's fair to say people don't really want it and it's not worth the hassle.

GoodSync

GoodSync. Easily back up and sync your files with GoodSync. Simple and secure file backup and synchronisation software will ensure that your files are never lost (affiliate link).

Aaroona

3196 posts

Uber Geek

#3344041 17-Feb-2025 23:45

SirHumphreyAppleby:

Adoption is low because using OAuth2 with e-mail is a terrible idea. OAuth2 is an authorisation protocol, not an authentication protocol. Google and Microsoft are pushing it because it gives them control over what software you can use on their platforms.

Aaroona:

I believe the IMAP standard actually has an AUTH=External option, and I've seen auth=xoauth2, which suggests it might even be possible, but I've seen no actual implementation of it. And there is unknown support from clients (presumably none, beyond Microsoft's proprietary connections).

There are two SASL AUTH options for SMTP and IMAP, XOAUTH2 and OATHBEARER. Using these requires an OAuth2 token and that's where everything falls to pieces. There is no token exchange mechanism defined within SMTP or IMAP, so in order to obtain a token (and refresh token), you must use HTTPS. Adding a dependency on another protocol introduces a potential point of failure. If you receive an authentication error at the client end (with a GUI), the user can go in and fix it, but if your SMTP server relays via another that requires OAuth2 authentication, then it may go unnoticed.

Assuming you already have a token and refresh token, it's not much different from a normal password, with the exception that you must refresh the token (using HTTPS) when it expires. This leads to another problem... the refresh token also expires and it doesn't tell you when. Even if you know this (from the provider documentation), your e-mail software would need to ensure it keeps tokens alive, otherwise your e-mail again stops flowing. If, for example, you want to use a command line tool (that isn't running constantly in the background) to send a notification e-mail in response to some event, don't count on it working, period.

Beyond that, how OAuth2 is managed by each provider varies significantly. Applications need to be registered within each platform, either by the user or the developers. The provider may also limit API access based on the client ID or simply decide they do not like the software and block access. At least one provider invalidates tokens when you change your password, so a seemingly innocent (and security conscious) act could have unexpected consequences for e-mail delivery.

Over the years I've had many people ask about implementing OAuth2 in CMail. CMail is written in C and there was no suitably licensed OAuth2 implementation for C-based applications. C++ yes, but not C. I finally decided to try and tackle the issue myself, but it's proven to be a difficult task.

I published a version of CMail that implemented support for native 'apps', as that is the only type of access I can test with a free GMail account. In theory, with the right settings, it would work with Microsoft as well, but despite all the requests I have had over the years to implement OAuth2, in the seven months since publishing that build, I've had zero users give any feedback on the implementation or offer to assist with testing other 'app' types.

Almost every post on Reddit regarding sending e-mail recommends simply setting up an account with SMTP2Go instead of trying to tackle OAuth2. So, I think it's fair to say people don't really want it and it's not worth the hassle.

Appreciate the detailed reply. Agreed, oAuth is not authentication, but is usually the way its denoted in the authentication modules when it comes to SMTP/IMAP/JMAP in the config files.

I guess sadly, as you've said, it's down to little reason for providers to invest in it.

Unfortunately due to the experience with CardDav with my new email service, I might have to look at going back to M365 mail for now.
It does seem that once you turn on MFA through Zoho, that they then force the use of Applicatino specific passwords.

I'll take a look at SMTP2Go. Thanks!