Subject: bug#72358: 29.4; oauth2.el improvements

From: Xiyue Deng <[email-masked]>
Date: Wed, 31 Jul 2024 00:43:34 -0700

Björn Bidar <[email-masked]> writes:

> Xiyue Deng <[email-masked]> writes:
>
>> Björn Bidar <[email-masked]> writes:
>>
>>> Xiyue Deng <[email-masked]> 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.
>>>
>>> Would it make sense to plug OAuth2.el into auth-source to store the
>>> authentication token safely inside an existing credential storage?
>>>
>>> Various applications already do so when using the native credential
>>> storages such as Freedesktop.org or the macOS keyring.
>>
>> As I mentioned to Robert, I do have another addon to do exactly this,
>> though through an awkward advice.  Would be great if auth-source can
>> make use of oauth2.el and handle that more gracefully.  I'll file
>> another bug to explore options once this one is done.
>
> Care to post this advice? It's not an optimal solution but better than
> nothing in the interim.

It currently depends on this modified oauth2.el.  Once the patches are
accepted I'll post it in a separate bug.

-- 
Xiyue Deng