Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for OAUTHBEARER as per RFC 7628 #2487

Closed
PMox opened this issue Apr 12, 2018 · 3 comments
Closed

Support for OAUTHBEARER as per RFC 7628 #2487

PMox opened this issue Apr 12, 2018 · 3 comments

Comments

@PMox
Copy link

PMox commented Apr 12, 2018

I did this

curl "imaps://imap.gmail.com:993" --user "XXX" --oauth2-bearer "ya29.XXX"

CURL is sending this:

A002 AUTHENTICATE OAUTHBEARER __REDACTED__

GMail IMAP is answering with:

A002 BAD Invalid SASL argument. i29mb53490361edj

Decoding the token:

pbpaste | base64 -D | python2 -c 'import sys; a=sys.stdin.read(); print repr(a)'

Generate this:

user=user@domain.com\x01host=imap.gmail.com\x01port=993\x01auth=Bearer ya29.XXX\x01\x01

As per RFC 7628 I think this is not correct, and I would expect the token to be formatted in this way:

n,a=user@domain.com,\x01host=imap.gmail.com\x01port=993\x01auth=Bearer ya29.XXX\x01\x01

If I provide this to GMail, it works.

The syntax with simply user=,auth= is suitable for method XOAUTH2 instead.

I tried to generate the different syntax and then try directly with OpenSSL to confirm what works and what not.

I expected the following

