Forcing HTTPBasicAuth in fetch_token results in invalid_request from Google

[butlertron]

Using Flask_OAuth2_Login (for example):

  def login(self):
    sess = self.session()

    # Get token
    try:
      sess.fetch_token(
        self.token_url,
        code=request.args["code"],
        client_secret=self.client_secret,
      )

results in:

  File "/lib/python2.7/site-packages/flask_oauth2_login/base.py", line 56, in login
    client_secret=self.client_secret,
  File "/lib/python2.7/site-packages/requests_oauthlib/oauth2_session.py", line 232, in fetch_token
    self._client.parse_request_body_response(r.text, scope=self.scope)
  File "/lib/python2.7/site-packages/oauthlib/oauth2/rfc6749/clients/base.py", line 409, in parse_request_body_response
    self.token = parse_token_response(body, scope=scope)
  File "/lib/python2.7/site-packages/oauthlib/oauth2/rfc6749/parameters.py", line 376, in parse_token_response
    validate_token_parameters(params)
  File "/lib/python2.7/site-packages/oauthlib/oauth2/rfc6749/parameters.py", line 383, in validate_token_parameters
    raise_from_error(params.get('error'), params)
  File "/lib/python2.7/site-packages/oauthlib/oauth2/rfc6749/errors.py", line 271, in raise_from_error
    raise cls(**kwargs)

This is due to a change introduced in 0.6.0 in oauth2_session.py/fetch_token:

auth = auth or requests.auth.HTTPBasicAuth(username, password)

whereas previously auth was allowed to remain empty. Google responds with:

{
  "error" : "invalid_request"
}

and everything falls down from there. Commenting out the line allows the request to complete normally.

[Lukasa]

This sounds like we need a Google compliance fix. We unconditionally added this auth header because the OAuth2 spec mandates that servers support Basic Auth, as discussed in #206.

[butlertron]

For sure, I don't know enough about the spec to create a pull request, and I figured the change was made for a reason.

[karthik-rangarajan]

Doesn't need a compliance fix since the underlying issue was fixed with #212. Spent way too much time debugging it and was about to make a PR when I figured this out. Any chance you can release 0.6.1 with this fix so that others like me aren't blocked by this?

[dir01]

If someone else is struggling with this, downgrading to requests-oauthlib==0.5.0 also solves the problem

[regner]

Please can we get a new release with this fix! Will be downgrading to 0.5.0 for now but just spent WAY to much time trying to debug this.

I should note that pip installing 0.6.0 on Windows seems to give a different version than Linux. Which made this extra fun to debug.

[Lukasa]

@regner Unfortunately, the fix for this will only come when someone sets aside the time to write it. I may get around to it at some point but I'm stretched pretty thin.

[regner]

Sorry, thought this fixed it: https://github.com/requests/requests-oauthlib/pull/212/files

[Lukasa]

@regner It does not. That fixed one issue, but this specific issue results from having the Basic auth header present at all.

[karthik-rangarajan]

@Lukasa I can take a shot at fixing it with a compliance fix, I'll make a PR later today.

[jsfan]

RFC 6749 is very permissive when it comes to authentication. The wording is

Clients in possession of a client password MAY use the HTTP Basic
authentication scheme [...].

and

Including the client credentials in the request-body using the two
parameters is NOT RECOMMENDED and SHOULD be limited to clients unable
to directly utilize the HTTP Basic authentication scheme (or other
password-based HTTP authentication schemes).

Unfortunately, a lot of OAuth 2 implementations go with what the RFC does not recommend. So, really, both ways of of authentication need to be available despite the RFC considering authentication via the request body a rare edge case.

[Lukasa]

@jsfan Are you saying that some implementations don't support authentication using Basic auth at all?

This is where the protocol implementer in me gets mad. I don't understand the point of having an RFC if everyone will ignore it.

Regardless, does this mean we need a configuration option of some kind?

[karthik-rangarajan]

@Lukasa Google doesn't support authentication using Basic auth at all, I think.

[poswald]

You might want to test it again now that #227 is closed since it could also be that the username was being passed as if it was the client_id so the client lookup by google would have failed. Up until yesterday, this project was not doing what the spec says so google may have been rejecting it because of that.

[poswald]

But, looking at it again I guess that maybe isn't relevant in this grant type...

[jsfan]

@Lukasa: Until I saw the Bitbucket authentication, I didn't even know that Basic Auth is the RFC's recommendation. I have never tried to find out if providers who use authentication in the body will accept Basic Auth as well. However, most documentation and sample code I have seen across multiple providers did not mention Basic Auth as an option at all. So, it's probably a fair assumption that some would have ignored the RFC's recommendation altogether.

[malefice]

Pretty late into the scene, but I also encountered this problem with a different project (not Google) where I cannot authenticate because of the extra Basic Auth headers. I created PR #237 to address this issue.

[singingwolfboy]

0.6.0 is no longer the latest version of requests-oauthilb, and the last comment on this issue is two years old. I'm going to close this issue. If it's still a problem on the latest version of requests-oauthlib, please open a new GitHub issue and reference this one.