Hard-coded Token auth-scheme in WWW-Authenticate challenge

[jmm]

This package is hard-coded to respond to requests that lack valid authentication credentials with a hard-coded scheme value of Token, even though by default it's configured to accept Authorization header values with no scheme (which I think is questionable) or with scheme Bearer, and even if a scheme is explicitly configured via options.tokenType (which may not be the clearest name -- perhaps something like httpAuthScheme would be clearer).

/lib/index.js has multiple hard-coded Token string literals for the scheme argument to Boom.unauthorized(), which is propagated to the WWW-Authenticate header.

The "WWW-Authenticate" header field indicates the authentication scheme(s) and parameters applicable to the target resource.

So shouldn't the tokenType value be used to populate the scheme sent in the response headers? Example:

- Boom.unauthorized(null, 'Token')
+ Boom.unauthorized(null, options.tokenType)

[nelsonic]

@jmm agree that naming tokenType could be misleading, and httpAuthScheme is a good label, however we haven't had a complaint/query about it (until now...) ... would it be enough to update all instances of Boom.unauthorized(null, 'Token') to Boom.unauthorized(null, options.tokenType) as you suggest?

[jmm]

Thanks!

@nelsonic Yeah, updating it so the tokenType is reflected in the response headers is the key thing. If this was new or you wanted to clarify it in a future major I would suggest maybe using a different name. I guess it also depends how you intend that option to be used though -- if it only relates to values of the Authorization header, then I think something like httpAuthScheme would be more apt. But like I mentioned in #179, the header name is configurable and I don't know if tokenType is intended to have any meaning when using a header other than Authorization

[nelsonic]

Agreed. 👍