Ken Hornstein <kenh(_at_)pobox(_dot_)com> 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.
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers