Handle authentication and authorization issues in the API in a consistent way

Description

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.

Status

Assignee

Andreas Heigl

Reporter

Andreas Heigl

Labels

None

Epic Name <span class="error">&#91;deprecated, this field is no longer being used&#93;</span>

None

Components

Priority

Trivial