我使用SpringBoot1.5.x+oauth2和jwt开发了一组微服务（资源服务器）。现在，每个微服务都使用Spring Security 进行保护，即jwt访问令牌在单个资源服务器级别进行验证。api网关没有spring安全机制，所以它只是将请求路由到适当的服务器，并将身份验证头传播到下游服务。
我想知道与只在api网关级别验证accesstoken的设置相比，这种设置是否有任何缺点。还是只是意见问题？将安全性保持在api网关级不就打破了松耦合的原则吗？因为每个微服务都可以更好地理解给定用户在自己上下文中的角色？
2条答案
按热度按时间3bygqnnd1#
api管理可以对jwt（failearly）做一个小检查，但是只有你的微服务可以真正管理所有的安全性东西！
如果您仅在api管理上设置安全性，则意味着可以访问您的网络的人可以在未经验证的情况下将请求推送到您的api。你将无法记录谁在做什么。最后，如果您需要设置某种acl，这将是不可能的（当您要求列出订单时，您只能列出您的订单）。
也许您会考虑在api管理层上解码jwt，并将带有用户名的头推送到后端，以防止上面提到的所有事情，但我认为这并不是一个好的做法。
首先，进入网络意味着我可以成为任何人。那么jwt不仅仅是一个用户名。例如，您可以在身份验证层上使用作用域范围读取命令/范围修改命令/范围删除命令）。这有助于限制应用程序可以做什么（在客户端id级别）或用户接受给应用程序什么（范围共享电子邮件…）。对于这个jwt，后台是强制性的。
好吧，你可以像用户名一样，在api管理中提取数据，把特定的头文件放到后端调用，但真的吗？为什么要做特定的事情？oauth2和jwt可以为您做这件事。
a64a0gku2#
这是个有趣的问题。在我们团队中，我们经常讨论这个主题。基本上你有一些参数影响这个问题的答案。但您也应该始终在微服务级别上解码和验证已授予的令牌。因为它们包含用于身份验证的相关信息，在某些情况下甚至用于授权。如果您的微服务在封闭的环境中运行（例如，在封闭的kubernetes集群上，只有api网关对外可用），那么您可以使用这种“混合”解决方案。
您可以考虑在api网关上验证accesstoken，并让其他微服务依赖于api网关。api网关无法将accesstoken交换为另一个authtoken，该authtoken仅在微服务上下文中有效。例如，这个新生成的authtoken可以包含更敏感的应用程序绑定信息，因为它不会向客户端公开。客户机只获得所谓的不透明令牌。看到了吗https://medium.com/tech-tajawal/microservice-authentication-and-authorization-solutions-e0e5e74b248a