adding OAuth

[Ken Hornstein]

>	I relay my mail through gmail.  sendmail uses cyrus sasl to
>authenticate.  gmail uses OAuth authentication.  If I could add OAuth
>to cyrus I could disable gmail requiring that I 'allow less secure
>apps'.  I think the authentication I use for my own messages is good
>enough; I worry about the vulnerability to which 'allow less secure
>apps' exposes my account from attack by others.  

So, I'm one of the people who work on nmh (the successor to good old
MH, and yes, it's still alive and kicking!), and our latest release
supports OAuth for POP and SMTP.  I didn't write the original OAuth
code, but I did do some of the integration work when we refactored our
networking code into a generic layer (nmh also supports Cyrus-SASL for
those protocols).  So I feel I can speak with some reasonable knowledge
on this topic.  But forgive me if I get some details wrong; it's been
a little bit since I looked at this, and a lot of the documentation is
very web-focused, so figuring out the bits that you need is a bit rough.

Adding OAuth support to Cyrus-SASL would be ... a large pain in the ass.
For the following reasons:

- The people who developed the XOAUTH2 SASL mechanism made some ... well,
  I would politely call them "non-optimal design choices".  Specifically,
  if there is a failure in the SASL protocol message exchange you have to
  be prepared to deal with that because you will get back an encoded JSON
  error message, and it wasn't all that clear to me you could do that in
  a generic SASL application because of the message flow (I'd have to look
  at the details again for this one, so if you are interested in more
  detail here let know).  The OAuth2 code in nmh is special-cased; if you
  request the XOAUTH2 mechanism it goes down the XOAUTH2 protocol exchange
  and doesn't call the Cyrus SASL library.

- To support OAuth2 for Gmail requires your project to register with Google
  and obtain a specific key (well, what you get is a "client_id" and a
  "client_secret"); we did that for nmh.  It's not clear to me how that
  would work for Cyrus-SASL; would every application have to register an
  API key?  That means you'd be limited to applications that did that (and
  there would have to be an API extension to pass that key into the library).
  Or would the Cyrus-SASL library get it's own key?  Tht might be better,
  but that presents it's own problems.

- You need some external utility to do the initial authorization; what
  we have is a new program (mhlogin) which will give you a URL to load
  into your web browser; you then login to Gmail, grant nmh access to
  your email, and you get an authorization code which you THEN use to
  get a "grant" in OAuth2 termology, and you need to keep that grant
  around to get a new bearer token (the bearer token is used to generate
  what actually gets sent during the XOAUTH2 SASL exchange).  This gets
  back to a problem I alluded to above; you are granting access to your
  email for specific applications, but if you got a client key for the
  Cyrus-SASL library then you'd be granting access to all applications
  that used the Cyrus-SASL library.  This may or may not be what you want
  (this wouldn't mean every Cyrus-SASL application could instantly
  read your email; you'd still need to get the grant into the application).

- The actual implementation requires you to parse JSON and speak HTTP
  to get a bearer token.  If you are doing a lot of requests you probably
  want to cache the bearer token (it has a limited lifetime); you use the
  grant you saved above to get a fresh bearer token.

Now, none of this is IMPOSSIBLE; I mean, we did it in nmh.  But it's a
lot more heavyweight than you might think.  I realize this is similar
in general scope to how Kerberos works, in that you need an extra
utility to get the Kerberos TGT, you have to talk to other servers to
get the actual tokens you send over the wire, the tokens have a limited
lifetime, etc etc.  But the key difference here is the GSSAPI library
and Kerberos utilities take care of all that for you; all you need to
do as an application programmer is make GSSAPI calls and you get the
necessary info back.  There is not, AFAIK, a comparable library in C
that is designed for this work; everything I've seen was web-focused and
really, I don't think we would have been able to do it if wasn't for the
main developer of the code who happens to work at Google.  So ... given
the current state of the art if you wanted to add that to Cyrus-SASL
you're going to have to write all of that code yourself.

There were objections to special-casing support for XOAUTH2 when the code
was first submitted; I agreed with them at first, but when I dug into it
a bit more I realized what was required and I knew it was not very likely
that OAuth2 would make it into Cyrus-SASL anytime soon.

>	gmail put both messages from this mailing list in my spam
>folder.

I think this is not a Cyrus-SASL issue?

--Ken