HTTP 规范：代理授权和授权标头

Posted 2023-03-07

【中文标题】HTTP 规范：代理授权和授权标头

【英文标题】：HTTP Spec: Proxy-Authorization and Authorization headers

【发布时间】：2012-04-18 21:35:51

【问题描述】：

所以我正在尝试实现以下场景：

应用程序受基本身份验证保护。假设它托管在app.com 在应用程序前面的 HTTP 代理也需要身份验证。它托管在proxy.com

因此，用户必须在同一个请求中为代理和应用程序提供凭据，因此他有不同的用户名/密码对：一对用于针对应用程序验证自己，另一个用户名/密码对用于验证自己针对代理。

阅读规范后，我不确定我应该如何实现它。我当时想做的是：

用户向代理发出 HTTP 请求，无需任何类型的身份验证。 代理回答407 Proxy Authentication Required 并返回Proxy-Authenticate 标头，格式为："Proxy-Authenticate: Basic realm="proxy.com"。问题：此Proxy-Authenticate 标头设置正确吗？ 然后，客户端使用 Proxy-Authorization 标头重试请求，这是代理 username:password 的 Base64 表示。 这次代理验证请求，但随后应用程序以401 Unauthorized 标头响应。用户由代理验证，但不是由应用程序验证。应用程序将WWW-Authenticate 标头添加到响应中，例如WWW-Authenticate: Basic realm="app.com"。 问题：此标头值正确吗？ 客户端使用Proxy-Authorization 标头和Authorization 标头再次重试请求，该标头的值是应用程序username:password 的Base64 表示。 此时，代理成功地对请求进行身份验证，并将请求转发给对用户进行身份验证的应用程序。客户终于得到了回复。

整个工作流程是否正确？

【问题讨论】：

好吧，感谢您在此处解释 Proxy-* 标头，正在寻找它们。但是你解决了你的问题吗？为什么这个问题仍然悬而未决？

由于您只是要求对该方法进行一般验证，因此我尝试在围绕此设置的其他排列的答案中添加一些额外的颜色。但是，如果您问这个问题是因为您尝试了您所描述的并遇到了特定错误，请更新问题以包含该错误；尽管我已尽力验证您发布的内容，但真正的测试只是尝试一下，看看会发生什么。

【参考方案1】：

是的，对于您所描述的情况，这看起来像是一个有效的工作流程，并且那些 Authenticate 标头的格式似乎正确。

有趣的是，给定的连接有可能（尽管不太可能）涉及链接在一起的多个代理，并且每个代理本身都可能需要身份验证。在这种情况下，每个中间代理的客户端本身会返回一个407 Proxy Authentication Required 消息，并自己用Proxy-Authorization 标头重复请求； Proxy-Authenticate 和 Proxy-Authorization 标头是单跳标头，不会从一个服务器传递到下一个服务器，但 WWW-Authenticate 和 Authorization 是端到端标头，被认为是从客户端到最终服务器，由中介逐字传递。

由于Basic 方案以明文形式发送密码（base64 是一种可逆编码），因此它最常用于 SSL。此方案以不同的方式实现，因为希望防止代理看到发送到最终服务器的密码：

客户端向代理打开一个 SSL 通道以发起请求，但它不会提交常规 HTTP 请求，而是提交a special CONNECT request（仍然带有Proxy-Authorization 标头）以打开到远程服务器的 TCP 隧道。 然后客户端继续创建嵌套在第一个中的另一个 SSL 通道，在该通道上传输包含Authorization 标头的最终HTTP 消息。

在这种情况下，代理只知道客户端连接的主机和端口，而不知道通过内部 SSL 通道传输或接收的内容。此外，使用嵌套通道允许客户端“看到”代理和服务器的 SSL 证书，从而可以验证两者的身份。

【讨论】：

我知道我正在从你那里复活这个知识领域（2 年前），但你知道大多数现代浏览器是否通过 SSL 发送代理基本身份验证？

我不确定我是否理解这个问题，但是：浏览器将在发送请求时通过同一通道发送基本身份验证凭据，因此如果您的代理 URL 是 https: 那么它将是在 SSL 通道中，但如果您的代理 URL 只是 http: 那么它将是明文的。

（如果我不理解您的问题，最好开始一个新的***问题，而不是试图在这里进一步解释。问题中的细节比评论更详细。）