JWT不应该是您的默认会话

在设计Web应用程序时，（尤其是传统的HTML类型），您将在一个点省略如何弄清楚如何在请求之间记录用户并保持在POSTION。

我们使用的核心机制是饼干。 cookie是将服务器发送到客户端的小字符串。在客户端收到此字符串之后，它将在后续请求中重复。我们可以将“用户ID”存储在Cookie中，并为任何将来的请求都知道，我们会知道客户端的user_id。

但这是非常不安全的。信息生活在浏览器中，介绍者可以更改user_id并被标识为其他用户。

解决这一问题的传统方式是所谓的“会话”。我不知道会话最早使用是什么，但它是在每个网络框架中，并且已经是Web框架是一件事。

通常，会话和饼干被描述为2种不同的东西，但是真的不是。会话需要饼干工作。

而不是预测的用户ID，我们正在向客户端发送完全随机源ID，这是不可能猜到的。 ID没有进一步的意义，anddoes没有解码到任何内容。这有时被称为不透明的令牌。

当客户端重复此会话ID后退到服务器时，服务器将查找（例如）数据库中的ID，该数据库将其链接回用户ID。当用户想要注销时，会话ID从中删除会话ID数据存储，这意味着cookie不再与用户关联。

PHP这样的语言具有内置的存储系统，并且将在本地文件系统中的DefaultBy Default Store数据中的存储系统。在Node.js生态系统中，bydefault此数据将处于“存储器”中，并在服务器重新启动后消失。

这些方法对开发人员机器进行了意义，或者当网站是Hostedon长期裸机服务器时，但这些日子通常均可完全鲜明的“系统”，因此需要存储在服务器中的PlaceThat中的信息。一个简单的选择是数据库，但使用Redis和Memcached等系统使用的系统很常见，这适用于Tiny网站，但是在大规模尺度上工作。

10多年前，我开始使用OAuth v1和类似的特朗尼主系统工作了更多的工作，我想知道我们是否只能将所有的所有信息存储在cookie中并加上加密签署它：

尽管获得了一些好的答案，但我并没有通过它，因为我没有足够的自信，在制作这个安全方面，我觉得它需要在加密比我所做的更好的地方。

几年后，我们得到了JWT，它是热辣的狗屎！ JWT本身是一个标准的forencrypting /签名的json对象，它使用了很多用于身份验证。在cookie中的不透明令牌中，我们实际上会再次嵌入user_id，但我们包含签名。签名只能由服务器生成，并且它使用“秘密”和cookie中的实际数据计算。

这意味着如果数据被篡改（User_ID已更改），则Thesignature不再匹配。

那么为什么这是有用的？我为此获得的最佳答案是，它没有与redis或数据库一样的会话数据系统。所有本信息都包含在JWT中，这意味着您的基础架构是简单的。您可能会根据每个请求的数据存储较少的呼叫较少。

首先，它是一个复杂的标准，用户容易获得SetterningWrong。如果设置错误，则在最坏的情况下，它可能意味着Anyonecan会生成有效的JWT，并模拟其他任何人。这不是abeginers级问题，也是去年的验证在其中一个产品中有一个错误的错误。

auth0是（或是？他们刚收购）安全产品的主要供应商，以及讽刺地赞助JWT.IO网站。如果他们不安全，那么普通（开发商）公众有什么？

然而，这个问题是许多安全专家不喜欢JWT的较大原因的一部分：它具有大量的特征和一个非常大的范围，这将其成为潜在错误的大型表面积，由图书馆遗传或这些库的用户来说。 （存在替代无国籍标记为JWT存在，其中一些人确实解决了这个问题。）

第二个问题是'注销'。使用传统的会话，您可以从您的会话存储中获取会话令牌，从而有效地为“无效”会话。

使用JWT和其他无状态令牌，这是不可能的。我们不能删除令牌，因为它是独立的，而且没有中央权威，那个人无效。

