Hacker News Reader

Comment by mfsch | Hacker News Reader

From what I gather it should be possible to use 2FA with JMAP. I‘m looking forward to no longer having to decide between using third-party email clients and properly securing the account that’s probably most worth securing.

View on HN

What would be nice is if the servers supported using client side certificates as an authentication factor. It's possible to configure postfix and dovecot to support this [1], but I haven't looked into whether it's possible to require both the certificate and the username and password to authenticate.

[1] https://blog.mortis.eu/blog/2017/06/dovecot-and-postfix-with...

For IMAP already, there are three main approaches to logging in that get used: use your main password for the service to access IMAP, use a separate token for each client (“app passwords” is the most common term of art, and what we call them at Fastmail), and OAuth, which can then have whatever restrictions you like, 2FA or whatever. IMAP providers each support one or more of these techniques. (At this time, we support the second. Gmail supports the third and, if you have “less secure apps” turned on, the first.)

The JMAP core deliberately doesn’t express opinions about authentication technique, because that’s a divisive topic where there is no clearly right answer. We shall see what happens there; conventions will rise.

For Fastmail’s internal JMAP usage, we have our own authentication flow, which will entail 2FA if you have that set up on your account. I cannot remark at this time about what our plans are around authentication for public JMAP access.

But this is my conclusion here: look, I love JMAP, but I don’t believe it actually changes anything on this front over existing email protocols.

Would WebAuthn support be possible with JMAP? That would really move things forward.

One high level problem that jumps out at me is: When do we authenticate?

For web sites WebAuthn drops nicely into the existing login flow. The user knows what they're trying to do is log in, and so when they're prompted to touch the button or whatever it makes sense in that context.

But today most email apps just silently update all the time. So are we authenticating when the app starts and then re-using some credentials obtained to re-connect as necessary? Is that safe? Even if that's all we do (which might be safe) it means the user gets prompted for WebAuthn (to press the button) when the mail app starts, even if they aren't currently interested in email. If they dismiss it, when do we prompt them again? Because meanwhile they of course don't get any new email.

Probably the same as now. Authentication with user supplied credentials grants you a long-living session for the current device and current mail application via a locally stored secret unlocked by the user logging on to his computer or unlocking his device (which too could be done via WebAuthn or a similar 2FA approach; e.g., a fingerprint on a smartphone).

It can be invalidated by exceeding an age limit or by the user logging out or otherwise retracting the access grant.

OAuth2 can handle this; you authenticate the mail client with an offline token that's valid for a long time. The mail client can refresh their tokens regularly and use a short-live token to authenticate their JMAP requests.

OAuth2 doesn't particularly care how the token is obtained, so it can handle any arbitrary authentication flow, including WebAuthn.

And it's a widely supported protocol; there are libs for C++, Java, Go, JS and others, so it should be easy to integrate.

Reply on news.ycombinator.com