我正在研究云服务身份验证系统,我不完全确定处理身份验证请求的最佳方式是什么。我们计划将我们的图像服务器作为与API服务器分开的进程运行,以便我们可以相互独立地扩展它们。使用API密钥处理请求身份验证非常简单,因为我们可以让映像服务器存储自己的API密钥并检查请求是否在标头中提供(显然通过HTTPS),与API服务器相同。对于用户而言,它变得更加复杂。
现在我们设置它以便API服务器处理生成会话令牌并将用户存储在其数据库中,但我们想要做的是使用3台服务器:
让映像和API服务器对身份验证服务器进行身份验证请求。究竟应该怎么做呢?对于API和映像服务器发出的每个请求,都要在性能方面达到性能。可以/应该从与其创建的服务器不同的服务器验证令牌吗?
例如:可以/我应该将从验证服务器收到的令牌传递给映像服务器,验证令牌来自“my.auth.server”并检查用户ID是否正确? JWT会成为一种很好的代币吗?
答案 0 :(得分:3)
这是另一种方法。
您的身份验证会发出一个 JWT 令牌,该令牌使用一个秘密在您的 API 和服务器映像中也可用进行签名。他们也需要在那里的原因是你需要验证收到的令牌以确保你创建了它们。 JWT 的好处在于,如果不同的用户具有不同的访问控制级别,它们的负载可以声明用户有权访问的内容。
该架构使身份验证无状态:无需在数据库中存储任何令牌,除非您想处理令牌黑名单(想想禁止用户)。如果您需要扩展,无状态是至关重要的。这也使您的 API 和图像服务器无需调用身份验证服务器,因为身份验证和授权所需的所有信息都在已发布的令牌中。
流程(无刷新令牌):
这里有几个问题。也就是说,错误使用的身份验证令牌为恶意用户提供了无限制的访问权限,以假装他们是受影响的用户并无限期地调用您的 API。为了解决这个问题,令牌有一个到期日,每当到期时,客户都被迫请求新的令牌。该到期时间是令牌有效载荷的一部分。但是如果令牌是短暂的,我们是否要求用户每次都使用他们的用户名和密码进行身份验证?不。我们不想每 30 分钟到一个小时询问用户密码,并且我们不想在客户端的任何地方保留该密码。为了解决这个问题,我们引入了刷新令牌的概念。它们是寿命更长的令牌,用于一个目的:充当用户的密码,对它们进行身份验证以获取新令牌。缺点是使用这种架构时,您的身份验证服务器需要将这些刷新令牌保存在数据库中。
新流程(带有刷新令牌):
可选(禁止用户)
我们如何禁止用户?使用该模型没有简单的方法可以做到这一点。增强功能:每个持久刷新令牌都包含一个黑名单字段,并且仅在刷新令牌未列入黑名单时才发布新令牌。
需要考虑的事项:
答案 1 :(得分:0)