[RFC] 2FA/SSO considerations for Mailu

In #783 we talk about the building blocks required for 2FA to make any sense; Here I would like to explore options.

what would we require 2FA for?

• All web-logins?
• Only some privileged actions? If so, which and do we need more than one level of vertical segregation?
• When we think something has changed? (once in a while/freshness or when we fingerprint a new device)
• When we think something risky is attempted? (not sure how that would apply in the context of Mailu)

how would provisioning work?

• Admin creates a user: does it mean he enrolls the 2FA rigmarole or send the user a temporary password/token that puts him on the enrollment route (and we accept that until it's initialized there is no 2FA)? Is it worth having a more complicated scheme where the administrator has two pieces of info he needs to communicate (potentially on different channels) to the user?
• client (auto)configuration?

what would be the fallback/recovery mechanisms?

• Are we happy with just "talk to admin"?

zero-touch/passwordless auth (where you don't even have to remember your username/email: you show up on the login page, activate your token and you're authenticated)

If we decide to support something of the sort we need to think about it from the get-go. Usually login processes are "journeys" spanning several steps/pages.

reach

• should we disable non-2FA ways of authenticating? (disable IMAP/PLAIN in favour of xoauth2? what about existing tokens?)
• should we allow to "add" alternative ways of authenticating rather than enforce 2FA everywhere?
• should there be mandatory factors?

technologies

Once the above has been answered we can talk about technologies and user experience:

• webauthn (trendy, phish-proof, easy, clearly where the industry is going ATM)
• TOTP (rfc6238, standard)
• fingerprint devices / threat intel / AI
• oauth2 client (to enable "login with Google/Facebook/...": that requires configuration) see #1984
• "send me a link on my backup email"
• "send me a text" (would require configuration and $$)
• consensus based approval for account resets (get X authenticated users to click on XXX to receive your reset token)

Keeping in mind that all of the above is not an option for next release ;)