微服务认证策略

Question

我很难为微服务架构选择一个体面的/安全的身份验证策略。我在这个主题上找到的唯一的SO帖子是这样的：微服务架构中的单点登录

在这里，我的想法是在每个服务（例如身份验证、消息传递、通知、配置文件等）中都有一个对每个用户的唯一引用（从逻辑上讲，然后是他的user_ID)，并且如果登录，可以获得当前用户的ID。

从我的研究中，我看到有两种可能的策略：

null

Answer 1

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

下面是使用OAuth2.0&OpenID Connect的样子。我还在答案中添加了用户名和密码登录，因为我假设大多数人也将其作为登录选项添加。

>

Account-Service:负责用户创建和身份验证的微服务。可以有endpoint为谷歌，脸书和/或常规用户名和密码认证endpoint-登录，注册。通过注册endpoint或首次Google/FB登录，我们可以在数据库中存储有关用户的信息。在用户使用这两个选项成功登录后，我们在服务器端创建一个带有相关用户数据的JWT令牌，比如userid。为了避免篡改，我们使用我们定义的令牌秘密（即字符串）对其进行签名。这个令牌应该作为httpOnly cookie与登录响应一起返回。为了安全起见，建议使用https。对于OpenID connect规范，此令牌将是ID令牌。

客户端web应用程序：将经过签名的JWT作为httpOnly cookie接收，这意味着javascript代码无法访问该数据，从安全的角度来看，这是推荐的。当向服务器或其他微服务发送后续请求时，我们将cookie附加到请求（在axios中，它意味着使用With Credentials：true）。

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

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