Appauth-android: Bearer token constant does not match OAuth 2.0 spec

[shalfknight]

Hi folks,

I just used your defined constant TOKEN_TYPE_BEARER = "bearer from AuthorizationResponse.java (same is also defined in TokenResponse.java) for setting my access token in my HTP header.

request
                                    .newBuilder()
                                    .addHeader(HttpHeaders.AUTHORIZATION,
                                            "${AuthorizationResponse.TOKEN_TYPE_BEARER} $accessToken")
                                    .build()

The problem is that "bearer" does not match the spec of https://tools.ietf.org/html/rfc6749#section-7.1 where the header value prefix bearer is defined with a capital letter "Bearer".

When updating the spring security dependency in my service implementation, the requests were rejected because the HTTP header value does not match he spec

I don't know if you are using this constants in a different context and maybe they are actually not supposed to be used for setting HTTP header values.

If they are actually supposed to be reused, maybe some other uses can start struggling with this pitfall as well.

Kind regards
Stefan

[panva]

The authorization header scheme is to be matched case-insensitive, so the problem lies with the Authorization or Resource Server accepting the Bearer token.

[shalfknight]

It is the OAuth 2.0's spec definition using a capitalized letter at the beginning.

https://tools.ietf.org/html/rfc6749#section-7.1

`For example, the "bearer" token type defined in [RFC6750] is utilized
by simply including the access token string in the request: https://tools.ietf.org/html/rfc6749#section-7.1

 GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer mF_9.B5f-4.1JqM`

Our resource server is just following this standard (enforced by Spring security)

Thereby I don't understand why the problem should lie on the resource server side by applying the OAuth 2.0 spec.

[panva]

Because RFC6750 (bearer token usage) makes use of the Authorization header defined in RFC2617 which defines the scheme as case insensitive. Therefore spring security should match the scheme accordingly.

RFC examples are also not normative.

[andifalk]

Because RFC6750 (bearer token usage) makes use of the Authorization header defined in RFC2617 which defines the scheme as case insensitive. Therefore spring security should match the scheme accordingly.

RFC examples are also not normative.

But RFC2617 is obsoleted by https://tools.ietf.org/html/rfc7617#section-1 and RFC7617 also states that "Note that both scheme and parameter names are matched case-insensitively.". Also RFC6750 states that "Note that, as with Basic, it does not conform to the generic syntax defined in Section 1.2 of [RFC2617] ".
You may also follow the current discussion in a corresponding issue in Spring Security
https://github.com/spring-projects/spring-security/issues/6228

So currently with all the different specs it is quite unclear what this means for case-sensitity/case-insensitivity for bearer token header :-(

[panva]

Note that both scheme and parameter names are matched case-insensitively.

Yeah. So it is pretty clear

[panva]

Nevertheless for the sake of interoperability which is the only thing that matters when there are no security implications

• clients ought to be sending Bearer
• resource servers should accept case insensitive matched schemes

[iainmcgin]

Changed to "Bearer" in https://github.com/openid/AppAuth-Android/commit/a7730439c0a8ac0485d59ea894a9bf04e8578d14