在 RESTful API 中发送身份验证失败信号答案

【问题标题】：Signalling authentication failure in a RESTful API在 RESTful API 中发送身份验证失败信号
【发布时间】：2010-12-09 18:39:06
【问题描述】：

我正在编写一个小应用程序，它公开了一个简单的 REST 式 HTTP API。由于缺乏授权，我一直在努力决定如何发出失败信号。

该应用没有用于身份验证的 API，而是依赖于包含客户端通过其他服务获取的会话令牌的 cookie 的存在。应用程序验证会话并使用通过验证过程获得的身份来执行特定于应用程序的授权。客户端无法直接向此应用进行身份验证。

我的问题是，用于拒绝未经授权的请求的明显 HTTP 状态代码“401 Unauthorized”是根据“WWW-Authenticate”标头指定的。见rfc2616 sec 10.4.2。

响应必须包含 WWW-Authenticate 标头字段（部分 14.47) 包含适用于所请求资源的质询。

我不敢相信这是一个不常见的问题。简单地重载 401 以包含更一般的用途是否很常见？浏览器弹出 auth/e 对话框怎么样（顺便说一下，我在测试中没有看到，所以也许 POST 不会发生这种情况）？

底线：在这种情况下使用 401 可以吗，还是有更好的解决方案？

【问题讨论】：

如果您使用 cookie，它就不是 RESTful API。 REST 服务根据定义是无状态的。
公平点 - 我将描述更改为 REST-ish，而不是 RESTful。那么你认为答案是要么正确实现每个请求的身份验证，要么放弃我对 RESTishness 的尝试？
很难说，这取决于你的应用。 REST 方法有一些优点。如果您想继续使用服务器端会话，我会按照 tvanfosson 的说法返回 403。

【解决方案1】：

通常，如果客户端可以进行身份验证并解决问题，您会发送 401，但由于您没有提供在 API 中进行身份验证的方法，我建议改为返回 403 错误（禁止）。这不需要标头，并将向客户端指示它无法访问服务。

【讨论】：

如果请求方法不是 HEAD 并且服务器希望公开请求未完成的原因，它应该在实体中描述拒绝的原因。如果服务器不希望向客户端提供此信息，则可以使用状态代码 404（未找到）来代替。 (w3.org/Protocols/rfc2616/rfc2616-sec10.html)
@vquintans 404 not found 在这种情况下似乎是模棱两可的。假设客户端请求了一个可能存在也可能不存在但没有 cookie 的特定资源？您如何解释 404 错误？它是否因为资源不可用或身份验证错误而失败。我会坚持明确表明需要授权的回复。
是的，我同意。但无论如何，我认为从 RFC 中评论这种可能性是很有趣的。

【解决方案2】：

返回类似这样的内容：

HTTP/1.1 401 Unauthorized
Location: https://example.com/auth-app/login

【讨论】：