[kwlug-disc] Using mutt with oauth2

[Chris Irwin]

On Tue, Aug 25, 2020 at 02:22:05PM -0400, Paul Nijjar via kwlug-disc wrote:
>
>Welp, it looks like Yahoo! is disabling username/password
>authentication on October 20. Guess who is freaking out now?

Not a Yahoo user, and had to do some searching to find the annoucment 
(and still only found it second-hand), but it looks like they're only 
disabling access with an account password, but that the app-password 
functionality would still exist and work?

I'd just use an app password if possible because it is equally as secure 
for a user, and compatible with existing IMAP clients. Oauth, on the 
other hand, is a user-hating anti-feature, and you're going to have a 
lot of problems with it, particularly with niche software like neomutt.

>I see there may be support for Oauth2 in neomutt. Has anybody
>successfully gotten Oauth2 authentication working with mutt or
>neomutt? I think Gmail may have disabled user/password login a while
>ago, so maybe some of you have experiences and helpful tutorials to
>point me to?

I've always found mutt/neomutt's IMAP functionality annoying, so I use 
mbsync to a local maildir, then run neomutt directly on the local 
maildirs. I didn't get as far as getting my neomutt workflow going, but 
did attempt OAuth with Evolution. It wasn't a pleasant experience.

My work uses O365 for our email hosting, and Microsoft were originally 
due to disable everything but their "modern" authentication flow (oauth) 
earlier this year (but luckily delayed it due to COVID). This included 
even app passwords.

OAuth uses an application token, as well as a user token. The 
authentication is out-of-band (web browser popup), and if the user token 
is compromised, that token couldn't grant general access to your account 
via the web. So it's better than putting your account password in 
.netrc, but honestly that benefit was already achieved with an app 
password.

To support OAuth, *every* IMAP provider now needs to be updated to 
support OAuth workflow (including the annoying bits like token renewal, 
etc).

However, the client supporting OAuth is only half the battle. The 
provider must also support the client. Your local mail client now 
requires an API key to identify that the *application* is authorized, in 
addition to credentials to identify yourself.

They expect every email client developer to register their application 
with them, and ship the application with an API token. Then remember 
that those clients would be expected to do this for gmail, yahoo, o365, 
etc. There is a significant barrier to get a functional mail client.

I doubt mutt/neomutt is going to start shipping API keys for *every* 
mail provider out there, and likely require you become a "developer", 
register an application yourself. Evolution, for example, currently uses 
this approach for O365. It is fully capable of doing "modern auth" with 
O365, but they haven't registered or shipped API keys. Instead, we had
to have a *domain admin* create application IDs, grant it appropriate 
permissions, and load those API tokens into Evolution locally.

Also, since all access filters through an API key, if Microsoft decides 
they don't like Mutt? They revoke the API token, and no mutt users are 
able to get their email anymore. Or equally as bad, they rate-limit.

GNOME actually *did* register with Google so they can integrate 
calendar/contacts/etc into the UI. However, google integration stops 
working daily for *every GNOME user worldwide*, because they 
collectively go over the API quota. Google will apparently increase the 
quota for free, but this is simply annoying to deal with.

https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/89

I'm lucky that Microsoft pushed back their implementation, but I'm not 
looking forward to having to actually tackle this for real. App 
passwords offer the same security, and are already compatible with 
pre-existing clients.

(As an aside, Yahoo is now part of "Oath", making "Yahoo oauth" searches 
fun)

-- 
Chris Irwin

email:   chris at chrisirwin.ca
  xmpp:   chris at chrisirwin.ca
   web: https://chrisirwin.ca