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
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).
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.
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.