[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: oauth2 support for Emacs email clients
From: |
Roland Winkler |
Subject: |
Re: oauth2 support for Emacs email clients |
Date: |
Sun, 08 Aug 2021 01:01:25 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
> > Now, using oauth2.el from GNU Elpa, I have got the basics
> > (authentication and authorization) working. This required some ugly
> > configuration within MS Azure. But I am still some distance away
> > from a smooth workflow, say, using Gnus.
>
> Can you tell us more details of
> (1) what you did to make this work, and
My starting point was oauth2.el in GNU elpa. Its main entry point is
oauth2-auth that requires several arguments
auth-url: URL for authentication
token-url: URL for requesting authorization
client-id
client-secret
redirect-uri: I got these from MS Azure by registering my "personnal app"
for communicating with Office365
> (2) what problems remain?
- The first problem has been documentation: both the Office365
machinery and oauth2.el assume that users know what they need to
do. I spent a good amount of time trying to figure out
- how the OAuth2 protocol works in general
- how the OAuth2 protocal relates to the particalur problem I
needed to address
- what functionality is provided by oauth2.el (it "implements the
OAuth 2.0 draft")
- how the general functionality provided by oauth2.el relates to
the particalur problem I needed to address
- what remaining steps were not (yet) implemented in relevant
emacs packages (imap and smtpmail)
- Others in this thread have mentioned davmail. This is a project
(published under GPL 2) that works as a local proxy server that
allows IMAP and SMTP clients to connect to Office365. So its main
purpose of existence are essentially the issues we are discussing
here. I have tried davmail and it seems to work.
I am mentioning it here because some discussions on its mailing list
gave me the impression that the entire topic is a hairy one which does
not permit a "one size fits all" solutions because, say, institutions
that use Office365 (i.e., institutions like the one I am working for
and that's forcing me to go through this pain), they have some freedom
to configure what OAuth2 means for their users (say: multi-factor
authentication), and they can also configure to what extent their
users can configure MS Azure as mentioned above.
So whatever I am writing here may be more or less irrelvant for
others, even if they likewise have to use Office365 (not to
mention Gmail).
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.
- It is my understanding of the internals of its code that oauth2.el
effectively delegates authentication to a browser that receives
the authentication token as a redirect uri. The last line of code
in oauth2-request-authorization is:
(read-string "Enter the code your browser displayed: "))
This step is awkward, even if it is only rarely needed.
> > More importantly, email clients need to regularly refresh the oauth2
> > access token. I believe Emacs is not yet suited for this.
>
> Can you tell us any more about what "regularly" concretely means?
> For instance, is this based on elapsed time? Actions carried out?
> It doesn't sound like something that will be difficult.
The OAuth2 protocol uses an access token and a refresh token. The
access token is used to access the server, but it has a shorter
lifetime. When the access token has expired, it can be refreshed
during a running session. Others reported in this thread that
oauth2.el supports this (for them), so I stand corrected.
>From the code base of oauth2.el I haven't been able to figure out
what happens when the refresh tokens expires. With my institution,
this happens after 30 days. So this may be a less pressing issue.
Still it is probably good (and not too difficult) to handle this
gracefully.
Also, I have not yet been able to figure out what happens when a new
emacs session is started. oauth2.el uses plstore. Does this work
across multiple emacs sessions, or is it then necessary to go again
through the (more tedious) multi-factor authentication? Depending
on a user's work flow with emacs and also depending on what
authentication means for this user, that may be an issue or not.
Maybe others can comment here.
And yes, I believe that earlier this week both imap.el and
smtpmail.el have been updated in trunk to support oauth2. It may
make sense to promote oauth2.el from GNU Elpa to emacs core.
- Re: oauth2 support for Emacs email clients, (continued)
- Re: oauth2 support for Emacs email clients, Eric S Fraga, 2021/08/04
- Re: oauth2 support for Emacs email clients, Thomas Fitzsimmons, 2021/08/04
- Re: oauth2 support for Emacs email clients, Tim Cross, 2021/08/04
- Re: oauth2 support for Emacs email clients, Thomas Fitzsimmons, 2021/08/04
- Re: oauth2 support for Emacs email clients, Ulrich Mueller, 2021/08/05
- Re: oauth2 support for Emacs email clients, Richard Stallman, 2021/08/07
- Re: oauth2 support for Emacs email clients, Eric S Fraga, 2021/08/09
- Re: oauth2 support for Emacs email clients, Richard Stallman, 2021/08/11
- Re: oauth2 support for Emacs email clients, Roland Winkler, 2021/08/12
Re: oauth2 support for Emacs email clients, Richard Stallman, 2021/08/03
- Re: oauth2 support for Emacs email clients,
Roland Winkler <=
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, 2021/08/08
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