`Authorization` header without scheme

This package encourages use of Authorization header values without a scheme token. Are you sure that’s valid HTTP? I’ve looked through RFC 2617 and RFC 7235 and it seems invalid to me. For example, here is the grammar showing scheme (auth-scheme) as a required part of the Authorization value. The prose and grammar elsewhere in the spec and in RFC 2617 lead me to the same conclusion.

https://github.com/dwyl/hapi-auth-jwt2/pull/105#issuecomment-140690731 included the following content (formatted as a quote):

The wording in RFC 2617 is “Should” not “Must” which means its a suggestion not a requirement.

Was that a quote or the author’s own words? In any case, can you please provide a specific reference to the section and content it’s based on?

[jmm]

@nelsonic Sounds good. I forgot to mention an important wrinkle: the header name is configurable. So I think that makes sense when the header is Authorization, but when using a custom header I guess anything goes and it’s fair game to set the value to just the bearer token.

Authorization: Bearer abcSomeTokenXyz
MyAuthorization: abcSomeTokenXyz

It’d probably be a good idea to link from the headerKey option docs to the RFC 7235 comments on caching (unfortunately they didn’t number the items in that section; it’s the last list item):

The credentials carried in an Authorization header field are specific to the user agent and, therefore, have the same effect on HTTP caches as the “private” Cache-Control response directive (Section 5.2.2.6 of [RFC7234]), within the scope of the request in which they appear.

Therefore, new authentication schemes that choose not to carry credentials in the Authorization header field (e.g., using a newly defined header field) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives (e.g., “no-store”, Section 5.2.1.5 of [RFC7234]) or response directives (e.g., “private”).

[jmm]

@nelsonic Thanks for the reply. I actually misstated the problem a little bit (but the upshot here is the same). I said:

This package encourages use of Authorization header values without a scheme token.

It appears to me that the HTTP grammar for Authorization permits a value (credentials) that consists only of a scheme (auth-scheme). (I don’t actually understand why that is.) So when this plugin accepts a header like…

Authorization: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpZCI6MSwibmFtZSI6IkFudGhvbnkgVmFsaWQgVXNlciIsImlhdCI6MTQyNTQ3MzUzNX0.KA68l60mjiC8EXaC2odnjFwdIDxE__iDu5RwLdN1F2A

…it seems to me that it’s using the scheme component as the token value. To illustrate, imagine that instead of the raw header value you had an API for retrieving the parsed components of HTTP header values, with an authorization interface with authScheme and token accessors. It seems to me that what this plugin is doing is equivalent to:

token = authorization.authScheme;
// authorization.token === undefined;

It looks like the Bearer scheme is proposed in RFC 6750. And I guess IANA runs a registry for HTTP auth schemes that includes it. From my reading of RFC 6750 (2.1) the Bearer scheme is required:

When sending the access token in the “Authorization” request header field defined by HTTP/1.1 [RFC2617], the client uses the “Bearer” authentication scheme to transmit the access token.

And from my reading of RFC 7235 (or 2617) it doesn’t seem valid to “omit” the scheme by interpreting the first token (component) of the header value as the bearer token instead of as the scheme.

Does it work anyway, yes (at least in this context), but it doesn’t seem like a great idea to me to intentionally violate the protocol.

I think it’s in 3.2.2 but after a quick glance I can’t find it

I don’t think that’d be the section in any case because Section 3.2.2 of RFC 2617 relates to the Digest auth scheme whereas RFC 6750 (Bearer scheme) says:

The syntax of the “Authorization” header field for this scheme follows the usage of the Basic scheme defined in section 2 of [RFC2617].

---

did I dream it? or was it in a different RFC?

Well, I think either of those is entirely possible 😃 It could be you saw that in some earlier version of one of these RFCs or another document. (I was just looking at a situation where something about clients sending the Origin header changed from MUST to SHOULD [or vice versa] in a later version of the spec due to web compat considerations that came to light.) I also think it’s not too hard to get turned around while going through these specs (individually and even more so when going through several). I don’t rule out that it’s happening to me right now 😃