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

[Eric Gillespie]

Ken Hornstein <address@hidden> writes:

> - 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?  Under what
>   circumstances will the refresh token be invalidated?

Yes.  Refresh tokens, unlike access tokens, are long-lived.
However, either may stop working at any time, for any unspecified
reasons.  Some example reasons:

- password change (typically forces fresh auth on all "devices")

- access revoked (https://security.google.com/settings/security/permissions)

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

> Ah, I see.  THAT works because send(1) reads the profile for you and
> passes down the "credentials" entry via the -credentials switch.
> Hm.  Could something like that work for post?  It would require some
> rejiggering (that I would be willing to do), but instead of passing down
> the access token on the post command line, we could do:
> 
> -oauth-cred-file      <cred file>
> -oauth-client-id      client_id
> -oauth-client-secret  client_secret
> 
> ... and so on.
> 
> A postproc could get all of those entries via mhparam.  That seems like it
> "fits" a bit better.  Thoughts?  Like I said, I'd be willing to do this
> work since I'm the one asking for it.

All sounds fine to me.  Lyndon's concern about ps is severe.
The xoauth token passed to post is usable all on its own, giving
a malicious user up to an hour to read the victim's mail.

Thanks.