ASP.NET Core MVC return Forbid/403 is backwards? [duplicate]

Question

REOPEN THIS

Someone marked this as duplicate for 403 Forbidden vs 401 Unauthorized HTTP responses

but that doesn't answer my question. I know what the 2 codes are SUPPOSED to be. What I'm asking is why ASP.NET Core seems to have it backwards.

Question

Using ASP.NET Core 3.1

I'm writing controller level authorization (not using middle ware and policies). If the user wasn't found in the request, I return a 401. If they are found but don't have access to a resource, I return a 403. This is my understanding of what I should be doing based on my googling.

But when I go to implement this in code, ASP.NET Core docs seem to imply the reverse. The Forbid method asks for authentication schemes as if it's gonna ask the client to log in. The Unauthorized method doesn't (it has some other parameter called value of type object which I don't know what that's for but that's beside the point I think).

From definitions in Microsoft.AspNetCore.Mvc.Core assembly

[Controller]
public abstract class ControllerBase
{
    ...

    // 403
    [NonAction]
    public virtual ForbidResult Forbid(params string[] authenticationSchemes);

    // 401
    [NonAction]
    public virtual UnauthorizedResult Unauthorized();

    ...
}

According to the documentation on the method, it looks like the schemes for the 403 is so that it can challenge the authentication which, to my understanding, many times means requesting that the client authenticate.

It seems like this is backwards. Why would ASP.NET Core ask for authentication on a response that implies the client is already authenticated? I would expect that on the 401 Unauthorized method but not for 403.

Am I missing something here?

Answer 1

401 Unauthorized

The 401 Unauthorized response status code indicates that the client request has not been completed because it lacks valid authentication credentials for the requested resource.

403 Forbidden

The 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 permanently forbidden and tied to the application logic, such as insufficient rights to a resource.

Neither response is a request for further action.