为用户和API单独设置身份验证服务器

时间:2016-09-07 17:21:11

标签: api security authentication

我正在研究云服务身份验证系统,我不完全确定处理身份验证请求的最佳方式是什么。我们计划将我们的图像服务器作为与API服务器分开的进程运行,以便我们可以相互独立地扩展它们。使用API​​密钥处理请求身份验证非常简单,因为我们可以让映像服务器存储自己的API密钥并检查请求是否在标头中提供(显然通过HTTPS),与API服务器相同。对于用户而言,它变得更加复杂。

现在我们设置它以便API服务器处理生成会话令牌并将用户存储在其数据库中,但我们想要做的是使用3台服务器:

  • 认证服务器
  • API服务器
  • 图片服务器

让映像和API服务器对身份验证服务器进行身份验证请求。究竟应该怎么做呢?对于API和映像服务器发出的每个请求,都要在性能方面达到性能。可以/应该从与其创建的服务器不同的服务器验证令牌吗?

例如:可以/我应该将从验证服务器收到的令牌传递给映像服务器,验证令牌来自“my.auth.server”并检查用户ID是否正确? JWT会成为一种很好的代币吗?

2 个答案:

答案 0 :(得分:3)

这是另一种方法。

您的身份验证会发出一个 JWT 令牌,该令牌使用一个秘密在您的 API 和服务器映像中也可用进行签名。他们也需要在那里的原因是你需要验证收到的令牌以确保你创建了它们。 JWT 的好处在于,如果不同的用户具有不同的访问控制级别,它们的负载可以声明用户有权访问的内容。

该架构使身份验证无状态:无需在数据库中存储任何令牌,除非您想处理令牌黑名单(想想禁止用户)。如果您需要扩展,无状态是至关重要的。这也使您的 API 和图像服务器无需调用身份验证服务器,因为身份验证和授权所需的所有信息都在已发布的令牌中。

流程(无刷新令牌):

  1. 用户通过身份验证服务器进行身份验证(例如:POST /auth/login)并接收由身份验证服务器生成和签名的 JWT 令牌。
  2. 用户使用该令牌与您的 API 和图像服务器通信并假设用户已获得授权)、获取并发布必要的资源。

这里有几个问题。也就是说,错误使用的身份验证令牌为恶意用户提供了无限制的访问权限,以假装他们是受影响的用户并无限期地调用您的 API。为了解决这个问题,令牌有一个到期日,每当到期时,客户都被迫请求新的令牌。该到期时间是令牌有效载荷的一部分。但是如果令牌是短暂的,我们是否要求用户每次都使用他们的用户名和密码进行身份验证?不。我们不想每 30 分钟到一个小时询问用户密码,并且我们不想在客户端的任何地方保留该密码。为了解决这个问题,我们引入了刷新令牌的概念。它们是寿命更长的令牌,用于一个目的:充当用户的密码,对它们进行身份验证以获取新令牌。缺点是使用这种架构时,您的身份验证服务器需要将这些刷新令牌保存在数据库中。

新流程(带有刷新令牌):

  1. 用户通过身份验证服务器进行身份验证(例如:POST /auth/login)并接收由身份验证服务器生成和签名的 JWT 令牌,以及他们安全存储的长期(例如:6 个月)刷新令牌
  2. 每当用户需要发出 API 请求时,都会检查令牌的到期时间。假设它尚未过期,用户使用该令牌与您的 API 和图像服务器通信并假设用户已获得授权),获取并发布必要的资源。
  3. 如果令牌确实已过期,则需要刷新您的令牌,用户调用身份验证服务器(例如:POST / auth/token)并传递安全存储的刷新令牌。响应是发布的新访问令牌。
  4. 使用该新令牌与您的 API 图像服务器通信。

可选(禁止用户)

我们如何禁止用户?使用该模型没有简单的方法可以做到这一点。增强功能:每个持久刷新令牌都包含一个黑名单字段,并且仅在刷新令牌未列入黑名单时才发布新令牌。

需要考虑的事项:

  • 您可能想要轮换刷新令牌。为此,每次您的用户需要新的访问令牌时,将刷新令牌列入黑名单。这样刷新令牌只能使用一次。不利的一面是,您最终会获得更多刷新令牌,但可以通过清除列入黑名单的刷新令牌(例如:每天一次)轻松解决这一问题
  • 您可能需要考虑设置每个用户允许发出的最大刷新令牌数(例如 10 或 20 个),因为您每次登录时都会发出一个新令牌(使用用户名和密码)。该数字取决于您的流量、用户可能使用的客户端数量(网络、移动设备等)以及其他因素。

答案 1 :(得分:0)

最佳使用方法之一是JWT令牌,您可以在所有服务器之间生成并共享它,并在服务器端对其进行验证。

https://jwt.io

我还认为,在这种情况下使用的最佳架构是微服务架构