使用基于表单的身份验证时，http 服务器应在 401 响应中返回什么 WWW-Authenticate 标头？

Question

我有一个在浏览器上运行的带有 Javascript 部分的 Web 应用程序。该前端使用多个 HTTP 端点（或多或少 REST）。前端必须能够区分401 和403 响应，并且不得接收通常用于人类用户的3xx 重定向。

通过纯表单登录完成授权（其中不涉及 Javascript），然后使用会话 cookie（用于“REST”和普通请求）。

WWW-Authenticate 标头值的正确值是多少？

• 来自RFC 7235：“生成 401（未经授权）响应的服务器必须发送包含至少一个质询的 WWW-Authenticate 标头字段。”

• Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry 没有列出任何基于表单的身份验证方案。

另见：

• HTTP 401 Unauthorized when not using HTTP basic auth?
• Authorization in RESTful HTTP API, 401 WWW-Authenticate

Answer 1

WWW-Authenticate 标头值的正确值是多少？

当您不使用RFC 7235 中所述的 HTTP 身份验证时，返回 401 和 WWW-Authenticate 是没有意义的。在 HTTP 身份验证中，客户端应使用 authentication scheme 令牌在请求的 Authorization 标头中发送凭据。

如果您想使用POST 在请求负载中发送凭据，则403 状态码更适合表明服务器已拒绝该请求。

Answer 2

由于这种类型的身份验证没有标准挑战，因此您（正如您自己预测的那样）发明了自己的。

我认为这里没有指定供应商令牌的标准机制，所以我认为您能做的最好的事情是使用不太可能与其他任何东西发生冲突的令牌。

亚马逊已经通过AWS 做到了这一点，还有很多其他的。我的建议是使用productname-schemename 之类的东西，例如acme-webauth。

Answer 3

没有用于基于表单的身份验证的 HTTP 身份验证方案。 浏览器通过显示一个可以输入凭据的弹出窗口来实现基本、摘要等。

Answer 4

理论上你应该回应

HTTP/1.x 401 Unauthorized
WWW-Authenticate: cookie; cookie-name=my-session-cookie-name

但是，现实世界的互联网浏览器（用户代理）并不真正支持这一点，根据我的经验，最不坏的选择是对所有“拒绝访问”使用 HTTP 状态 403，“未经授权”和“不允许”。如果您有一个通过非浏览器用户代理仅访问的 REST 服务，您可以按照规范并返回上述标头。

如 RFC 7231 第 6.5.4 节 (https://www.rfc-editor.org/rfc/rfc7231#section-6.5.4) 中所述，服务器可以用 404 响应“拒绝访问”和“未找到”，因此对于所有用户代理（浏览器）来说，以下应该是可以的：

403: "Unauthorized" or "Not allowed"
404: "Access Denied" or "Not Found"

或者您可以在任何情况下使用400，因为这会导致浏览器回退到通用错误处理情况。状态码 401 尤其成问题，因为它在历史上意味着（至少在实践中）使用了基本领域身份验证并且不接受提交的 HTTP 标头 Authorization。由于您无法通过该标头在常用浏览器中提交会话 cookie，因此当您使用 cookie 进行身份验证时，这些浏览器无法正确处理 401。