nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] XOAUTH2 integration, and a few questions


From: David Levine
Subject: Re: [Nmh-workers] XOAUTH2 integration, and a few questions
Date: Tue, 28 Jun 2016 21:18:54 -0400

Ken wrote:

> I had a few questions; I guess Eric is probably the best person to
> answer them,

Right, but I'll take a stab at them in the hope that I can save him
the trouble.

> - From looking at the protocol document and the source code, it seems
>   that (using RFC 6749 termology) mhlogin gets an OAuth Authorization
>   Grant (involving the user's browser), and then uses it to get an
>   access token and a refresh token, and stores those in a credential
>   file (by default: oauth-gmail).  Is that correct?

Yes.  Multiple token sets can be stored in that file, to support different
logins, e.g., multiple Gmail accounts.

We should add an example to the mhlogin man page.

> Under what circumstances will the refresh token be invalidated?

I don't know, but isn't that up to the resource owner?  As in, why would
nmh care?

> - If the access token is old, the refresh token is used to get a new
>   one.  When you have an up-to-date access token, it's used to constrct
>   the SASL exchange for the XOAUTH2 mechanism.  Is that correct?

Yes.

> I really think it would be preferrable to just pass down the 'real'
> authservice flag and have post(8) (well, probably the SMTP code)
> construct the access token.  If there's a reason it's done the way it
> is now, I would like to understand it.

    All parameters configuring the service may be overridden by profile
    components, and even though only Gmail is supported out of the box, the
    user can define new services entirely in the profile.  Profile
    components are prefixed by oauth-service-, for example, oauth-gmail-
    credential-file which specifies where mhlogin should write credentials
    and where send should read them.

And post doesn't read the profile.  This also allows a postproc to do
things that send/post can't.

> I think it's almost ready to go; do other agree?

Definitely.  I've been using it, completely successfully, for a few months.
It's my favorite recent nmh addition.

BTW, I merged master to the xoauth branch in the hope that it would avoid
merge conflicts when merging the branch to master.  It won't, completely,
so let me know if you want me to do it.

David



reply via email to

[Prev in Thread] Current Thread [Next in Thread]