OAuth SMTP support

[krokosik]

I've just spent several hours trying to set up Vaultwarden SMTP to work with my Microsoft 365 service. Tbf it was mostly due to Microsoft's settings being spread across many websites, docs etc., but the main takeaway is that they disable basic authentication methods by default and consider them obsolete. I've read that Google does the same and I have to say that I would also feel better without storing my password in plain text in an .env file.

I checked the meta feature issue and I did not see supporting XOauth2 auth method being listed, neither did I see any doc page in the wiki on how to use it. Is this feature planned?

[stefan0xC]

It's not planned and I'm not sure if it makes sense for a server side app to use it (even if the lettre crate technically supports Xoauth2 as authentication mechanism, cf. #2809) because as far as I understand it the access token would not be valid forever (even if it can be refreshed). I can't predict if we would refuse a PR that implements setting up OAuth 2.0 for mail authentication, but the simpler solution is probably to update the documentation that explains how and why to use an app password instead.

For Google/Gmail the SMTP-Configuration page already asserts that it can't be used without creating an app password because they force the use of two-factor authentication. I think Microsoft only requires an app password if you have enabled two factor authentication (cf. #3521 (reply in thread)), so this should probably be mentioned as well.

[Spunkie]

To add some context here. Google Workspace admins received this email 2 days ago reiterating the plan and dates for removing less secure apps auth this year.

---

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](https://support.google.com/a/answer/6260879).

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” 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.

[stefan0xC]

And if the response to this is that I should loosen the 2fa requirements on my orgs workspace, just so vaultwarden can send system emails, that sounds like a much bigger "workaround" to me.

My response would be not to use your protected Google Account but a separate mail provider. Implementing OAuth 2.0 just for your specific organizations need (because you've decided to use Google's security features which come with a tradeoff) is overkill.

[Spunkie]

Would I implement a whole separate mail provider and potentially increase my phishing, spam, and general attack surface across my entire org just to use vaultwarden?... Ya probably, Vaultwarden is great software, but it's still a shit ask. And I would point out, anecdotally, vaultwarden will stand alone as the only software in my entire orgs stack that would require this in 2024.

---

Also I know you mentioned the issue of access tokens would not be valid forever further up but App Passwords are not without their own quirks around this.

App passwords revoked after password change:

To help protect your account, we revoke your app passwords when you change your Google Account password. To continue to use an app with your Google Account, create a new app password.

Certainly you're likely to get at least a couple of orders of magnitude longer session from an App Password than an oauth token. But at least the oauth token renewal can be automated, versus the App Password that will at some point require manual intervention.

---

because you've decided to use Google's security features which come with a tradeoff

If I was to put some 4am manic sass on this. We've been using security keys here pushing a decade, yubikeys otp, to u2f, and to fido2(and now "passkeys"). I've never once felt we've needed to make "tradeoffs" of any kind when using security keys, it's been unequivocally nothing put positives. So it sure would be cool if we didn't have to start this year. 🦆👍

[BlackDex]

Well, we always like well written PR's which might add this feature, as long as it isn't hacked in of course.
If you know some way of generating the oauth2 token manually, you can use that in some scriptable way to add that to Vaultwarden via the ENV's, since lettre does support that authentication method if provided the correct token.

Also, you could use a proxy for this, now that might not be the most sexy way to implement this, but it is possible.
For example https://github.com/simonrob/email-oauth2-proxy, can do what you need. And if you want to use a container for this, there is an example for that same tool available here https://github.com/blacktirion/email-oauth2-proxy-docker

[BlackDex]

As an addition (and i have not tested it), you can generate those xoauth2 tokens by using one of these tools:

• https://github.com/ltratt/pizauth
• https://github.com/pdobsan/oama
• https://github.com/ahrex/oauth-helper-office-365

[stefan0xC]

I've never once felt we've needed to make "tradeoffs" of any kind when using security keys, it's been unequivocally nothing put positives.

If Google prevents you from doing something for security reasons (because it's pushing OAuth 2.0) then you are trading off security versus convenience, i.e. you not being able to set up your protected Google Account with services that either won't or at least have not yet implemented support for this authentication scheme (getting/refreshing the access token).
I'm sorry that this open source project is not up to your expectations but implementing a new industry standard also takes time and effort (i.e. to learn the specs, develop the libraries and expand the larger ecosystem) and this is still a volunteer driven project (though Bitwarden does not have support for that yet either). I'm sure if this becomes more ubiquitous and the demand higher that someone will look into it and make a PR eventually.

[krokosik]

UPDATE: Microsoft has just announced that they will remove basic auth all together:
https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-online-to-retire-basic-auth-for-client-submission-smtp/ba-p/4114750#:~:text=Exchange%20Online%20to%20retire%20Basic%20auth%20for%20Client%20Submission%20(SMTP%20AUTH),-%E2%80%8EApr%2015&text=Today%2C%20we%20are%20announcing%20that,SMTP%20AUTH)%20in%20September%202025.

[macmillernz]

+1 for this feature
I'm a Microsoft 365 user who wants the convenience of using my personal email.
Setting up an smtp proxy or another email domain is not an option for me.

[BlackDex]

Why isn't that an option?? You can setup Vaultwarden, and maybe even a reverse proxy for Vaultwarden like nginx or traefik or caddy or haproxy. But not something for your email?

I'm sorry, but implementing a feature like this will take a lot of time and testing and I would rather put the time i have into other features, especially if there are other tools who can do this a lot better.

[mattpr]

Google Workspace "app passwords" are also on their deathbed.

Normally for server-side apps, you would either just provide a little "authorize email" flow from the admin UI to generate the access token, or you just leave it as a config and give users some basic directions around specific tools to generate the tokens.

The problem with supporting this natively in any serverside app is that while SMTP is fairly generic, oauth for SMTP is not...because the app needs to be aware of things like what scopes/permissions are needed on google vs microsoft vs _____ in order to have the oauth token grant the permissions needed. There are also things like requirement for a google developer project to be created to manage the oauth integration which has a bunch of hoops associated with it (for self hosting, individual hosters need to setup their own google projects for oauth). So supporting oauth for SMTP has to be done per platform (google, microsoft, etc) rather than once for all platforms. ...unless there is a shortcut I'm missing.

[c0fe]

@mattpr Agreed, this is why I think having OAuth support for GMail and Microsoft Outlook would be sufficient in this case.