简短:如何在微服务架构中对基于角色的用户进行身份验证和授权?
长:假设您具有以下给出的体系结构。 我正在努力寻找确保这种架构安全的最佳实践解决方案。 当我搜索时,会得到很多不同的答案。
“将身份验证留给第三方OAuth提供者” 。对于一个相当简单的应用程序来说,这似乎增加了很多开销和复杂性,并且可能不希望将身份验证和授权委派给第三方。
“使用JWT” 。如果我是正确的话,那么使用JWT令牌不适合外部使用(例如在SPA中)。
“使用外部不透明令牌和内部连接在redis / mechchache中的JWT的组合” 。对于我给定的情况,这似乎是最好的解决方案,但是我的问题是缺少对库/代码示例的实际引用。
如果有人对我想要实现的实际实现有一些参考,我会非常高兴: 微服务架构中的身份验证,基于角色的授权。
答案 0 :(得分:2)
没有足够的信息来建议您使用身份验证和授权的体系结构应该怎么做,但是我可以告诉您我倾向于使用的一种方法。
遵循OAuth,因为它为您提供了很多选择,您可以从自己的IDM / IAM开始,以后可以通过社交平台进行连接。
我们从JWT开始,在大多数情况下,这只是一个已签名的令牌(一段时间后,我们转向了已签名和加密的令牌)。我们创建了一个服务,负责处理身份验证和创建JWT令牌。 (我们从 Keycloak 开始,但后来由于keycloak在我们的用例中体积不大而转移到自己的服务中
当您说外部时,我不确定您的意思是什么,如果最终用户IMO可以访问它,那么我们只能使用一个已签名的令牌。是的,所有信息对用户都是可见的,但这就是他的所有信息以及一些与授权相关的信息。
如果您将令牌传递给边界之外的人,实际的外部系统,而您不想共享使用信息,则可以考虑对其进行加密,但是接下来您将需要做很多事情从安全的角度考虑,因此选择标准的安全平台或第三方提供商(你们俩都可以信任谁,并且在保护它方面投入了足够的思想)可以长期为您提供帮助。
使用不透明令牌和JWT的组合可能是一个过大的杀伤力,除非您有很强的理由反对它。 IMO您一开始就很简单,可以一直使用JWT,如果需要,可以对其进行加密。您所需要做的就是提供另一项服务来管理身份验证以及创建和签名令牌,您应该会很好。