停止使用JSON Web代币进行身份验证

• “由于可扩展性，JWTokens是被推荐的认证方法。”

• “JWTokens更易于使用。”

• “JWToken是无状态的，所以我们不需要使用服务器上的内存。”

我确信他们的意图是好的，但是他们共享了一种不安全的用户身份认证和授权用户的方式，至少对于web应用程序是这样的。

免责声明：我并不主张我们应该完全停止使用JWT或类似机制。然而，我看到许多教程为了简单起见，以糟糕的方式实现了它们。

我们当然可以安全地使用JWT代币，但是，我们可能不应该从头实现它们，因为广泛地保护它们会变得很复杂。

JWT通常实现的方式

让我们看一下使用JWT对用户进行身份验证的流程。

• 用户输入他们的用户名和密码——当用户单击登录按钮时，将向服务器发送一个请求，用数据库验证用户的凭据。

• 服务器成功地验证了用户的身份——服务器现在使用一个密码创建并签署一个JWT，并在响应中返回它。

教程通常将到期时间设置为一周到30天。

• 客户端在响应中接收JWT——开发人员(在像chrome这样的客户端中)接收它，应用一些逻辑，然后存储它，通常是在本地存储。

• 客户端使用存储在代币中的信息来有条件地渲染——通常，教程使用像用户的电子邮件、用户名和布尔字段，如isAdmin。

• 客户端将代币添加为每个请求的标头——如果代币存在于本地存储中，则用户的会话是活动的。

服务器现在可以通过解密每个请求的签名代币来检查用户的身份。

代币将一直有效到到期。

以这种方式使用JWT的所有问题。

响应包含JWT。

我们遇到的第一个危险信号是在响应中返回代币。因此，前端代码可以自由地读取和存储代币。

访问代币会使跨站点脚本攻击能够窃取用户的身份并代表他们发送请求。因为我们没有关于用户的会话信息，所以可能没有办法知道。

JWT在到期之前一直有效。

由于JWT认证是无状态的，一旦服务器签署了有效的代币，就没有办法撤销用户的会话。

因此，使用长到期窗口+不安全存储是黑客对我们的用户造成严重损害的完美组合。

撤销它们的唯一方法是更改签名密钥，这实际上将注销我们的整个用户群，因为所有代币都将呈现为无效。

从长远来看，本地存储不安全。

在本地存储中长时间存储内容是不安全的，因为任何人都可以在浏览器中访问它。

跨站点脚本可以从本地存储中检索代币，因为它没有加密或保护。

信息可能不同步。

这个问题不像其他问题那么严重。

存储像isAdmin、用户地址等字段可能本身并不安全，但这里有一个问题。

由于代币是无状态的，因此当信息发生变化时无法更新它们。因此，用户的用户名、电子邮件或权限可能与数据库中的实际值不同步。

允许跨域请求。

使用JWT，任何拥有代币的人都可以发送有效的请求。

恶意网站可以从虚假域名向我们的网站发送请求，浏览器将允许它。

我们可以通过使用CORS来降低这种风险。

何时(以及如何)正确地使用JWT

这些代币对于验证web应用程序来说并不安全，但这并不意味着它们是无用的。相反，有几个用例可以很好地处理这些代币。

使用JWT时：

• 到期窗口很小。(2小时)

• 请求不涉及将代币存储在浏览器中。

• 请求不需要加密。

一个真实的例子用例

最好的例子是控制对资源(如文件下载)的访问。

假设我们的用户一个月前购买了一款虚拟产品，想再次下载它。

我们会有一个开放的链接，使任何人都可以用来下载我们的虚拟产品吗?

JWT代币非常有用，因为我们可以创建短期访问代币来验证用户的身份，并临时授予对购买内容的访问权。

代币不会存储在任何地方，而且它会很快过期。因此，它允许我们轻松地处理可验证的交易。

如果我们曾经将第三方登录与谷歌或其他提供商集成过，那么这就是使用JWT的一个很好的例子。

服务器端会话

有状态会话意味着服务器将用户的会话存储在内存或数据库中。

尽管这需要进行一些权衡，但在实现时，它消除了前一种方法的大部分问题和安全问题。

然而，它确实带来了一些其他的挑战。这取决于我们的项目需求。

我们可以跟踪用户的会话活动(更容易)

使用有状态会话，我们可以存储有用的信息，如用户的IP地址、会话持续时间、上次请求的时间戳，并查看每个用户有多少活动会话。

服务器可以根据需要撤销会话。

在触发警告时(假设用户有三个来自不同国家的活动会话)，会话可以按需撤销，以防止被盗代币被使用——无需每30分钟等待一次到期。

HTTP-Only cookie更安全

没有方法可以100%安全抵御所有攻击。

我们必须将有状态会话代币(如UUID字符串)存储在HTTP-Only cookie中。

一个HTTP-Only cookie意味着cookie被自动附加到每个客户端请求，没有人可以访问浏览器中的代币，甚至我们自己也不行!

HTTP-Only Cookies默认情况下阻止跨站点请求

HTTP-Only cookie应该对跨站点请求有严格的设置。默认情况下，如果请求来自第三方域名，cookie将不起作用。

稍后我们将深入探讨这个问题。

会话在加密方面并不昂贵。

我们不必验证经过签名的JWT会话，因为代币可以映射到用户id，并存储在基于内存的数据库(如Redis)中，以便进行快速的访问和读取操作。

权衡

通常，无状态是首选的方法，因为它允许服务在没有任何依赖关系的情况下大量运行(状态)。

