"Bearer was not authenticated" message when the token format is invalid in the header

[amura]

I spent a lot of time trying to investigate the message I was seeing in the logs about bearer not authenticated. It as correctly manifested on the client side as a 401 unauthorized exception, however with debug logs enabled on the server, I would have expected more detailed information about what was going wrong. All that is logged when a bearer is presented in the wrong format in the header is a sequence of debug messages about the bearer not authenticated, followed by authorization failed, and bearer was challenged.

You can easily reproduce this with a simple spa front end where you send back the token with the token presented in the format Bearer: ey....., or yet still, just the token without the Bearer key work in front. One could argue that it's correct in this instance just to report this scenario as an authorization failure, however whilst developing and with debug logs turned on, I would expect a bit more information to help with resolving the underlying issue.

[blowdart]

If you're not sending the correct header format then the JWT middleware isn't going to pick up the token, in fact no authentication service is going to handle it, so there are notdetailed error messages to give, because nothing is doing anything with it. We can't say "Oh wrong format", because we don't know what the right formats are, given all the auth services stand alone, we just know nothing processed it. The lack of processing messages is probably the only clue here.

[amura]

After adding the jwt middleware, I would expect this to kick in and act on the token, which if missing from the header surely this omission should then be reported, especially with all the debug logging enabled. Under RFC 6750, an error message should be returned when a token is malformed, you will probably argue this is different, but I suggested that presenting a valid token whilst omitting the "Bearer", surely that would be a malformed token, and that should be reported as such.

I am also comparing the equivalent experience I had using go, and this invalid token was reported immediately in debug mode.

[blowdart]

You know I'm going to disagree :) As soon as you leave out the Bearer part of the authorization header it's not an invalid token, because it's not a token at all, something else could handle it.

Consider

Authorization: Bearer madeUpNonsenseBearer

If there was a bearer authorization service, then it would look at the credential value and decide if it's invalid or not, but with multiple bearer services another service might decide that "madeUpNonsenseBearer" is actuallty valid, so detailed errors from one bearer service might be entirely wrong.

Now, you want

Authorization: madeUpNonsenseBearer

to error, which makes no sense, because now there's just a type, there's nothing to handle the type, and with nothing to handle the type there's nothing to give detailed errors, because nothing is looking at it, because you've completely missed the type header. The JWT middleware only kicks in when it sees a type of Bearer. Without a type it is skipped entirely.