Add XOAUTH2 support?

Alexander Perlis aperlis at math.lsu.edu
Wed Apr 3 23:47:19 UTC 2019


RFC 7628 standardized the SASL OAuth2 binding under the name
OAUTHBEARER, but currently some servers (e.g., imap-mail.outlook.com)
advertise only the nonstandard precursor XOAUTH2. (Seems XOAUTH2 might
have come out of Google and also was adopted by others including
Microsoft. Later RFC 7628 came into being. Google added support for
OAUTHBEARER, but Microsoft has yet to do so. Here's the anachronism:
guess who authored RFC 7628?)

Mutt supports OAUTHBEARER. Would patches adding XOAUTH2 be welcome?

This would for example allow Mutt to connect with OAuth2 authorization
to a personal Microsoft account (@hotmail, @outlook, @live). In
principle it could also allow connecting to a work/school
(organizational Azure AD Office365) account, but I don't want to get
anyone's hopes up: whereas the scope "wl.imap wl.offline_access" is
acceptable both to the IMAP server and to the personal account
endpoint, I haven't found a scope that is acceptable both to the IMAP
server and to the Azure AD account endpoint.

Producing XOAUTH2 patches for Mutt should be easy: as far as I can
tell, the only difference between OAUTHBEARER and XOAUTH2 is the
BASE64 payload of name/value pairs being submitted. With OAUTHBEARER
the payload is

   n,a=ACCOUNT,^A    <-- note two commas
   host=HOST^A
   port=PORT^A
   auth=Bearer ACCESSTOKEN^A^A

whereas with XOAUTH2 it is

   user=ACCOUNT^A    <-- note no commas
   auth=Bearer ACCESSTOKEN^A^A

Here are two different approaches on how Mutt could handle XOAUTH2:

   (1) Purely behind-the-scenes. The user continues specifying
   imap_authenticators="oauthbearer", but Mutt treats this as meaning
   "use OAUTHBEARER when advertised, otherwise fall back to XOAUTH2 if
   it is advertised".

   (2) User explicitly specifies. The user can specify
   imap_authenticators="oauthbearer:xoauth2" if they're happy with
   either method, or could for example specify
   imap_authenticators="xoauth2" to force use of XOAUTH2.

The latter approach strikes me as more flexible for dealing with
unusual servers, for example a proxy server that might send
OAUTHBEARER to one back-end infrastructure and XOAUTH2 to an entirely
different back-end infrastructure. (Sounds far-fetched, but Microsoft
itself could become such an example if XOAUTH2 continues working with
scopes from their personal account infrastructure whereas OAUTHBEARER
is added to work with new scopes coming out of the Azure AD
infrastructure.)

Any thoughts/suggestions/concerns?

Alex


More information about the Mutt-dev mailing list