Re: oauth2 support for Emacs email clients

[Thomas Fitzsimmons <fitzsim@fitzsim.org>]

David Engster <deng@randomsample.de> writes:

>> David Engster <deng@randomsample.de> writes:
>>
>>>>   Others have mentioned "officially" registering Emacs as IMAP/SMTP
>>>>   clients for Office365 (and possibly Gmail), similar to what seems
>>>>   to be the case for Thunderbird.  I am wondering how davmail is
>>>>   doing this.
>>>
>>> Microsoft has actually recognized that it does not make sense for
>>> desktop applications to embed secrets into their code, so they
>>> distinguish between "public" and "confidential" client applications:
>>>
>>> https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-client-applications
>>>
>>> Public client applications do not have a client secret but only an ID
>>> which can simply be embedded into the application, which is how DavMail
>>> does it. Public client applications are only allowed to access web APIs
>>> on behalf of the user, but this is usually enough.
>>
>> Interesting, but are public client applications allowed to use
>> IMAP/SMTP?  Or must public client applications use WebDAV to communicate
>> with Microsoft servers, like DavMail does?
>
> As I've written: Public client applications are only allowed to access
> web APIs, so no IMAP/SMTP.

OK; I wasn't sure if by "web APIs" you meant only "OAuth-related web
APIs".  Thanks for confirming.

I wonder why Microsoft does not allow public client applications to use
IMAP/SMTP.

> I usually use DavMail to get my mail downloaded to a locally running
> IMAP server.
>
> So yes, simply registering Gnus as a public client is not enough, one
> would also need a new backend specifically for Exchange.

Hmm, yeah.  I'd prefer to keep using IMAP/SMTP, standards designed for
email.  Excorporate does some email operations via EWS, but it seems
strange to extend Excorporate (and make a Gnus backend for it) to handle
all of email just to avoid application registration issues with a new
IMAP/SMTP authentication method.

IMAP/SMTP are already implemented and work fine for other email
services, and they can authenticate via OAuth (assuming registration is
sorted out).

>> It seems like Thunderbird could act as a public client application,
>> however I believe it is currently acting as a confidential client
>> application.  I wonder why.
>
> Because they want to use IMAP/SMTP.

Maybe the FSF could request that Emacs be registered as a public client
application and also be allowed to use IMAP/SMTP.  That would solve the
"embedding a secret in Free Software" part of the OAuth registration
issue, at least for Microsoft servers.

Thomas