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
