我有简单的微服务架构：
当用户尝试登录时，凭据从边缘服务传递到身份验证服务。Auth服务从用户服务中获取用户数据（使用@FeignClient），如果用户名/密码匹配，它将生成令牌。没什么好看的。
这种方法存在一个“小”问题：/api/user/{username}用户服务中的端点（由身份验证服务用于获取用户数据）可能被任何用户用来获取其他任何用户的数据（密码，角色等）。一种解决方案是以某种方式为具有角色的auth-service创建JWT令牌，AUTH_SERVICE并在用户服务端检查JWT，以及角色是否不同于AUTH_SERVICE拒绝请求。
还有其他解决方案吗？
编辑
我以为我的设计很普遍，但显然我应该首先更加具体：
编辑2：
我最终将auth-service合并到user-service，这是几个SO用户提出的建议。在考虑了这一点之后，似乎不必为JWT生成单独的auth-service。我接受了@Abhijit Sarkar的答案，因为它有一些有效的观点，即使他不赞成额外调用auth-service来验证令牌的有效性。
在我看来，您对服务的划分太细了；这种情况发生了，随着时间的流逝，您开始意识到由于维护和性能问题，服务需要更粗粒度。从身份验证到用户服务的另一个HTTP调用的成本，以及维护服务间身份验证的开销都不是小事。
IMO，用户服务可以用于其他用户信息，例如地址等（如果存在的话），但是auth服务应负责管理其自身的数据。这正是Spring Security具有UserDetailsService的原因。
用户凭据和其他用户信息应该在同一表中，甚至在同一数据库中，这实际上是一个设计选择。不同的人会给你不同的答案，但在我看来和经验，之间一个共享的数据库小数目的相关服务是可以接受的，特别是因为这些表要由外键（用户ID）有关。对于微服务而言，分布式事务纯粹是邪恶的，所以我什至不去。删除/更新用户时，请使用事件来最终实现一致性。
编辑：
与OP聊天之后，我了解到用户服务实际上是他设计中的OAuth资源服务器。对于他（因此对我）来说，OAuth授权服务器在哪里还不清楚。无论如何，我都支持合并用户服务和auth服务的建议。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句