Currently we use 401 Unauthorized as a catch-all for rejecting requests, even when the requester does not have the required privilege to access the resource.
The HTTP 403 Forbidden response status code indicates that the server understands the request but refuses to authorize it.
This status is similar to 401, but for the 403 Forbidden status code, re-authenticating makes no difference. The access is tied to the application logic, such as insufficient rights to a resource.
Consider the endpoint GET/users/{id}/clients. Currently, if the requesting user is not an admin, and their id does not match the given id, we reject the request with a 401 Unauthorized. This could be seen as misleading because it indicates that there is an issue with authorization, not privilege. Since the user does not have the privilege to access other user's clients, we should instead return a response of 403 Forbidden.
Soft breaking change, as response codes will be changed.
Currently we use
401 Unauthorizedas a catch-all for rejecting requests, even when the requester does not have the required privilege to access the resource.see MDN Documentation
Consider the endpoint
GET/users/{id}/clients. Currently, if the requesting user is not an admin, and their id does not match the givenid, we reject the request with a401 Unauthorized. This could be seen as misleading because it indicates that there is an issue with authorization, not privilege. Since the user does not have the privilege to access other user's clients, we should instead return a response of403 Forbidden.Soft breaking change, as response codes will be changed.