微服务认证策略答案

【问题标题】：Microservice Authentication strategy微服务认证策略
【发布时间】：2015-06-21 02:24:39
【问题描述】：

我很难为微服务架构选择合适/安全的身份验证策略。我在该主题上找到的唯一 SO 帖子是这个：Single Sign-On in Microservice Architecture

我的想法是在每项服务（例如身份验证、消息传递、通知、配置文件等）中对每个用户都有一个唯一的引用（从逻辑上讲，然后是他的user_id）以及获取当前用户的@987654325 的可能性@如果已登录。

根据我的研究，我发现有两种可能的策略：

1。共享架构

在此策略中，身份验证应用程序是一项服务。但是每个服务都必须能够进行转换 session_id => user_id 所以它必须非常简单。这就是我想到 Redis 的原因，它可以存储 key:value session_id:user_id。

2。防火墙架构

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

这两种解决方案在以下方面的比较：

安全
鲁棒性
可扩展性
易于使用

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

我更喜欢解决方案 #1，但没有找到太多默认实现来确保我朝着正确的方向前进。

【问题讨论】：

您能否提供更多关于您要达到的目标的详细信息？在第一种情况下，身份验证是针对 Redis 进行的，还是在服务本身中进行的？第二张图中缺少Redis，这是故意的吗？
我添加了一些信息。请让我知道目前还不清楚。谢谢！
您有没有想过创建一个使用 OAuth 协议的微服务，而您的其他服务使用创建的令牌？
我对这个解决方案很好奇，但我仍然不明白它在实践中是如何工作的。你知道我在哪里可以找到它的一些标准实现吗？
@AugustinRiedinger，感谢您提出这个问题。我还采取了一些小步骤，将我的单体 Web 应用程序分解为微服务。在您的情况下，服务 1-n 是无状态的还是有状态的。如果它们是状态完整的，您是否考虑过在每个服务中管理会话。谢谢

标签： authentication architecture microservices

【解决方案1】：

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

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

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

Account-service： 负责用户创建和身份验证的微服务。可以有 Google、Facebook 和/或常规用户名和密码身份验证端点的端点 - 登录、注册。在注册时 - 意味着通过注册端点或第一次 google/fb 登录，我们可以将有关用户的信息存储在数据库中。在用户使用任一选项成功登录后，我们在服务器端创建一个包含相关用户数据（如 userID）的 JWT 令牌。为了避免篡改，我们使用我们定义的令牌秘密（这是一个字符串）对其进行签名。此令牌应与登录响应一起作为 httpOnly cookie 返回。出于安全考虑，建议也仅使用 https。根据 OpenID 连接规范，此令牌将是 ID 令牌。
客户端 Web 应用程序： 将签名的 JWT 作为 httpOnly cookie 接收，这意味着 javascript 代码无法访问此数据，从安全角度来看是推荐的。当向服务器或其他微服务发送后续请求时，我们将 cookie 附加到请求中（在 axios 中意味着使用 withCredentials: true）。
需要通过令牌对用户进行身份验证的微服务：这些服务验证 JWT 令牌的签名，并使用为令牌签名提供的相同密钥读取它。然后他们可以访问存储在令牌上的数据，例如用户 ID，并获取数据库以获取有关用户的其他信息，或者执行任何其他逻辑。注意 - 这不是用于授权，而是用于身份验证。为此，我们有刷新令牌和访问令牌，这超出了问题的范围。

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

【讨论】：

【解决方案2】：

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

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

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

【讨论】：

AWS Lambda 不会变“冷”，需要时间来启动吗？那会使登录变慢，不是吗？
@tsuz，AWS 现在在 lambda 中引入了并发功能，您可以在其中保留并发。有了这个，你可以解决冷启动问题。 docs.aws.amazon.com/lambda/latest/dg/…
我很想在几年前看到这个答案，它非常简单地理解了具有身份验证和授权独立微服务的微服务架构如何被编排以提供对其他服务的访问
@Sandeep，我认为您指的是预置并发而不是保留。

【解决方案3】：

您可以使用idenitty server 4 进行身份验证和授权

您必须使用防火墙架构，因此您可以更好地控制安全性、稳健性、可扩展性和易用性

【讨论】：

【解决方案4】：

据我了解，解决此问题的一个好方法是使用 OAuth 2 协议（您可以在 http://oauth.net/2/ 上找到更多相关信息）

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

链式微服务设计示例

资源：

【讨论】：

谢谢，这很清楚。我发现这篇非常好的文章分解了几乎相同的解决方案：dejanglozic.com/2014/10/07/…
您的回答很好，但是从 API 网关（从其内部或在 AuthMicroService 中）生成的令牌如何由随机微服务处理，其目的不是进行身份验证，并且可能在他的业务代码中没有 oauth 管理？
例如，您可以使用 Netflix Zuul 将网关中收到的令牌发送给所有服务，他们将知道用户信息。 docs.spring.io/spring-boot/docs/current/reference/htmlsingle/…
在服务之间使用 OAuth2 的另一个好处是您可以使用端点来区分服务身份验证和用户身份验证操作。
OAuth 更多的是授予系统访问另一个系统中保存的用户数据的权限。在我看来，这对于 SAML 来说是一个很好的案例。