security - JWT 是用户身份验证的安全选项吗？

Question

我喜欢 JWT 的简单性，只是在为 Web 应用程序实现身份验证机制时使用它们，其中我有一个 Elixir/Phoenix 后端，提供 RESTful JSON API 和一个 Angular 2 前端。

今天无意中发现this文章(我与本网站没有任何关联)，它让我对 JWT 的使用产生了一些疑问，我想讨论一下。主要是:

在不关闭的情况下，没有真正的 JWT 失效方式
整个系统。至少当他们是无国籍的。

这意味着您无法撤销访问权限，这可能非常糟糕。

LocalStorage - JWT 主要存储在前端的地方 - 不如 session 存储安全。

Local storage, unlike cookies, doesn’t send the contents of your data store with every single request. The only way to retrieve data out of local storage is by using JavaScript, which means any attacker supplied JavaScript that passes the Content Security Policy can access and exfiltrate it. Not only that, but JavaScript also doesn’t care or track whether or not the data is sent over HTTPS. As far as JavaScript is concerned, it’s just data and the browser will operate on it like it would any other data.

After all the trouble those engineers went through to make sure nobody is going to make off with our cookie jar, here we are trying to ignore all the fancy tricks they’ve given us. That seems a little backwards to me.

到目前为止，我认为他的观点是无效的——只要一个人通过 https 提供一切服务并防止 XSS 和 CORS 攻击。我的意思是如果恶意 JS 可以在网站上执行，这真的不是 JWT 的问题。并且 JS 不允许混合内容(http 和 https)。

使所有 token 无效:只需使用 JWT 代号变量之类的东西，它可以存在于您的环境变量中并在每个 token 中进行编码。它是一个简单的整数。如果要使所有 token 无效，请增加它。然后你只需要一个机制来检查代号是否匹配。这不一定会影响数据库，也不应该是性能问题。并且使用可靠的部署策略在多个实例上推出它应该不会太难。

对于使单个 token 无效:使用刷新 token 和 JWT 的非常短的生命周期(几分钟)。如果 JWT 的 TTL 即将结束，则用户通过刷新 token 获取新的 TTL。这意味着每隔几分钟就会命中一次数据库。

还是我错了？

Answer 1

LocalStorage - where JWTs are mostly stored on the front-end side - is not as secure as Session Storage.

您始终可以将 JWT 存储在 HttpOnly cookies 内，这将降低它们被任何 XSS 漏洞窃取的风险。

当然，所有其他常用的最佳实践都适用——安全标志、HSTS 等。

For invalidating all tokens: Just use something like a JWT generation-number variable, that could live in your environment variables and is encoded in every token

是的，您可以这样做，甚至可以完全生成新的 secret 。

For invalidating a single token: Use refresh tokens and a very short lifespan for a JWT (couple of minutes). If the TTL of the JWT is almost over, the user get's a new one via the refresh token. This means a DB hit every couple of minutes.

所以我假设这意味着对您的刷新 token 使用传统的服务器端 session 状态机制？这似乎是一种有效的方法。尽管使用安全算法(例如 SHA-2 - 不需要盐)，确保 session token 在服务器端散列。

唯一棘手的部分是从客户端到服务器的时钟同步。如果您很快将它们过期，那么任何小的时钟差异都可能使客户端感到困惑，并且他们不会及时请求刷新 token 。这使事情变得更加复杂，而复杂性是安全性的主要敌人。

如果您的 token 到期如此之快，那么使用传统的服务器端 session 管理机制可能更有意义。