令牌非常短暂。例如，5分钟。在5分钟结束之前，我们会生成一个新的。 （通常使用单独的刷新）。

没有服务器驱动的注销，假设是客户员删除自己的令牌。

良好的系统通常将使用前两个。要点出口的重要事项，为了支持注销，您仍可能需要一个集中式商店（用于刷新令牌，撤销列表或两者），这是JWT应该“解决”的一员。

Sidenote：有些人喜欢JWT，因为每次请求的系统较少，但能够在他们过期之前撤销令牌的矛盾。

我最喜欢的解决方案是保留在他们过期之前已经过的JWTS的全局列表（并在到期后删除令牌）。而是让WebServers命中服务器获取此列表，使用Pub / sub机制将列表推向每个Server。

撤销令牌对安全性很重要，但罕见。现实地，这份列表很小，很容易适合内存。这在很大程度上解决了thelovout问题。

JWT的最后一个问题是它们比较大，并且当使用的仪式时，它会增加大量的每个请求的开销。

总而言之，这只是为了避免中央会话库的大量缺点。这不是我看来，JWT普遍是一个坏主意或勒出者，但有很多需要考虑。

在阅读科技博客时，有一件事让我感到惊讶，这就是JWT围绕着很多喋喋不休。特别是在媒体和子资金，如/ R /节点，我以极定的基础将intris到JWT。

我意识到这并不意味着'JWTS更受欢迎的Thanssion令牌'，因为GraphQL并不是比关系数据库更受欢迎，或者NoSQL：它不是一个有趣的关于已经尝试的技术和经过十年或更多的测试（参见：上诉到新奇）。此外，撰写新解决方案的主题专家可能会产生不同的问题＆amp;尺寸大多数自己的读者。

然而，这些新技术比他们的SimplerCounterparts创造了更多的嗡嗡声，如果足够的人一直在谈论热门的东西，最终这可以转化为实际的采用，尽管它是大多数简单用例的Asub最佳选择。

这类似于许多较新的开发人员，学习如何在服务器呈现的HTML之前构建SPAS。经验丰富的Devs可能会觉得SERVER呈现的HTML可能是您需要的默认选择，并且在需要时构建SPA，但这不是新的开发人员通常是什么样的。

在简单的选择之前采用复杂的系统被认为是ISSOMething，我看到发生更多，但它让JWT感到惊讶。

作为一项练习，我抬起最受欢迎的最受欢迎（by票）邮政信/ r / node提及jwt。我打算超过前100岁，但在前12名之后得出了。

1提到使用撤销列表，3提到REFESH令牌。剩余的文章和Github存储库根本没有忘记。

大部分帖子使用周或几个月的到期时间，3帖尼维斯省的JWTS。

除了1，这些高度上升的帖子的质量极低，散步可能没有资格写下这一点，并可能潜在危害。

所有这一切至少证实了我的偏见，即安全令牌的JWT很难。

经过大量的红线帖子和评论也让我更加澄清了为什么人们认为JWTS更好。到处都是：“它更加可扩展”，但它在思考的思想开始有问题时不明显。我相信问题开始表现的观点可能远远高于假设。

我们大多数人不是Facebook，但即使在“数百万积极的会议”中，AdistRibed Key-和GT;价值商店不太可能扣。

统计上，我们大多数人都在建立不会使AraSpberry Pi打破汗水的应用程序。

使用JWTS for令牌添加一些简洁的属性，并在某个时期使您的服务成为无状态，这可能是可取的属性Insome架构。

采用它们附带缺点。您要么放弃撤销，或者您要拥有基础架构，以便更加复杂的方式只是采用会话商店和不透明令牌。

我的观点在这一切都不是为了劝阻JWT的使用，而是在你做的时候刻意和小心。 了解安全和功能权衡和陷阱。 将其留出您的'Booterplates'and模板，并不使其成为默认选择。