安全与隐私paragonie.com
应当避免使用 JSON Web Token（JWT）
JSON Web Tokens should be avoided
2017 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章批评 JSON Web Token（JWT）及其背后的 JOSE 标准：作者认为它过于复杂、默认不安全，算法协商和库实现容易导致漏洞，而且问题不只出在个别库的实现 bug 上。文章主张避免使用 JWT，转向更简单、更难被误用的令牌方案（评论提到作者后来设计了 PASETO）。
为什么经久不衰：JWT 至今仍被广泛使用，而文中指出的标准设计与默认值问题反复以新漏洞形式出现，因此这篇批评多年后仍是讨论认证方案时的经典参考。
HN 评论精选
批评者常不提供替代方案；在 SPA/REST 场景下，无状态客户端令牌仍有实际价值。
对 JWT 的批评大致分两类：一是具体 JWT 库的漏洞（如本文）；二是泛泛批评任何“无状态”客户端令牌，因为很难在保持无状态的同时提前撤销。问题是这两类都只批评，似乎从不推荐替代方案。我本人并不执着于 JWT：完全可以用别的机制实现类似模式（认证后存安全 Cookie，不做刷新，到期即失效，只在万不得已时用笨拙的撤销策略）。若提供 REST API，我更喜欢把令牌字符串放在请求头里，而不是强制用 Cookie（虽然 Cookie 也只是请求头）。但给 JS 前端提供 REST API 时，服务端 session 状态绝不是好选择：要么负载均衡配置粘性会话，要么在各实例间共享会话状态（从来不太可靠），而且依赖 session 本身也不够 RESTful。所以 2017 年写 SPA 时，我肯定会选客户端方案，也就撞上第二类批评。
StevePerkins查看英文原文
The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any alternatives. I could care less about JWT per se. I'm happy to implement a similar pattern with something else (e.g. store a secure cookie post-auth, skip all the refresh business and just let it expire when it expires, and employ an ugly revocation strategy only if absolutely necessary). I don't need JWT for this. If I'm providing a REST API, then I'd prefer a token string that I could pass as a header value rather than forcing the use of cookies. Although I suppose you could argue that a cookie is just another header value. Either way, if you're serving up a REST API to a JavaScript UI... what's NOT a good option is server-side session state (e.g. Java servlet sessions). That requires you to either: configure your load balancer for sticky-sessions, or employ a solution to share session state across all your server-side instances (which never works very reliably). Moreover, relying on a session isn't a very RESTful auth strategy in the first place. So if I'm writing a SPA in 2017, then I'm definitely taking a client-side approach and running afoul of the #2 critics. And since JWT is so widely implemented (e.g. if I use a "Login with Google" option then I'm using JWT), I'm probably running afoul of the #1 critics too. These criticism are fine, I guess. There's no faster route to blog clicks, book sales, speaker invites, and consulting dollars than: (1) telling everyone to jump on this year's hype train, or (2) telling everyone that last year's hype train sucks. What the world really needs is a bit more actual prescriptive recommendations of what to do instead.
文章把误用和实现错误归咎于标准，论证难以成立。
我看不到文中有什么有效论证。提出的问题要么是实现错误，要么是误用。全文无非是在说“JWT 可能被这样误用，导致应用不安全；标准和库都防不住，所以它很糟”。可什么时候有过技术能成功阻止人们犯傻？
akfish查看英文原文
I don't see any valid arguments in the post. The issues raised are either mis-implementation or misuse of JWT. All I am getting is "JWT can be misused in such such way that makes your application vulnerable. And neither its standards nor libraries prevent that, so it sucks". But when is the last time we see any technology successfully prevented people from being silly?
问题在标准/RFC 层面，而非个别库的漏洞。
很多人都在谈“none”算法问题，但更近的漏洞更能说明问题：提交给工作组邮件列表的报告指出，RFC 里虽有“安全考虑”章节，这个具体问题却从未被覆盖。现在麻烦在于，人们会多年引用这份 RFC，却无法更新它。这不像一两个库的漏洞——几乎所有实现都犯了同样的错误，这说明问题更深。
technion查看英文原文
A lot of people are talking about the "none" algorithm issue, but the more recent vulnerability[0] is more telling: The report to the working group mailing list[1] led to the point that the standard had a "security considerations" section in the RFC, and this particular issue was never covered. And now there are difficulties around the fact they cannot update an RFC which people will refer to for years. It's not a vulnerability in one or two libraries - it looks like just about every made the same mistake, which points to something much more broken. [0] https://auth0.com/blog/critical-vulnerability-in-json-web-encryption [1] https://www.ietf.org/mail-archive/web/jose/current/msg05613.html
作者提出了 PASETO 作为更开发者友好的替代方案。
如果你像我一样更爱看 HN 评论而不是原文：作者不只是抱怨 JOSE/JWT，他还设计了替代方案 PASETO（paseto.io）。Okta 有一篇不错的第三方介绍。PASETO 看起来很好：对开发者友好，让非密码学专家也很难搬起石头砸自己的脚。我迫不及待希望它在流行度上取代 JWT。
skrebbel查看英文原文
If you, like me, prefer HN comments over articles: The author does not just complain about JOSE and JWT but he also designed an alternative, PASETO: https://paseto.io/ Here's a nice PASETO write-up from Okta, a reputable third party: https://developer.okta.com/blog/2019/10/17/a-thorough-introduction-to-paseto PASETO looks excellent to me, in that it's proper developer friendly and makes it hard for non crypto nerds like me to shoot themselves in the foot. I can't wait for it to replace JWT in popularity.
历次讨论
同类还值得读
非法素数
Illegal prime
维基百科条目，介绍“非法素数”：某些素数之所以被称为“非法”，是因为它们经特定编码后，恰好对应一段被法律禁止传播的数据——最著名的是 DVD 解密程序 DeCSS 的代码，有人把…
安全与隐私上首页 5 次 · 2010–2021en.wikipedia.org编辑精选关于 /dev/urandom 的常见误区
Myths about /dev/urandom
（Thomas Hühn 撰写，2014 年首发并持续更新）逐条反驳关于 /dev/urandom 的常见误解：它与 /dev/random 使用的是同一个 CSPRNG，一旦完…
安全与隐私上首页 5 次 · 2014–20202uo.de编辑精选AES 高级加密标准火柴人图解
A Stick Figure Guide to the Advanced Encryption Standard (AES)
一篇用火柴人漫画形式讲解 AES（高级加密标准）算法的经典科普文章。
安全与隐私上首页 5 次 · 2009–2022moserware.com编辑精选指纹是用户名，不是密码
Fingerprints are Usernames, not Passwords
作者（eCryptfs 维护者、Ubuntu 安全工程师）认为指纹等生物特征是公开、不可更改的标识，应视作用户名而非密码，不能当作秘密凭据用于认证。
安全与隐私上首页 4 次 · 2013–2017blog.dustinkirkland.comHTTPS 连接的最初几毫秒（2009）
The First Few Milliseconds of an HTTPS Connection (2009)
逐毫秒拆解一次 HTTPS 连接建立时发生了什么，重点讲 TLS 握手、证书验证、RSA 签名与密钥协商等机制，面向不熟悉该领域的读者。
安全与隐私上首页 4 次 · 2009–2020moserware.com编辑精选