Currently in the API issues with authentication (We have no idea who you are due to a missing user-entry in the request) are handle by throwing an Exception with HTTP-Status-code of 400 (BAD REQUEST) or 403 (NOT AUTHORIZED).
Issues with authorization (We know who you are but you are not allowed to do this) are usually handeled by throwing an Exception with HTTP-Status-code of 403 (NOT AUTHORIZED) which is fine.
Shouldn't issues with authentication be handled by throwing an Exception with HTTP-Status-code 401 (Unauthorized)? According to [RFC 5849](https://tools.ietf.org/pdf/rfc5849.pdf#page=27) we could then add a WWW-Authenticate-header to the responses that are triggered by any Exception with code 401.
That would mean to touch the error-handling to add the condition for the 401-error-code and then check all controllers for Exceptions being thrown due to unauthenticated users and change them to 401.
Is it worth it? I'd say Yes, as it makes the API more clear in what actually has been the issue with the request. 400 is such a generic thing that the client can't easily decide it's due to not being logged in or due to some typo anywhere in the request.