fix: stop OAuth2Extractor from letting a non-Bearer header shadow access_token

[ultramcu]

Problem

OAuth2Extractor is documented as "looks in 'Authorization' header then 'access_token' argument for a token". In practice, a present but non-Bearer Authorization header silently shadows a valid access_token:

Authorization: Basic dXNlcjpwYXNzd29yZA==   +   ?access_token=<valid JWT>
  -> OAuth2Extractor returns "Basic dXNlcjpwYXNzd29yZA==" (the access_token is never read)

The cause is the composition:

var OAuth2Extractor = &MultiExtractor{
    AuthorizationHeaderExtractor, // returns ANY non-empty Authorization value
    ArgumentExtractor{"access_token"},
}

AuthorizationHeaderExtractor's stripBearerPrefixFromTokenString returns the header value unchanged when there is no "Bearer " prefix, and MultiExtractor stops at the first non-empty token, so the access_token fallback only runs when the Authorization header is entirely absent. A request that carries both HTTP Basic auth (e.g. a browser re-sending cached credentials, or a proxy) and a valid ?access_token=<jwt> therefore fails to authenticate, surfacing a confusing token is malformed: token contains an invalid number of segments error.

Fix

Use BearerExtractor{} as the first sub-extractor. It already returns ErrNoTokenInRequest for a non-Bearer header, so MultiExtractor correctly falls through to access_token:

var OAuth2Extractor = &MultiExtractor{
    BearerExtractor{},
    ArgumentExtractor{"access_token"},
}

Behavior change

A token placed directly in the Authorization header without the Bearer scheme prefix is no longer extracted by OAuth2Extractor (it previously was, as a side effect of the lenient strip). This matches RFC 6750, which mandates the Bearer scheme for OAuth2 access tokens. A real Bearer <token> header is unaffected, and AuthorizationHeaderExtractor itself is unchanged for anyone using it directly.

Tests

Adds TestOAuth2Extractor covering: Bearer header, Bearer precedence over access_token, access_token fallback with no header, and the regression cases — a non-Bearer header (Basic ..., Token ...) falling through to access_token, and a non-Bearer header with no access_token returning ErrNoTokenInRequest. The fallthrough cases fail before this change and pass after.

go test -race ./..., go vet ./... and gofmt are clean; no existing test changed.

[oxisto]

where is BearerExtractor defined?

[ultramcu]

BearerExtractor is the existing exported type in this package — request/extractor.go:84 (type BearerExtractor struct{}, with an ExtractToken method). I reused it here precisely because it returns ErrNoTokenInRequest when the Authorization header isn't Bearer …, so MultiExtractor falls through to the access_token form value instead of being shadowed by a non-Bearer header (e.g. Basic …). The previous code used stripBearerPrefixFromTokenString, which returns the header unchanged for a non-bearer value, which is what stopped the fallthrough.