API网关后面的资源服务器是否应该独立地验证身份验证声明？

Question

是否认为通过不可验证的普通字符串报头来“身份验证”是可以的--仅仅断言一个主体名称(User-ID: 12345)，只要这是在验证身份验证的API网关之后？

。

除了作为反向代理(基于URL的路由、SSL终止、负载平衡等)的基本用途外，API网关还经常用于合并请求身份验证。例如见香港:认证参考资料，网关:访问控制。

我正在回顾一些执行此操作的体系结构，但随后将可验证的身份验证输入替换为可验证的标头，类似于用户名。作为普通的报头，这些消息不能由任何实际的上游服务进行验证。换句话说，实际的资源服务器只需接收一个简单的字符串头，以达到User-ID: 12345的效果。注意，API网关后面的通信也是纯HTTP的(SSL在网关处终止)。

示例:不可验证的标题：香港官方OAuth 2.0认证器设置上游报头

这让我感到非常不舒服，因为任何能够与API网关后面的内部网络中的资源服务器通信的代理都可以通过设置标头值来声明自己想要的任何主体。为证明这一点而提出的论点是，资源服务器只能通过网关(S)在它们自己的虚拟专用网络中访问。

我更倾向于将所有身份验证细节都传递回每个资源服务器以进行完整的处理，而是让API网关(S)提供一个只有API网关或其委托身份验证器才能产生的加密可验证断言(例如带有sub声明的JWT )。然后，资源服务器将能够验证身份声明是由受信任的源断言的，而不仅仅是网络上任何想要成为User-ID: 12345的代理。

例如:可验证的JWT：香港官方OpenID连接认证器，特别是标头，似乎表明它设置的标头是可验证的JWT，尽管没有说明使用哪个键对其进行签名。

默认情况下，插件将Authorization: Bearer <access-token>头中的访问令牌传递给上游服务。

所以，我的同行们，我是不是被困在了一个不值得信任的偏执世界里？我前面描述的无法验证的头方法(完全依赖于虚拟网络的正确配置)现在是否已经足够好了？

Answer 1

这一切都取决于每一家公司认为对他们来说足够安全的是什么。

只在边境进行核查的既定方法可能就足够了。你喜欢的深度安全方法显然会更好。

除了存在于同一网络中的邪恶行为者的风险外，您还应考虑：

• 意外代理:特权网络中的另一个系统中存在一个非预期代理 (相对不太可能)。
• 标头注入:通过将换行符嵌入到另一个标头(例如，复制到报头的POST参数)，我可能能够注入一个新的User-ID: 281745头。
• 标头同义词:如果网关设置和过滤的正是User-ID，但是处理实际上将UsEr-Id:或User_ID:视为相同的标头。由于CGI接口的工作方式，这并不像看上去的那么不可能。例如，参见维基百科事件。
• 困惑的代理:如果我能够在网关考虑的内容中将两个请求滑动到后端，那么我将控制第二个请求的头。

然而，在最终后端进行更强的验证将使执行任何这些攻击变得更加困难(代价是那里的复杂性更高)。

显然，这些都不是当前的问题，但是稍后会在网关或后端的更新中无意中引入这些问题。