如果外部世界不能直接访问apis，为什么内部服务之间的通信需要像oauth这样的授权？

Question

这只是一个关于微服务架构的一般性问题。如果外部世界无法访问两个或更多内部服务，为什么它们仍然需要像oauth2这样的令牌身份验证来相互通信？难道他们的apis不能只过滤内部IP地址吗？这种方法的风险是什么？

Answer 1

如果外部世界无法访问两个或更多内部服务，为什么它们仍然需要像oauth2这样的令牌身份验证来相互通信？

您不需要OAuth2或令牌身份验证，但您应该使用它。这取决于你有多信任你的流量。现在，在“云时代”，不拥有自己的数据中心是很常见的，所以有另一部分人拥有你的服务器和网络硬件。该部分可能会进行错误配置，例如，来自另一个客户的流量被路由到您的服务器。或者，您可能设置了自己的基础设施并进行了错误配置，从而使来自测试环境的流量无意中被路由到您的生产服务。有了新的实践来处理这种新的情况，Google BeyondCorp和Zero Trust Networks中对此进行了描述。

从本质上讲，您不应该信任网络流量。对所有请求使用身份验证(例如OAuth2、OpenID连接、JWT)，并使用TLS或mTLS加密所有流量。

的apis不能只过滤内部IP地址吗？这种方法的风险是什么？

如上所述，也许你也不应该相信内部流量。

此外，现在通常使用OpenID头中发送的JWT连接(基于OAuth2的身份验证)- JWT-tokens对最终用户进行身份验证。大多数系统在处理请求时都将在用户上下文中操作，该上下文位于JWT-token中，并且很容易在请求中将该令牌传递给用户请求的操作所涉及的所有服务。

Answer 2

对于内部服务，通常不是验证令牌(理论上这已经由面向外部的网关/api完成)，而是更多地传递用户的标识信息。即使是内部服务也经常想知道谁是权限和访问控制的请求/代理用户，有时告诉每个需要用户作用域的服务创建者接受Authorization中的JWT要比说“在X-COMPANY-USER-ID header中查找用户ID”容易得多。

Answer 3

您可以使用Oauth在Microservices公开的apis上实现非常细粒度的基于角色的访问控制(RBAC)，这是使用过滤IP地址做不到的。