使用有状态会话确实给我们带来了一个潜在的新挑战。

CSRF攻击

使用cookie时，我们需要注意跨站点请求伪造攻击。

当将代币存储在本地存储时，这种类型的攻击是不可能的。然而，有两种主要的方法可以防止这种情况。

Cookie设置

在生产环境中，我们应该设置HTTP-only，并将Secure标志设置为true（如果请求不是 HTTPS，浏览器不会放置 cookie）。

对于CSRF攻击，应该将Same-Site标志设置为“strict”。

将此标志设置为strict可以确保只允许来自与服务器相同域的请求。

例如，如果第三方网站试图在CSRF攻击中使用用户的会话执行请求，则不会设置 auth cookie，因为攻击者的域与您的域不匹配。

Anti-CSRF 代币

要确保我们的API只使用Post Requests执行更改。

GET请求应该只检索数据。

这些类型的攻击欺骗用户点击链接，然后该链接使用用户的活动会话嵌入一个请求表单来更改用户数据，而不访问实际的身份验证代币。

使用Anti-CSRF代币可以确保服务器可以验证客户端发送的POST请求来自实际的网站。

服务器检查接收到的代币是否与最初发送给客户端的代币匹配。

可扩展性

JWT教程喜欢谈论他们的 Todo List React App需要如何扩展以服务于数百万活跃用户。

虽然这是一个合理的问题，也是一个不可思议的未来问题，但将可扩展性置于安全性之上是不好的。

只解决应用程序的即时需求，而可扩展性可能不是其中之一。一台服务器可以服务成百上千的用户。

提供可扩展性

在本文结束时，我不能不提到可扩展性可能成为服务器端会话的一个问题。

如果可扩展性是应用程序的一个关注点，其实不必担心：我们很快就会修好。

需要注意的是，使用集群会产生额外的成本，但根据工作负载，这些成本不应该太高。一定要使用Redis的AWS计算器来进行估算，并决定服务器端会话对我们的项目来说是否是个好主意。

使我们的有状态会话处于“无状态”

如果应用程序不需要在其运行的同一个实例中存储任何状态，那么它就是无状态的。

如果数据库与应用程序运行在相同的服务器实例中，那么它就不是无状态的。

但是，如果我们独立于服务器实例运行数据库，则服务器是无状态的，因为它的唯一目的是处理业务逻辑。

存储数据是数据库关心的问题。

将会话存储在基于内存的数据库中

我们的服务器应该为每一个经过身份验证的请求要求会话数据。出于这个原因，我们想要优化读和写的操作。

使用我们的常规SQL或NoSQL数据库将非常费力，并可能导致高成本和速度放缓。

使用Redis

Redis是一个内存(键，值)对数据库，允许快速读写访问。

例如，AWS提供Redis集群，确保我们的操作通过自动扩展组保持可扩展性。

服务器端会话工作流

最后，让我们回顾一下使用有状态会话的工作流程，就像不久前使用JWT时一样。

用户输入他们的用户名和密码。

当用户单击登录按钮时，向服务器发送一个请求，使用数据库验证用户的凭据。

服务器认证用户成功。

服务器创建一个代币(UUID)，将其映射到用户的数据库ID，并将其存储在Redis中。

服务器将Cookie附加到发送给浏览器的HTTP响应上。

客户端检查代币是否有效。

仅仅在标头中有一个HTTP-Only cookie并不意味着会话是处于活动状态。

浏览器向处理用户会话数据的服务器端点发送一个GET请求。因为Cookie向服务器提供了这个信息，所以这个请求不需要参数。

前端现在可以在应用程序中存储会话数据，而无需保留实际的代币。

客户端使用存储在代币中的信息有条件地渲染

通常，教程使用像用户的电子邮件，用户名等字段。这一次，信息通常是最新的，因为客户每次刷新网站时，信息都会更新。

HTTP-Only Cookie在每次请求时会自动发送

代币将一直有效到到期。但是，服务器可以根据需要撤销它。

接下来是什么？

我们应该知道，没有什么解决方案是万全之策，总会有权衡，也没有一种方法是100%安全的。漏洞总是存在的。但是，我们应该确保为我们的方法提供最好的安全性。

本文介绍了JWT及其作为web认证解决方案的缺点。然后我们找到了一种更好的(安全的)方法来实现我们的web应用程序的认证。

不过，我展示了一个使用有状态会话的简单实现。我们可能会想，到期怎么办?即使是一个星期也可能是一个很长的期限。

刷新代币

刷新代币并不是为了让事情变得简单，但是这里有一个大概的想法。

我们有两个代币:验证代币(用于验证我们的身份)和刷新代币。

身份验证代币可以是短暂的，例如，1-2天。当用户正在积极地使用他们的会话时，浏览器将不断地检查，以查看认证代币是否即将到期。当它检测到这一点时，它使用具有较长的到期时间的刷新代币，在前一个认证代币过期之前请求一个新的身份验证代币。

Long-Lived刷新代币引入了新的问题和复杂性，比如代币轮换和代币重用检查。

如果我们仍然想使用无状态会话，有些白费力气

像AWS Cognito或Firebase这样的库使用无状态代币，并将它们存储在本地存储中。

如果我们仍然希望使用无状态会话，请确保使用经过良好测试的、功能完整的库来为我们处理安全性。

这些库使用短期代币，不断刷新它们，并提供代币刷新轮换，以防止安全问题。

Source：https://medium.com/better-programming/stop-using-json-web-代币s-for-authentication-use-stateful-sessions-instead-c0a803931a5d