使用不透明的访问令牌会使我的服务器有状态吗?
Posted
技术标签:
【中文标题】使用不透明的访问令牌会使我的服务器有状态吗?【英文标题】:Does Using Opaque Access Tokens Make My Server Stateful? 【发布时间】:2019-12-30 23:35:26 【问题描述】:我试图在身份验证上下文中了解 RESTful API 中的无状态性。这是场景:
-
用户登录。
服务器验证用户名和密码,并生成一个不透明的访问令牌。它缓存了一些与这个token相关的信息——例如,过期时间、userId、这个token在过期之前是否被显式失效等等。
令牌被发送到客户端,客户端在以后的每个请求中都发送它。
列表项
菲尔丁的论文将无国籍定义为:
“...这样从客户端到服务器的每个请求都必须包含理解请求所需的所有信息,并且不能利用服务器上存储的任何上下文。因此会话状态完全保留在客户端上。”
在我的示例中,客户端在每个请求中都发送令牌,因此满足第一个条件。但是,我的服务器有一个与此会话关联的上下文,该上下文存储在会话缓存中。
这会使我的应用程序有状态吗?
如果是,那么是否只有使用 JWT 才能实现真正的无状态?我在思考这个问题,因为 JWT 还很新,那么架构师在它们被发明之前是如何构建真正的无状态服务的呢?
【问题讨论】:
【参考方案1】:没错。如果您维护会话,您将保持服务器中的状态,这使得应用程序难以扩展。真正的无状态应用程序可以横向扩展,任何服务器都应该能够处理请求。
JWT 是避免会话的流行方式,所有内容都封装在令牌中,任何服务器都可以对请求进行身份验证/授权并帮助我们实现无状态应用程序,它们有自己的挑战,但是 OpenID 连接是身份验证/授权的新方式.
在使用 jwt 使应用程序无状态之前,我们将会话保存在数据库(或共享缓存)中,任何服务器想要检查会话都必须联系数据库。
希望有帮助!
【讨论】:
你写的是真的。但这一切都与这个问题无关。你没有回答这个问题。 1)你在写关于规模能力的文章。但是作者没有问任何关于这个的字眼。 2)您正在将 JWT 与 OpenID 进行比较。但是作者没有问这个问题,也没有问过 OpenID 也没有问过 JWT 的任何其他替代方案。 3)您声明如果会话数据存储在“服务器内部。所以应用程序是无状态的”。这意味着你不明白什么是无状态的。 --> 你的回答完全误导。 感谢您的 cmets。第一行作者说他们想了解身份验证。所以我分享了关于无状态身份验证的一切。我没有看到我在哪里比较 JWT 和 open id ?如果您知道 open id,您就会知道 jwt 的相关性。我仍在寻找您的第 3 点,我在哪里提到将会话保存在服务器中使其无状态? 1) 作者只是向我们解释了上下文。他没有询问可扩展性。这就是为什么您的第一段无关紧要,删除它会很好。 2)是的,我对比较的评论不正确。这不是比较。然而,第 2 段无关紧要。 “JWT 是流行的方式”——作者没有问 JWT 的目的,因为他已经使用了它。 “是新的方式”——首先,它不是新的。其次,它与这个问题无关。如果您删除答案的第二段,这对这个问题会很有用。 3) “在此之前,我们将会话保存在数据库(或共享缓存)中,而不是在服务器内。” - 听起来您认为“用于在数据库中保持会话”是有状态的指标,而“相当在服务器内部”是无状态的指标。您的声明“所以应用程序是无状态的”在服务器内部进行。这意味着您说“在服务器内部-> 这就是它是无状态的”。如果你的意思是别的,请解释它与这个问题的关系。 我还关心防止数据库上的 CPU 负载。我相信 OP 的引用,特别是有向图“存储的上下文”,是 RDBMS 在这种情况下所扮演的角色。介词“on”在英语中是模棱两可的,但在依赖 DAG 中,依赖于 DB 的服务器合法地是“存储的上下文”。【参考方案2】:简而言之:不,令牌的这种使用不会使您的应用程序有状态。
详解:当我们谈到无状态/有状态时,我们通常只考虑影响业务逻辑的数据。业务逻辑通常不依赖于身份验证数据。例如,用户发送一个请求,其中包含下订单所需的所有数据。通常创建订单不取决于此用户何时登录、他的用户 ID 等。
【讨论】:
以上是关于使用不透明的访问令牌会使我的服务器有状态吗?的主要内容,如果未能解决你的问题,请参考以下文章
使用 RestSharp 返回“状态代码:未找到”获取 PayPal 访问令牌