Indeed the behavior as currently implemented in go-oauth2 could break the OAuth 2.0 specification. For example, the Amazon Cloud Drive API returns a "bearer" token type but expects a "Bearer" scheme in the authorization headers – valid according to the specs, but not good friends with go-oauth2 (which reuses token type verbatim for Authorization header).

A workaround without having to change the go-oauth2 source code is to implement a transport wrapper for the HTTP client, which rewrites authorization headers with the correct "Bearer" capitalization in Authorization headers (example and usage). While it does not fix the underlying problem, at least it allows stock go-oauth2 to be used.

I ran into similar issues and documented a solution at:
http://sgeb.io/articles/fix-go-oauth2-case-sensitive-bearer-auth-headers/

(also applies to #117)

Indeed the behavior as currently implemented in go-oauth2 could break the OAuth 2.0 specification.

The spec says token_type is a parameter and returned by the server after one of the token retrieving flows. The returned access token is only valid with the returned access type. Amazon is failing to implement the spec correctly by rejecting the type they have assigned to the token.

Thanks for the clarification. My understanding is based on the following:

In RFC 6749 "The OAuth 2.0 Authorization Framework", section 5.1

   token_type
         REQUIRED.  The type of the token issued as described in
         Section 7.1.  Value is case insensitive.

(notice the "case insensitive")

and in RFC 6750 "The OAuth 2.0 Authorization Framework: Bearer Token Usage", section 2.1

   The syntax for Bearer credentials is as follows:

     b64token    = 1*( ALPHA / DIGIT /
                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
     credentials = "Bearer" 1*SP b64token

(notice the uppercase "Bearer" scheme as part of the syntax spec).

From that I inferred the behavior of the Amazon Cloud Drive API complies with the specs, whereas go-oauth2 doesn't. But I do see your point. In any case the workaround mentioned earlier fixes the issue for me.

You are referring to a sample that illustrates what the header should look like for token type "Bearer". The generic syntax is explained at https://tools.ietf.org/html/rfc2617#section-1.2, and it labels the entire token string as case insensitive. Amazon's implementation doesn't fulfill this requirement.

@rakyll, what is the harm in us mapping any spelling of "bearer" to "Bearer"? If it fixes Amazon for users and doesn't break anything else, why not do it?

If it's critical, let's patch it. From the report, I got an impression that it only affects the Amazon Cloud Drive API users.

@rakyll, I subscribed to this issue as I'm seeing the same issue trying to consume the Asana API.

It's probably worth noting that Go's func (*http.Request) BasicAuth will itself bark on a value different from "Basic". I imagine this is the correct behavior, so presumably RFC 6750's section 2.1 can override RFC 2617's section 1.2 too.

Section 2.1 talks about this:

The syntax of the "Authorization" header field for this scheme follows the usage of the Basic scheme defined in Section 2 of [RFC2617]. Note that, as with Basic, it does not conform to the generic syntax defined in Section 1.2 of [RFC2617] but is compatible with the general authentication framework being developed for HTTP 1.1 [HTTP-AUTH], although it does not follow the preferred practice outlined therein in order to reflect existing deployments.

A contributor mailed https://go-review.googlesource.com/#/c/9852/.