我使用 Spring Boot 1.5.x + OAuth2 和 JWT 开发了一组微服务（资源服务器）。现在每个微服务都使用 Spring Security 进行保护，即 JWT 访问令牌在单个资源服务器级别进行验证。 API Gateway 没有 Spring Security，因此它只是将请求路由到适当的服务器并将身份验证标头传播到下游服务。
我想知道与仅在 API 网关级别验证 AccessToken 的设置相比，此设置是否有任何缺点。还是只是意见问题？保持 API 网关级别的安全性不会破坏松耦合原则，因为每个微服务都可以更好地了解给定用户在其自身上下文中的角色吗？
【问题讨论】：
标签： spring-boot microservices spring-security-oauth2
API 管理可以对您的 JWT 做一个小检查（提前失败），但是您的微服务是唯一可以真正管理所有安全内容的服务！
如果您仅在 api 管理上设置安全性，这意味着可以访问您的网络的人将能够在未经身份验证的情况下向您的 API 推送请求。 您将无法记录谁做了什么。最后，如果你需要设置某种ACL，这是不可能的（当你要求列出订单时，你只能列出你的订单）。
也许您会考虑在 api 管理层解码您的 JWT，并将带有用户名的标头推送到您的后端，以防止我上面所说的所有事情，但我认为这不是一个好习惯。
首先，访问网络意味着我可以成为任何人。那么 JWT 不仅仅是一个用户名。例如，也许您在身份验证层上使用范围。 （范围读取命令/范围修改命令/范围删除命令）。这对于限制应用程序可以做什么（在 client_id 级别）或用户接受给应用程序的内容（范围共享电子邮件...）很有用。 对于后台的这个 JWT 是强制性的。
好的，您可以在 api 管理中使用用户名和提取数据并将特定标头放入调用后端，但真的吗？为什么要做具体的东西？带有 JWT 的 oauth2 可以为您做到这一点。
【讨论】：
这是一个有趣的问题。在我们的团队中，我们就这个话题讨论了很多。基本上你有一些影响这个问题的个人答案的参数。但是您也应该始终在微服务级别解码和验证授予的令牌。因为它们包含用于身份验证的相关信息，在某些情况下甚至用于授权。如果您的微服务在封闭环境中运行（例如，在封闭的 Kubernetes 集群上，外部只有 API-Gateway 可用），您可以使用这种“混合”解决方案。
您真的可以考虑只在 API-Gateway 验证 AccessToken，让其他微服务依赖 API Gateway。 API 网关可以将 AccessToken 交换为另一个 AuthToken，仅在微服务上下文中有效。例如，这个新生成的 AuthToken 可以包含更敏感的应用程序绑定信息，因为它不会暴露给客户端。客户端只得到一个所谓的不透明令牌。见https://medium.com/tech-tajawal/microservice-authentication-and-authorization-solutions-e0e5e74b248a
【讨论】：