401 Unauthorized means you aren’t authenticated, or your authentication is broken/expired/invalid.

403 Forbidden means that your authentication is valid, but that you don’t have access to the resource.

401 should not be used to indicate the latter.

HTTP Authentication requires a lot of care to interact with the browser's authentication flow and UI.

I worked on a site for several years that used HTTP Digest authentication. We finally gave up on it and switched to the standard form-and-cookie approach, because the browser authentication flows had so many bugs, quirks, per-browser idiosyncrasies, and other issues to work around.

I've never implemented the status codes for browser purposes - only for APIs.

HTTP Digest looks interesting, but I think I'd generally feel more comfortable just using HTTP Basic over HTTPS. Or better, of course, just doing it yourself with some signed cookies.

Why not? 401 seems like a fine fit if your client doesn't need to differentiate between authentication and authorization; most don't need to at all.

Also, you can fail authorization without passing authentication. For instance, you could be authorized by ip range or something unrelated to any of the data in the http request.

Wut. Most clients don't need to differentiate between "you're not allowed to do that" and "you're not logged in"? Those things require totally different reactions, no?

> Why not?

Because those are the semantics as-per the spec.

In relation to your latter point, 403 also covers any other reasons your access is forbidden - e.g. IP ranges etc.

> "unauthorized" (you passed authentication information but it wasn't acceptable)

That's still "unauthenticated". "Unauthorized" means that you were authenticated (i.e. the server knows who you are), but you are not allowed (i.e. authorized) to execute the requested operation. So the correct names would be "401 Unauthenticated" and "403 Unauthorized".