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

Previous Next

Full log

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

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

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.

> 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)

> (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.

> Thomas

-- 
Xiyue Deng

Previous Next

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