cURL / Mailing Lists / curl-library / Single Mail


Re: [PATCH] OAUTH 2.0 Bearer token support SMTP/IMAP (XOAUTH2)

From: Kyle L. Huff <>
Date: Sun, 25 Aug 2013 13:28:38 -0400

On Sun, Aug 25, 2013 at 10:58 AM, Steve Holme <> wrote:

>> > Do you know if OAUTH 2.0 is supported in POP3 as well?
>> POP3 might support OAUTH 2.0, but I have not found a provider
>> that has implemented it. I know that presently the google POP3
>> service does not support OAUTH 2.0.
> I couldn't find much on the subject myself, from a quick search, but I think
> I found a mail client / api that had implemented it and it should be pretty
> straight forward to implement it here as well.

I plan to focus on the HTTP Authorization XOAUTH2 mechanism in the
near future, I could attempt to address the POP3 implementation at
that time. I will have to do some digging to find a provider that I
can test it with.

> Mmmm... I don't know of a way of doing this from that function myself and it
> does worries me that --bearer needs to be specified before -u to avoid the
> user being prompted for the password :(
> Perhaps the call to checkpasswd() could be moved to after all the parameters
> have been got ??
> You also need to bear in mind that checkpasswd() doesn't just check for the
> password - it also looks for the optional login options via the ; separator
> which is currently used to specify the preferred authentication mechanism
> (in addition to in the URL). As such we should support "-bearer mybearer -u
> steve;AUTH=XOAUTH2" as a valid command line to curl. If bearer was passed
> into this function then it could be added to the check that then requests
> the password from the user.

Perhaps in addition to moving the call to checkpassword() to after the
parameter collection it might be intuitive to add a new type to
checkpasswd() - say, "XOAUTH2 Access Token" - to prompt for an omitted
bearer. This would handle cases where the auth mech was explicitly
defined as AUTH=XOAUTH2, but no bearer token was provided.

Below is an example of the behavior of a few examples with the
included patches. Hopefully this gives you a better context of the
current behavior.

command: curl --url "smtps://" -u --bearer ya29.AHES...xMbS
result: prompts for password; user can enter anything and OAUTH
proceeds normally

command: curl --url "smtps://" -u;AUTH=XOAUTH2 --bearer ya29.AHES...xMbS
result: prompts for password; auth LOGIN is attempted

command: curl --url
"smtps://;" --bearer
result: no prompt for password; OAUTH proceeds normally

> I'm pretty happy with the patches myself - although I did want to ask /
> point out the following before committing:
> * Is it necessary to obtain the length of user and bearer (ulen and blen) in
> Curl_sasl_create_xoauth2_message() in order to calculate the length that is
> passed to Curl_base64_encode() - could this be strlen(xoauth) or have I
> missed something there?

No, you are correct. After ditching the stack based buffer I
overlooked this. tunnel vision... This has been corrected in the
attached patch.

> * Setting outlen and outptr are not, strictly speaking, needed when
> returning failure

Changed. Both conventions were present in the same file, I erred on
the side of specificity.

> * The alignment of the parameters to the function are also 2 characters out
> in the .c file


Also, I removed the check for conn->bearer from the functions
imap_perform_authenticate and smtp_perform_authenticate, as I believe
this check lacks sanity. With that check If the bearer is absent the
result would is "No known authentication mechanisms supported!", which
I believe should result in code 334 "Authentication Failure". Any
check for the bearer should be done elsewhere (if at all).


Kyle L. Huff

List admin:

Received on 2013-08-25