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

Question

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

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

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

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

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

整个工作流程是否正确？

Answer 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 证书，从而可以验证两者的身份。