jwt同一会话_在会话中使用JWT

jwt同一会话

这个话题已经在黑客新闻，reddit和博客上讨论了很多次。 共识是–请勿使用JWT（用于用户会话）。

而且我在很大程度上同意对JWT的典型论点 ， 典型的“但我可以使其工作……”的解释以及JWT标准的缺陷的批评 。 。

我不会在这里重复所有内容，因此请阅读这些文章。 您真的可以使用JWT付诸实践，了解它很复杂，并且对于大多数用例来说几乎没有好处。 我猜对于API调用是有意义的，特别是如果您在单页应用程序中为RESTful客户端重用相同的API，那么我将重点讨论用户会话用例。

受到所有这些批评之后，我违背了以上文章的建议，使用了JWT，浏览了他们的论点并声称我处于最佳状态。 我很可能是错的。

我将用户ID存储在作为cookie存储的JWT令牌中。 不是本地存储，因为这是有问题的。 不是整个状态，因为我不需要那可能导致问题（在链接的文章中指出）。

我想避免在设置中跨节点共享会话。 这是不使用Web服务器/框架的会话机制的一个非常令人信服的原因。 不，您不需要拥有数百万的用户即可要求您的应用程序在多个节点上运行。 实际上，它几乎应该始终在（至少）两个节点上运行，因为节点会死掉并且您不希望停机。 负载平衡器上的粘性会话是解决该问题的一种方法，但是您只是将集中的会话存储外包给了负载平衡器（有些负载平衡器可能不支持它）。 共享的会话缓存（例如memcached，elasticache，hazelcast）也是一种选择，许多Web服务器（至少在Java中）支持可插拔的会话复制机制，但这为架构引入了另一个组件，要支持的堆栈的另一部分，以及可能会破裂。 它不一定很坏，但是如果有一种简单的方法可以避免它，那我就去做。

为了避免共享会话存储，您需要在请求/响应周期中传递整个会话状态（如cookie，请求参数，标头），或者需要接收userId并从数据库或缓存中加载用户。 据我们了解，前者可能是一个错误的选择。 尽管有诸如ASP.NET和JSF之类的框架将整个状态转储到页面HTML内的事实，但这在直观上听起来并不好。

对于后者–您可能会说：“好吧，如果您打算在每个请求中从数据库中加载用户，这将会很慢，并且如果您使用缓存，那么为什么不对会话本身使用缓存呢？” 。 好吧，缓存可以是本地的。 记住，我们只有几个应用程序节点。 每个节点可以为当前活动的用户提供一个本地内存缓存。 所有节点都将加载相同的用户（在负载均衡器以循环方式将一些请求路由到它们之后）的事实并不重要，因为该缓存很小。 但是您不必在节点之间复制它，也不必照顾从群集传来的新节点，处理节点之间的网络问题，等等。每个应用程序节点都是孤岛。应用程序节点。

因此，这是我对链接文章的第一个反对意见–仅将用户标识符存储在JWT令牌中并不是没有意义的，因为它使您免于会话复制。

对JWT标准及其加密的安全性的批评又如何呢？ 完全正确，很容易用脚射击。 这就是为什么我仅将JWT与MAC一起使用，并且仅将其与接收令牌时经过验证的特定算法一起使用的原因，因此（据称）避免了所有陷阱。 公平地说，我愿意使用其中一篇文章中提出的替代方案PASETO ，但是它没有Java库，实现它需要花费一些时间（将来可能会这样做）。 总结一下-如果存在另一种易于使用的经过身份验证的cookie加密方法，我会使用它。

所以我基本上是在“ PASETO模式”下使用JWT，它只有一种操作和一种算法。 作为一般方法，这应该没问题–本文不批评在令牌（和无状态应用程序节点）中包含用户标识符的想法，而是批评标准的复杂性和脆弱性。 这是我的第二个反对意见–“不使用JWT”被广泛理解为“不使用令牌”，而事实并非如此。

在为简化体系结构和缺乏共享状态而进行的努力中，是否引入了一些漏洞？ 我希望不是。

翻译自: https://www.javacodegeeks.com/2018/03/using-jwt-sessions.html

jwt同一会话