我很难为微服务架构选择一个像样的/安全的身份验证策略。我在这个话题上找到的唯一一篇帖子是:Single Sign-On in Microservice Architecture
我在这里的想法是在每个服务中都有(例如,身份验证、消息传递、通知、配置文件等)对每个用户的唯一引用(从逻辑上讲,然后是每个用户的user_id
),以及在登录时获取当前用户的id
的可能性。
从我的研究中,我看到有两种可能的策略:
1.共享架构
在此策略中,身份验证应用程序是其中的一个服务。但是每个服务都必须能够进行session_id
=> user_id
的转换,所以它必须非常简单。这就是为什么我想到Redis,它将存储键:value session_id:user_id
。
2.防火墙架构
在此策略中,会话存储实际上并不重要,因为它只由身份验证应用程序处理。然后,可以将该user_id
转发到其他服务。我想到了Rails + Devise (+ Redis或mem-cached,或cookie存储等)。但是有很多的可能性。唯一重要的是Service X永远不需要对用户进行身份验证。
这两种解决方案在以下方面有何不同:
使用的
或者你可能会建议另一个我在这里没有提到的解决方案?
我更喜欢解决方案#1,但还没有找到很多默认的实现来确保我走在正确的方向上。
发布于 2015-04-16 20:50:12
根据我的理解,一个很好的解决方法是使用OAuth 2协议(你可以在上找到更多关于它的信息)
当您的用户登录到您的应用程序时,他们将获得一个令牌,并且使用此令牌,他们将能够发送到其他服务,以在请求中标识他们。
链式微服务设计示例
资源:
发布于 2018-03-08 07:48:01
简而言之:使用Oauth2.0基于令牌的身份验证,它可以在任何类型的应用程序中使用,如webapp或移动应用程序。然后,web应用程序所涉及的步骤序列将是
下图描述了所需的组件。这种将web和数据api分离的体系结构将提供良好的可扩展性、弹性和稳定性。
发布于 2021-07-14 23:45:07
您可以通过使用JWT令牌来避免在后台存储会话信息。
下面是使用OAuth 2.0和OpenID Connect时的样子。我还将用户名和密码登录添加到答案中,因为我假设大多数人也会将其添加为登录选项。
以下是该解决方案的建议组件:
,此内标识将是ID内标识
JWT侧web应用程序:接收签名的httpOnly cookie形式的JWT,这意味着javascript代码无法访问此数据,从安全的角度来看,建议您这样做。在向服务器或其他微服务发送后续请求时,我们将cookie附加到请求中(在axios中,这意味着使用withCredentials: true)。
需要通过令牌对用户进行身份验证的
我最近专门为这个主题创建了一个详细的指南,以防它对某人有帮助:https://www.aspecto.io/blog/microservices-authentication-strategies-theory-to-practice/
https://stackoverflow.com/questions/29644916
复制相似问题