Correct http status code for resource which requires authorization

Question

There seems to be a lot of confusion about the correct http status code to return if the user tries to access a page which requires the user to login.

So basically what

Answer 1

I'm not talking about HTTP authentication here, so that's at least 1 status code we aren't going to use (401 Unauthorized).

Wrong. 401 is part of Hypertext Transfer Protocol (RFC 2616 Fielding, et al.), but not limited to HTTP authentication. Furthermore, it's the only status code indicating that the request requires user authentication.

302 & 200 codes could be used and is easier to implement in some scenarios, but not all. And if you want to obey the specs, 401 is the only correct answer there is.

And 403 is indeed the most wrong code to return. As you correctly stated...

Authorization will not help and the request SHOULD NOT be repeated.

So this is clearly not suitable to indicate that authorization is an option.

I would stick to the standard: 401 Unauthorized

-

UPDATE

To add a little more info, lifting the confusion related to...

The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource.

If you think that's going to stop you from using a 401, you have to remember there's more:

"The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI."

This "indicating the authentication scheme(s)" means you can opt-in for other auth-schemes!

The HTTP protocol (RFC 2616) defines a simple framework for access authentication schemes, but you don't HAVE to use THAT framework.

In other words: you're not bound to the usual WWW-Auth. You only just MUST indicate HOW your webapp does it's authorization and offer the according data in the header, that's all. According to the specs, using a 401, you can choose your own poison of authorization! And that's where your "webapp" can do what YOU want it to do when it comes to the 401 header and your authorization implementation.

Don't let the specs confuse you, thinking you HAVE to use the usual HTTP authentication scheme. You don't! The only thing the specs really enforce: you just HAVE/MUST identify your webapp's authentication scheme and pass on related parameters to enable the requesting party to start potential authorization attempts.

And if you're still unsure, I can put all this into a simple but understandable perspective: let's say you're going to invent a new authorization scheme tomorrow, then the specs allow you to use that too. If the specs would have restricted implementation of such newer authorization technology implementations, those specs would've been modified ages ago. The specs define standards, but they do not really limit the multitude of potential implementations.