GNU bug report logs - #72358
29.4; oauth2.el improvements

Previous Next

Full log

Message #62 received at 72358 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Xiyue Deng <manphiz <at> gmail.com>
Cc: Robert Pluim <rpluim <at> gmail.com>, Thomas Fitzsimmons <fitzsim <at> fitzsim.org>,
 72358 <at> debbugs.gnu.org
Subject: Re: bug#72358: 29.4; oauth2.el improvements
Date: Fri, 02 Aug 2024 17:43:59 +0300

Xiyue Deng <manphiz <at> gmail.com> writes:

> Hi Thomas,
>
> Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:
>
>> Xiyue Deng <manphiz <at> gmail.com> writes:
>>
>>> Robert Pluim <rpluim <at> gmail.com> writes:
>>>
>>>>>>>>> On Tue, 30 Jul 2024 17:08:21 +0300, Björn Bidar via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> said:
>>>>
>>>>     Björn> Xiyue Deng <manphiz <at> gmail.com> writes:
>>>>     >> The fourth patch may need a bit of background: oauth2.el (optionally)
>>>>     >> uses plstore to save authentication data for future reuse, and the
>>>>     >> plstore id for an account is computed using a combination of `auth-url',
>>>>     >> `token-url', and `scope'.  However, this combination of data doesn't
>>>>     >> guarantee uniqueness for accounts for a same provider, e.g. for Gmail,
>>>>     >> the three parameters are the same for different accounts, and hence
>>>>     >> storing a second account information will override the first one.
>>>>
>>>>     Björn> Would it make sense to plug OAuth2.el into auth-source to store the
>>>>     Björn> authentication token safely inside an existing credential storage?
>>>>
>>>>     Björn> Various applications already do so when using the native credential
>>>>     Björn> storages such as Freedesktop.org or the macOS keyring.
>>>>
>>>> Yes. In fact thereʼs the auth-source-xoauth2 package that does
>>>> that. And oauth2 can already store stuff using plstore, so Iʼm sure it
>>>> can be extended to use auth-source.
>>>>
>>>
>>> auth-source-xoauth2 doesn't actually use auth-source
>>> (e.g. ~/.authinfo.gpg) to store the data it needs, but use a custom file
>>> storing an ELisp hash table to store the client-id, client-secret, etc.
>>> It does advice the authentication code to use the calculated token.
>>
>> I have not seen it mentioned in this thread yet, so here goes: my
>> url-http-oauth package in GNU ELPA supports storing credentials in
>> ~/.authinfo.gpg and refreshing them.  It would be nice if your OAuth2
>> work could get feature parity with it, then I could delete my package;
>> feel free to copy any code that makes sense.  (I do not use
>> url-http-oauth anymore, but I felt the need to write it when I was using
>> Excorporate and OAuth.)
>>
>
> Thanks for working on url-http-oauth!  I think it adds credential
> management using auth-source, e.g. prompt for client-id and
> client-secret and store them, which my other addon (that I'll post next
> as it depends on the changes I made here) didn't do.  Ideally this
> should be handled transparently by all auth-source backends and say Gnus
> when you add a new account, but IIUC currently the JSON backend doesn't
> support creation, which I'm using for ease to read and modify.


I think depending on the authentication storage it would make sense to
provide a custom setting with a sane default that allows the user to
configure a path inside the storage to store their credentials.
These could then have templates for the hostname, user, port etc just
like the regular search parameters that `auth-sources-search' supports.

>> Ideally you could get the result (and the xoauth2 support for IMAP and
>> SMTP) accepted in Emacs core.
>>
>
> That would be great!  My other addon uses advice, but it would
> definitely be better to be integrated in core (which already has partial
> support)
>

From Gnus point of view I think it would make it easier to support
auth-source as then Oauth support would come for free as then the
credentials can be retrieved just for basic authentication.

Some kind of hook or trigger to call renewal functions would be needed
though so that tokens can be refreshed transparently or manually if the
user needs to re-authenticate.

>> (Then, extremely ideally, the FSF could work out legal agreements with
>> the various OAuth providers to get Emacs registered as an OAuth
>> application, like, e.g., Thunderbird.)
>>
>
> That would be the best for the end user.  Imagine a Gnus user could just
> add a new account and on launch Gnus the default browser will open the
> login page (or be prompted an URL to visit), which then normally handles
> all the login shenanigans (2FA, authenticator, etc.) and viola, you're
> logged in.
>

To allow seamless authentication the FSF could make things much smoother
by registering Emacs with common providers, working with FSFE together
in this regard could help too (there are other countries than the U.S.).

The issue I see is that registering Emacs is not enough since Emacs is
in this context merely a runtime for these modes that want to use OAuth.
The scope of the permissions they need varies, so their names etc.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.