我有两个服务——A 和 B——它们都公开了一个 HTTP/REST API。服务 A 向公众公开并对其用户进行身份验证。它将部分工作负载委托给服务 B，服务 B 还必须知道经过身份验证的用户的身份并执行一些访问控制。服务 B 没有公共 IP 地址，只接受来自同一内部网络中的服务的连接（服务 A 是其中之一）。
由于我认为 A 和 B 之间的连接受信任（它们都位于两个防火墙之后），因此我只需在自定义 HTTP 标头中传递用户身份。这个设置中是否存在我没有想到的漏洞？是否有传递用户身份而不是使用自定义 HTTP 标头的标准方法？
我的两项服务几乎完全相同。
由于以下思路，我采取了稍微不同的路线来解决它：如果由于防火墙或路由器的某些错误配置，服务 B 突然在互联网上或我公司的内部网络上可用，会发生什么情况? 我们已经更改了防火墙规则，而没有被告知过去的更改；所以我变得小心翼翼。
这就是我目前正在做的事情：服务 A 和 B 共享一个只有他们知道的秘密密码。我使用它在服务 A 上的一个小型 json 结构（我的“访问令牌”）上构建一个 hmac，该结构基本上包含经过身份验证的用户的用户名、随机数和到期日期。我将访问令牌和 hmac 传递给服务 B（作为标准授权标头中的长 base64 编码字符串）。然后服务 B 使用 hmac 验证访问令牌，如果它签出，则可以合理地确定它收到的访问令牌来自服务 A。剩下的就是确保访问令牌没有过期。
你可以用 JWT 做同样的事情，用公钥加密对访问令牌进行数字签名，而不是我用 hmac 做的事情。
这与您正在做的事情并没有太大不同 - 构建我的访问令牌（只有一次，当用户登录服务 A 时）并没有太多工作，也没有验证服务 B 上的令牌，但确实如此与您的解决方案相比，添加一些额外的安全性。
就像您一样，我会对描述解决此问题的普遍接受方式的答案感兴趣 - 我一直认为我的解决方案有点过于本土化，并且可能会遇到我无法立即看到的问题。
“纵深防御”是关于失败的计划。在这种网络模型中，服务器端请求伪造 (SSRF)漏洞对对手来说非常有价值。
请记住，没有开发人员打算实施不安全的软件，但这些问题非常猖獗。