微服务认证策略
我很难为微服务架构选择一个像样的/安全的身份验证策略。我在这个话题上找到的唯一一篇帖子是：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永远不需要对用户进行身份验证。
这两种解决方案在以下方面有何不同：
使用的
- security
- robustness
- scalability
- ease
或者你可能会建议另一个我在这里没有提到的解决方案？
我更喜欢解决方案#1，但还没有找到很多默认的实现来确保我走在正确的方向上。
回答 4
Stack Overflow用户
发布于 2015-04-16 20:50:12
根据我的理解，一个很好的解决方法是使用OAuth 2协议(你可以在上找到更多关于它的信息)
当您的用户登录到您的应用程序时，他们将获得一个令牌，并且使用此令牌，他们将能够发送到其他服务，以在请求中标识他们。
链式微服务设计示例
资源：
Stack Overflow用户
发布于 2018-03-08 07:48:01
简而言之:使用Oauth2.0基于令牌的身份验证，它可以在任何类型的应用程序中使用，如webapp或移动应用程序。然后，web应用程序所涉及的步骤序列将是
- 根据ID提供商进行身份验证
- 将访问令牌保留在cookie中
- 访问webapp中的页面
- 调用服务
下图描述了所需的组件。这种将web和数据api分离的体系结构将提供良好的可扩展性、弹性和稳定性。
Stack Overflow用户
发布于 2021-07-14 23:45:07
您可以通过使用JWT令牌来避免在后台存储会话信息。
下面是使用OAuth 2.0和OpenID Connect时的样子。我还将用户名和密码登录添加到答案中，因为我假设大多数人也会将其添加为登录选项。
以下是该解决方案的建议组件：
- Account-service:，一个负责用户创建和身份验证的微服务。可以有Google，Facebook和/或常规用户名和密码身份验证端点-登录，注册。在注册时-意味着通过注册端点或第一次google/fb登录，我们可以在数据库中存储有关用户的信息。在用户使用任一选项成功登录后，我们将在服务器端使用相关用户数据创建一个JWT令牌，如userID。为了避免篡改，我们使用我们定义的令牌秘密(这是一个字符串)对其进行签名。此令牌应作为httpOnly cookie与登录响应一起返回。为了安全起见，建议只使用https。对于OpenID连接specification.
，此内标识将是ID内标识
JWT侧web应用程序：接收签名的httpOnly cookie形式的JWT，这意味着javascript代码无法访问此数据，从安全的角度来看，建议您这样做。在向服务器或其他微服务发送后续请求时，我们将cookie附加到请求中(在axios中，这意味着使用withCredentials: true)。
需要通过令牌对用户进行身份验证的
- Microservices :这些服务验证JWT令牌的签名，并使用为签署令牌而提供的相同秘密读取它。然后，它们可以访问存储在令牌上的数据，如userID，并从数据库中获取有关用户的附加信息，或执行任何其他逻辑操作。注意-这不是用于授权，而是用于身份验证。为此，我们有刷新令牌和访问令牌，这超出了问题的范围。
我最近专门为这个主题创建了一个详细的指南，以防它对某人有帮助：https://www.aspecto.io/blog/microservices-authentication-strategies-theory-to-practice/
https://stackoverflow.com/questions/29644916
复制相似问题
腾讯云开发者
