HTTP 401 Unauthorized or 403 Forbidden for a “disa

Question

An authentication service allows user accounts be disabled (a sort of soft-delete).

If the server then receives an authentication request for a disabled user that would otherwise be valid, should the server return 401 or 403? With either status code, I would return a message indicating that the account had been disabled.

For quick reference, relevant quotes from HTTP/1.1 spec (emphasis mine):

401 Unauthorized

The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].

403 Forbidden

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

Answer 1

technically both are correct, it really comes down to how much you want to reveal.

returning a 401 says to the caller that the account isn't valid, which is correct, but if your api is then going to be called again to register a user with the same credentials that call would also fail. which might not be much use to the caller.

so, it really depends on how your api will be used and who/what the target audience is.

Answer 2

I've got two different answers for what to return in this case.

Semantic choice - 401 Unauthorized. In this case, your client has provided credentials, and the request has been refused based on the specific credentials. If the client were to try again with a different set of credentials, or if the account were to be re-enabled in the future, the same request might succeed.

Security choice - 404 Not Found. Many services will simply return a 404 for any failure, in order to avoid information leakage. Github comes to my mind immediately.

From General API Information, in github's developer docs:

Unauthenticated requests will return 404 to prevent any sort of private information leakage.

For something I was deploying as a public service, I'd probably go with using 404 to avoid giving an attacker clues about their credential attempts. If it was for internal-only consumption, or in testing, I'd probably return 401.

Answer 3

Based on an email written by Roy T. Fielding, there's apparently a bug in the current HTTP spec.

The way the spec is intended to be read is as follows (using quotes from above email):

401 "Unauthenticated":

you can't do this because you haven't authenticated

403 "Unauthorized":

user agent sent valid credentials but doesn't have access

So, in the case of a disabled user, 403 is the correct response (and 404 is also an option).