I'm writing a small application which exposes a simple REST-ish HTTP API. I'm stuck trying to decide how to signal a failure due to a lack of authorization.
The app does not have an API for authentication, but instead depends upon the presence of a cookie containing a session token obtained by the client via another service. The app verifies the session and uses the identity obtained through the verification process to perform app-specific authorization. There is no way for a client to authenticate directly to this app.
My problem is that the obvious HTTP status code for rejecting unauthorized requests, "401 Unauthorized", is specified in terms of the "WWW-Authenticate" header. See rfc2616 sec 10.4.2.
The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource.
I can't believe this is an uncommon problem. Is it common to simply overload 401 to include more general uses? What about browsers popping up auth/e dialogs (which incidentally I haven't seen in my testing, so maybe it doesn't happen for POSTs)?
Bottom line: is it OK to use 401 in this context, or is there a better solution?