[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: oauth2 support for Emacs email clients
From: |
Thomas Fitzsimmons |
Subject: |
Re: oauth2 support for Emacs email clients |
Date: |
Sun, 08 Aug 2021 11:30:55 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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
- Re: oauth2 support for Emacs email clients, (continued)
Re: oauth2 support for Emacs email clients, Richard Stallman, 2021/08/03
Re: oauth2 support for Emacs email clients, David Engster, 2021/08/08
Re: oauth2 support for Emacs email clients, Thomas Fitzsimmons, 2021/08/08
Re: oauth2 support for Emacs email clients, David Engster, 2021/08/08
Re: oauth2 support for Emacs email clients,
Thomas Fitzsimmons <=
Re: oauth2 support for Emacs email clients, David Engster, 2021/08/08
Re: oauth2 support for Emacs email clients, Roland Winkler, 2021/08/08
Re: oauth2 support for Emacs email clients, Thomas Fitzsimmons, 2021/08/09
Re: oauth2 support for Emacs email clients, David Engster, 2021/08/10
Re: oauth2 support for Emacs email clients, Thomas Fitzsimmons, 2021/08/10
Re: oauth2 support for Emacs email clients, David Engster, 2021/08/10
Re: oauth2 support for Emacs email clients, Alexandre Garreau, 2021/08/11
Re: oauth2 support for Emacs email clients, Richard Stallman, 2021/08/10
Re: oauth2 support for Emacs email clients, David Engster, 2021/08/11
Re: oauth2 support for Emacs email clients, Richard Stallman, 2021/08/12