HTTPBearer security scheme is returning 403 instead or 401

[Kludex]

Discussed in #9130

^{Originally posted by aaaaahaaaaa September 8, 2020}
HTTPBearer security scheme enabled as a dependency is returning a 403 when a request is unauthenticated because of a missing or a malformed authorization header. In those scenarios, a 401 should be returned instead.

Related PRs

• Fix exception status codes in security http schemes #2120
• Changing OAUTH2/OIDC dependencies response status code when Authorization header missing #5310
• Fix OIDC response code when authorization header is missing #5332
• fix: give correct unauthorized response on OpenID Connect Auth #9312

[ezeparziale]

I use the auto_error=False and control the correct http error code manually.

[ordinary-jamie]

Hey @Kludex, what do you think about raising a HTTP 400 BAD REQUEST for cases where the authentication scheme is not correctly 'bearer'?

From RFC 6750 Section 3.1:

invalid_request
         The request is missing a required parameter, includes an
         unsupported parameter or parameter value, repeats the same
         parameter, uses more than one method for including an access
         token, or is otherwise malformed.  The resource server SHOULD
         respond with the HTTP 400 (Bad Request) status code.

invalid_token
         The access token provided is expired, revoked, malformed, or
         invalid for other reasons.  The resource SHOULD respond with
         the HTTP 401 (Unauthorized) status code.  The client MAY
         request a new access token and retry the protected resource
         request.

My reading of this text is that:

• when the server understands the request (i.e. 'bearer' scheme is correct) but the token itself is malformed we should return a 401
• when the server does not understand the request (i.e. 'bearer' scheme is wrong), then we should return a 400

[Kludex]

Can you show me the diff you are talking about?

[ordinary-jamie]

fastapi/security/http.py L#125

EDIT: Wrong line sorry

[Kludex]

You want 400 instead of 403? That's why I asked the diff, not the lines in the code source. 👀

[ordinary-jamie]

Sorry, my misunderstanding. At any rate, I don't think it is necessary after reading section 3 again I realised they offered an example for this scenario.

tldr; 401 seems like the appropriate error code 👍

 If the request lacks any authentication information (e.g., the client
   was unaware that authentication is necessary or attempted using an
   unsupported authentication method), the resource server SHOULD NOT
   include an error code or other error information.

   For example:

     HTTP/1.1 401 Unauthorized
     WWW-Authenticate: Bearer realm="example"

[bootrecords]

This not only affects the HTTPBearer, but a lot of other classes in the security scope also return 403 in "Not authenticated" cases where they should return 401 instead, such as the OAuth2 class (though strangely enough not the subclasses OAuth2PasswordBearer and OAuth2AuthorizationCodeBearer), the HTTPBase class and its sublasses (except for HTTPBasic for some reason), all classes in api_key.py and OpenIdConnect. Would probably be good if that could be straightened out for all occurrences there.