我喜欢JWT的简单性，只是在为Web应用程序实现身份验证机制时使用它们，我有一个Elixir / Phoenix后端，提供RESTful JSON API和Angular 2前端。
今天我偶然发现了this文章（我与这个网站没有任何关系），这让我对JWT的使用产生了一些疑问，我想讨论一下。主要是：
与Cookie不同，本地存储不会发送您的数据内容 存储每个请求。检索数据的唯一方法 本地存储是使用JavaScript，这意味着任何攻击者 提供的传递内容安全策略的JavaScript可以访问 并渗透它。不仅如此，JavaScript还不关心或 跟踪数据是否通过HTTPS发送。至于JavaScript 我担心的是，它只是数据而浏览器会像它一样运行 它会有任何其他数据。
在经历了所有麻烦之后，这些工程师一直在努力确保无人问津 我们将试图忽略我们的饼干罐 所有他们给我们的花哨技巧。这看起来有点倒退 对我来说。
到目前为止，我认为他的观点无效 - 只要通过https服务一切并防止XSS和CORS攻击。我的意思是如果恶意JS可以在网站上执行，这实际上不是JWT的问题。 JS不允许混合内容（http和https）。
使所有令牌无效：只需使用JWT生成数字变量，它可以存在于您的环境变量中，并在每个令牌中编码。这是一个简单的整数。如果要使所有令牌无效，请将其递增。然后你只需要一种机制来检查世代号是否匹配。这不一定是数据库，不应该是性能问题。使用可靠的部署策略在多个实例上进行推广应该不会太困难。
使单个令牌无效：使用刷新令牌和JWT的短暂生命周期（几分钟）。如果JWT的TTL几乎结束，则用户通过刷新令牌获得新的TTL。这意味着数据库每隔几分钟命中一次。
或者我错了？
答案 0 :(得分：5)
LocalStorage-- JWT主要存储在前端 - 是 不如会话存储安全。
您可以随时将JWT存储在HttpOnly cookies内，这样可以降低因任何XSS漏洞而被盗的风险。
当然，所有其他常用的最佳实践都适用 - 安全标志，HSTS等。
使所有令牌无效：只需使用类似JWT的东西 生成数字变量，可以存在于您的环境中 变量并在每个令牌中编码
是的，你可以做到这一点，甚至完全产生新的秘密。
使单个令牌无效：使用刷新令牌和JWT的使用寿命非常短 （几分钟）。如果JWT的TTL几乎结束，那么用户 通过刷新令牌获取一个新的。这意味着数据库命中每一个 几分钟。
所以我假设这意味着为您的refesh-tokens使用传统的服务器端会话状态机制？这似乎是一种有效的方法。尽管使用安全算法（例如SHA-2 - 不需要盐），确保会话令牌在服务器端进行哈希处理。
唯一棘手的部分是从客户端到服务器的时钟同步。如果您快速到期，那么任何小的时钟差异都可能使客户端感到困惑，他们也不会及时请求刷新令牌。这使事情变得更加复杂，复杂性是安全的主要敌人。
如果您的代币过期，那么使用传统的服务器端会话管理机制可能会更有意义。