title: Signalling authentication failure in a RESTful API
body: <p>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.</p>
  
  <p>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.</p>
  
  <p>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 <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html" rel="noreferrer">rfc2616 sec 10.4.2</a>.</p>
  
  <blockquote>
    <p>The response MUST include a
    WWW-Authenticate header field (section
    14.47) containing a challenge applicable to the requested resource.</p>
  </blockquote>
  
  <p>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)?</p>
  
  <p>Bottom line: is it OK to use 401 in this context, or is there a better solution?</p>