# 2FA for Dovecot / Opensmtpd?



## hbauer (Jul 31, 2022)

Hi to all, in general you are told to use 2FA for your mail if possible. The majority of this targets Webmail users.

You can find tons of documentation to enable 2FA authentication for ssh but I have not found anything in this direction for dovecot / opensmtpd.

How could you achieve this?

Regards, Hagen.


----------



## pboehmer (Aug 1, 2022)

For dovecot, I think you want to use Oauth2, which is detailed here:

https://doc.dovecot.org/configuration_manual/authentication/oauth2/

This has been on my todo list for some time, but it seems every time I start looking into it, the more confused it get.  If anyone ever does a full step-by-step, I would be very grateful if they would share it.  I'd like to use local validation instead of a 3rd party (Google API, etc).

I'm still trying to wrap my head on the reasoning for requiring 2FA on outbound email.  My companies' insurance is pushing for us to implement this as well.  Looks like there is plenty of discussion on trying to get 2FA implemented on OpenSMTP over the past couple of years, but I'm not finding any solutions.


----------



## zirias@ (Aug 1, 2022)

pboehmer said:


> For dovecot, I think you want to use Oauth2, which is detailed here:


Note this isn't related to 2FA _per se_, it just means authentication is delegated to another system. All you get is some "token" (an access token) that you can verify. The user will only be able to get hold of that token by properly authenticating with the identity provider.

But then, that's probably your best bet. Many Oauth/OIDC identity providers support 2FA.



pboehmer said:


> If anyone ever does a full step-by-step, I would be very grateful if they would share it.


Can't help here, I never tried using it with dovecot ...



pboehmer said:


> I'd like to use local validation instead of a 3rd party (Google API, etc).


This however is a misunderstanding. You always need a "3rd party", it could of course be your own if you operate your own identity provider.

Whether "local validation" (of the access token you're presented) is possible depends on the nature of that token. If it is a cryptographically signed JWT, you can validate it. But note there's a drawback, you won't have a way to revoke such tokens – so they should really be short-lived. If it is a "reference token" (just some opaque string), you must ask your identity provider whether it's valid (IIRC that's what the introspection endpoint is for).


----------