Unless there are other RFC outdating RFC 7628 (which I didn't found), I would expect cURL to do one of the following:

  1. use XOAUTH2 with current format
  2. or OAUTHBEARER with the syntax documented in RFC 7628
  3. or anyway allow to force a given SAML auth mechanism

Workaround (partial) is to use a request in the form:

-X "AUTHENTICATE XOAUTH2 __REDACTED__"
-X "AUTHENTICATE OAUTHBEARER __REDACTED__"

but it seems cURL supports only one request at a time, so this would will not play well with a folder listing operation.

curl/libcurl version

curl 7.54.0 (x86_64-apple-darwin17.0) libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz HTTP2 UnixSockets HTTPS-proxy

curl 7.59.0 (x86_64-apple-darwin17.3.0) libcurl/7.59.0 SecureTransport zlib/1.2.11
Release-Date: 2018-03-14
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile NTLM NTLM_WB SSL libz UnixSockets

operating system

Mac OS 10.13.3

@PMox
Copy link
Author

PMox commented Apr 13, 2018

I would say all the logic is in Curl_auth_create_oauth_bearer_message and this method is used to handle both the XOAUTH2 and the OAUTHBEARER case, but this seems logically wrong because it must handle two difference scenarios and he has no way to distinguish.

The code is computing the mech before the call to Curl_auth_create_oauth_bearer_message, but it's never provided to the method, which has currently no way to decide how to proceed.

The method is called 4 times.

This one must use the n,a= format:

curl/lib/curl_sasl.c

Lines 341 to 347 in de97b5f

mech = SASL_MECH_STRING_OAUTHBEARER;
state1 = SASL_OAUTH2;
state2 = SASL_OAUTH2_RESP;
sasl->authused = SASL_MECH_OAUTHBEARER;
if(force_ir || data->set.sasl_ir)
result = Curl_auth_create_oauth_bearer_message(data, conn->user,

This one must use the n,a= format:

curl/lib/curl_sasl.c

Lines 554 to 555 in de97b5f

if(sasl->authused == SASL_MECH_OAUTHBEARER) {
result = Curl_auth_create_oauth_bearer_message(data, conn->user,

This one must use the user= format

curl/lib/curl_sasl.c

Lines 354 to 359 in de97b5f

mech = SASL_MECH_STRING_XOAUTH2;
state1 = SASL_OAUTH2;
sasl->authused = SASL_MECH_XOAUTH2;
if(force_ir || data->set.sasl_ir)
result = Curl_auth_create_oauth_bearer_message(data, conn->user,

I'm not sure about this one:

result = Curl_auth_create_oauth_bearer_message(data, conn->user,

@KerryL
Copy link

KerryL commented Sep 8, 2018

It looks like this may be a very simple fix. I modified a single line in Curl_auth_create_oauth_bearer_message (in vauth/oauth2.c) to use the "n,a=" format.

In the four places where Curl_auth_create_oauth_bearer_message are called, the two that require the "user=" format send a NULL hostname and zero port. The logic to check for NULL hostname and zero port was already included in, but the same format was used for all cases.

I can't say that I've tested this thoroughly, but it does work when sending via gmail with AUTH OAUTHBEARER.

I'll create a pull request containing the change.

EDIT: eh, looks like pull requests aren't used much here. So how about a patch instead?

diff --git a/lib/vauth/oauth2.c b/lib/vauth/oauth2.c
index 6288f89..a8b35c9 100644
--- a/lib/vauth/oauth2.c
+++ b/lib/vauth/oauth2.c
@@ -72,7 +72,7 @@ CURLcode Curl_auth_create_oauth_bearer_message(struct Curl_easy *data,
     oauth = aprintf("user=%s\1host=%s\1auth=Bearer %s\1\1", user, host,
                     bearer);
   else
-    oauth = aprintf("user=%s\1host=%s\1port=%ld\1auth=Bearer %s\1\1", user,
+    oauth = aprintf("n,a=%s,\1host=%s\1port=%ld\1auth=Bearer %s\1\1", user,
                     host, port, bearer);
    if(!oauth)
      return CURLE_OUT_OF_MEMORY;

merty added a commit to merty/curl that referenced this issue Dec 16, 2018
OAUTHBEARER tokens were incorrectly generated in a format similar to
XOAUTH2 tokens. These changes make OAUTHBEARER tokens conform to the
RFC7628.

Fixes: curl#2487
Reported-by: Paolo Mossino
@stale
Copy link

stale bot commented Mar 7, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Mar 7, 2019
merty added a commit to merty/curl that referenced this issue Mar 12, 2019
OAUTHBEARER tokens were incorrectly generated in a format similar to
XOAUTH2 tokens. These changes make OAUTHBEARER tokens conform to the
RFC7628.

Fixes: curl#2487
Reported-by: Paolo Mossino
merty added a commit to merty/curl that referenced this issue Mar 12, 2019
OAUTHBEARER tokens were incorrectly generated in a format similar to
XOAUTH2 tokens. These changes make OAUTHBEARER tokens conform to the
RFC7628.

Fixes: curl#2487
Reported-by: Paolo Mossino
merty added a commit to merty/curl that referenced this issue Mar 18, 2019
OAUTHBEARER tokens were incorrectly generated in a format similar to
XOAUTH2 tokens. These changes make OAUTHBEARER tokens conform to the
RFC7628.

Fixes: curl#2487
Reported-by: Paolo Mossino
@stale stale bot closed this as completed Mar 21, 2019
merty added a commit to merty/curl that referenced this issue Mar 26, 2019
OAUTHBEARER tokens were incorrectly generated in a format similar to
XOAUTH2 tokens. These changes make OAUTHBEARER tokens conform to the
RFC7628.

Fixes: curl#2487
Reported-by: Paolo Mossino
merty added a commit to merty/curl that referenced this issue Mar 26, 2019
OAUTHBEARER tokens were incorrectly generated in a format similar to
XOAUTH2 tokens. These changes make OAUTHBEARER tokens conform to the
RFC7628.

Fixes: curl#2487
Reported-by: Paolo Mossino
jay pushed a commit that referenced this issue Apr 2, 2019
OAUTHBEARER tokens were incorrectly generated in a format similar to
XOAUTH2 tokens. These changes make OAUTHBEARER tokens conform to the
RFC7628.

Fixes: #2487
Reported-by: Paolo Mossino

Closes #3377
@lock lock bot locked as resolved and limited conversation to collaborators Jun 19, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

Successfully merging a pull request may close this issue.

3 participants