HTTP 规范 : Proxy-Authorization and Authorization headers

Question

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

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

因此，用户必须在同一个请求中为代理和应用程序提供凭据，因此他有不同的用户名/密码对:一对用户名/密码对应用程序进行身份验证，另一个用户名/密码对对应用程序进行身份验证代理。

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

1. 用户在没有任何身份验证的情况下向代理发出 HTTP 请求。
2. 代理回答 407 Proxy Authentication Required 并返回 Proxy-Authenticate header ，格式为:"Proxy-Authenticate: Basic realm="proxy. com”。
   问题:Proxy-Authenticate header 设置是否正确？
3. 客户端然后使用 Proxy-Authorization header 重试请求，这是代理 username:password 的 Base64 表示。
4. 这一次代理对请求进行身份验证，但随后应用程序使用 401 Unauthorized header 进行响应。用户已通过代理进行身份验证，但未通过应用程序进行身份验证。应用程序将 WWW-Authenticate header 添加到响应中，例如 WWW-Authenticate: Basic realm="app.com"。 问题:这个 header 值是正确的吗？
5. 客户端再次使用 Proxy-Authorization header 和 Authorization header 重试请求，该 header 的值以应用程序的 username:password< 的 Base64 表示形式表示。
6. 此时，代理成功验证了请求，并将请求转发给对用户进行身份验证的应用程序。客户最终得到回复。

整个工作流程是否正确？

Answer 1

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

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

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

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

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