Extending auth-source and plstore for more XOAUTH2 scenarios

Extending auth-source and plstore for more XOAUTH2 scenarios

[Farblos]

Hi,

I've made some extensions to package auth-source and plstore to cover 
more XOAUTH2 scenarios.  My employer uses MS Office 365 with a device 
grant for the MUTT/Gnus/whatever outcasts, where you need additional URL 
parameters to refresh an access token.  Plus I store the access token 
*and* its expiry date in a plstore to avoid token refresh cycles as much 
as possible.

The changes comprise:

- A function `plstore-update' with signature similar to that of 
`plstore-put', but which merges new properties with existing properties.

- An auth-source backend `auth-source-plstore-xoauth2' that allows for 
an arbitrary function to be called to perform the actual token requests. 
  Plus auxiliary functions to do the dirty URL interfacing.  (I could 
deliver that part as a separate package on (M)ELPA, or wherever, BTW.)

Some more changes (not all of which I have implemented yet):

- Nullify the plstore data structure when `plstore-close' gets called to 
avoid clear-text credentials lingering around.

- Make plstores a bit more edit-friendly.  For example, keep the plstore 
non-secret and secret data between some pre-defined markers, but keep 
the rest of the text unchanged when reading and writing plstore data. 
That would allow for local variables at the end of the plstore.

- Provide auto-closing plstores, probably also configurable with local 
variables.

- Allow auth-source backends to specify credential expiry per backend. 
For the `auth-source-plstore-xoauth2' backend, for example, auth-source 
expiry and plstore expiry (if it gets implemented) and the access token 
expiry should be all synchronized to avoid funny results.

So much for the bigger picture.  What do you think?  Would you accept 
changes in that direction?

In parallel I'm trying to get the FSF copyright assignment done.

Thanks

Farblos

Re: Extending auth-source and plstore for more XOAUTH2 scenarios

[Thomas Fitzsimmons]

Hi Farblos,

Farblos <akfkqu.9df7rp@vodafonemail.de> writes:

> I've made some extensions to package auth-source and plstore to cover
> more XOAUTH2 scenarios.  My employer uses MS Office 365 with a device
> grant for the MUTT/Gnus/whatever outcasts, where you need additional
> URL parameters to refresh an access token.  Plus I store the access
> token *and* its expiry date in a plstore to avoid token refresh cycles
> as much as possible.

[...]

> So much for the bigger picture.  What do you think? 

It would indeed be nice to have in GNU ELPA a package that has
configuration logic for IMAP/SMTP/POP3 OAuth 2.0.

I currently use the https://github.com/harishkrupo/oauth2ms Python
script for IMAP and SMTP XOAUTH2.  Have you seen it?  It's got excellent
documentation and the script has been solid.  However, I would prefer to
eliminate the external Python script and have a pure Elisp solution.  It
sounds like that's what you'd like to contribute, in which case, great!

Also have a look at url-http-oauth, which I just released to GNU ELPA
this week.  It provides OAuth 2.0 support for HTTP services, and uses
the auth-source netrc backend.  See if you may be able to make use of
parts of it.  I started with netrc support because that's what I use,
and because authinfo.gpg can be GPG-encrypted.  There's not much
netrc-specific though, so it might be worth trying with the plstore
backend if that's what you prefer.

Thomas

Re: Extending auth-source and plstore for more XOAUTH2 scenarios

[Björn Bidar]

Hello,

I'm not sure how exactly that relates to this issue. But sasl.el that
was taken from FLIM, FLIM supports XOAUTH2.

FLIM is used in Wanderlust for this kind of purpose I think it.
It would make sense to import sasl-xoauth2 and sasl-scram for
completeness into Emacs.

I worked with signon-plugin-oauth2 in the past to implement the
Microsoft OAuth2 Workflow.
I have a few pointers regarding that:
- Microsoft's way of doing OAuth2 with a clientid rather than a client
  secret is ironically much friendlier to FOSS programs such as
  Emacs. Emacs can simply write the clientid inside the sources after
  registering an AppID at Microsoft. An example where this was already
  done is KDE PIM/Akonadi.
  No further intervention is needed on the user side besides pointing
  the user to the webpage to give Emacs the permission to access all the
  requested areas.
- I think it would make sense to see how Wanderlust implemented OAuth2
  for Microsoft.
- Take pointers from other existing implementations that try to add Microsoft
  Oauth to Gnus.

Br,

Björn Bidar