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

Question

所以我正在尝试实现以下方案：

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

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

阅读规范后，我不确定应该如何实现这一点。我想要做的是：

1. 用户向代理发出HTTP请求，而不进行任何类型的身份验证。
2. 代理人回复407 Proxy Authentication Required并返回Proxy-Authenticate标题，格式为："Proxy-Authenticate: Basic realm="proxy.com"。
   问题：这是{{1}标题是否正确设置？
3. 然后，客户端使用Proxy-Authenticate标头重试请求，该标头是代理Proxy-Authorization的Base64表示。
4. 这次代理对请求进行身份验证，然后应用程序以username:password标头回答。用户由代理进行身份验证，但不是由应用程序进行身份验证。该应用程序会在响应中添加401 Unauthorized标头，例如WWW-Authenticate。 问题：此标头值是否正确？
5. 客户端再次使用WWW-Authenticate: Basic realm="app.com"标头和使用应用Proxy-Authorization的Base64表示值的Authorization标头重试请求。
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证书，允许对两者的身份进行身份验证。