微服务认证策略

Question

我很难为微服务架构选择合适/安全的身份验证策略.我在这个主题上发现的唯一SO帖子就是这个:微服务架构中的单点登录

我的想法是在每个服务(例如,身份验证,消息传递,通知,配置文件等)中为每个用户提供一个唯一的引用(在逻辑上user_id与他相当)以及在id登录时获取当前用户的可能性.

从我的研究中,我发现有两种可能的策略:

1.共享架构

在此策略中,身份验证应用程序是其中一项服务.但是每个服务必须能够进行转换session_id=> user_id所以它必须简单易行.这就是为什么我想到Redis,它会存储密钥:值session_id:user_id.

2.防火墙架构

在此策略中,会话存储并不重要,因为它仅由身份验证应用程序处理.然后user_id可以转发到其他服务.我想到了Rails + Devise(+ Redis或mem-cached,或cookie存储等),但有很多可能性.唯一重要的是Service X永远不需要对用户进行身份验证.

---

这两种解决方案如何比较:

• 安全
• 稳健性
• 可扩展性
• 便于使用

或者你可能会建议我在这里没有提到的另一种解决方案？

我更喜欢解决方案#1,但没有找到太多的默认实现,这可以保证我正朝着正确的方向前进.

我希望我的问题不会被关闭.我真的不知道还能在哪里问它.

提前致谢

Answer 1

根据我的理解,解决问题的一个好方法是使用OAuth 2协议(您可以在http://oauth.net/2/上找到有关它的更多信息)

当您的用户登录您的应用程序时,他们将获得一个令牌,使用此令牌,他们将能够发送到其他服务以在请求中识别它们.

链式微服务设计示例

资源:

• http://presos.dsyer.com/decks/microservice-security.html
• https://github.com/intridea/oauth2
• https://spring.io/guides/tutorials/spring-security-and-angular-js/

Answer 2

简短回答：使用基于 Oauth2.0 类令牌的身份验证，可用于任何类型的应用程序，如 web 应用程序或移动应用程序。Web 应用程序所涉及的步骤顺序是

1. 针对 ID 提供者进行身份验证
2. 将访问令牌保存在 cookie 中
3. 访问 webapp 中的页面
4. 调用服务

下图描述了需要的组件。这种将 web 和数据 api 分开的架构将提供良好的可扩展性、弹性和稳定性

Answer 3

您可以使用JWT令牌避免在后端存储会话信息。

以下是使用OAuth 2.0和OpenID Connect 的效果。我还将用户名和密码登录添加到答案中，因为我假设大多数人也将其添加为登录选项。

以下是建议的解决方案组件：

1. 帐户服务：负责用户创建和身份验证的微服务。可以有 Google、Facebook 和/或常规用户名和密码身份验证端点 - 登录、注册的端点。在注册时 - 意味着通过注册端点或首次登录 google/fb，我们可以将有关用户的信息存储在数据库中。用户使用任一选项成功登录后，我们在服务器端创建一个包含相关用户数据（例如 userID）的 JWT 令牌。为了避免篡改，我们使用我们定义的令牌秘密（这是一个字符串）对其进行签名。该令牌应作为 httpOnly cookie 与登录响应一起返回。为了安全起见，建议也仅使用 https。根据 OpenID 连接规范，此令牌将是 ID 令牌。

2. 客户端 Web 应用程序：以 httpOnly cookie 形式接收签名的 JWT，这意味着 JavaScript 代码无法访问此数据，从安全角度来看，建议使用此数据。当向服务器或其他微服务发送后续请求时，我们将 cookie 附加到请求中（在 axios 中，这意味着使用 withCredentials: true）。

3. 需要通过令牌对用户进行身份验证的微服务：这些服务验证 JWT 令牌的签名，并使用为签署令牌而提供的相同密钥来读取它。然后他们可以访问存储在令牌上的数据（例如用户 ID），并获取数据库以获取有关用户的其他信息，或者执行任何其他逻辑。注意 - 这不是用于授权，而是用于身份验证。为此，我们有刷新令牌和访问令牌，这超出了问题的范围。

我最近专门针对这个主题创建了一份详细指南，以防它对某人有所帮助：https ://www.aspecto.io/blog/microservices-authentication-strategies-theory-to-practice/