JWT（JSON Web Token）与自定义令牌

Question

我浏览了问题，但没有找到可以解决我的疑问的内容。我找到了很多有关JWT的详细信息，但是在比较JWT可以提供的优势与生成自定义token对REST服务进行身份验证时，没有太多相关信息。

相比于生成自定义token，使用JWT（Json Web Token）的优势是什么？要生成自定义token，我可以使用一些散列策略或某些唯一随机数生成器。

如果我生成自定义token，是否存在安全问题？ 您是否建议使用其他身份验证机制？

谢谢！

- Deibys

---

嗨，Deibys，我有同样的问题，你找到了令人信服的答案吗？你最终采用了什么方法？谢谢。 - Adnane.T

同样的问题，既然不应该在会话中使用JWT，为什么我不能使用自己的令牌实现呢？ - Anuj Kumar

Answer 1

JWT令牌包含声明（claims），这些声明是有关主题的陈述（例如登录用户）。这些声明可以是姓名、电子邮件、角色等。JWT令牌经过数字签名，不易受到跨站请求伪造（CSRF）攻击。

这两个特征确保接收令牌的服务不需要返回到发行身份验证服务器来验证令牌的有效性或获取有关主题的信息。

这显著提高了使用JWT令牌系统的可扩展性。JWT令牌需要安全传输通道（HTTPS）。

这样做的缺点是令牌无法被撤销（因为没有中央服务器守护这些令牌）。这就是为什么令牌通常具有短寿命的原因。

另一方面，持有会话ID的令牌需要联系身份验证服务器来验证令牌（通常是数据库查找）并检索有关主题的信息（另一个数据库查找）。

验证HMAC令牌需要知道用于生成令牌的密钥。通常，接收服务（您的API）将需要联系身份验证服务器，因为该服务器是保存密钥的位置。

HMAC令牌和会话ID通常存储在cookie中。Cookie不能用于跨域服务调用，并且需要受到CSRF攻击的保护。

- MvdD

---

JWT本身并没有提供任何对抗CSRF或XSS攻击的措施。签名是防止令牌被篡改的一种措施。即使签名了，令牌仍然可能会被盗取。Stormpath有一篇很好的文章，描述了应该在哪里存储JWT令牌以及如何防止CSRF和XSS攻击。链接：https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/ - Mika Tuupola

JWT令牌本身并不能防范CSRF攻击，但它们通常用于承载认证方案。承载认证方案不容易受到CSRF攻击。我阅读了Stormpath的文章，但不同意他们的建议。将JWT令牌存储在cookie中会使非浏览器客户端更难以使用您的API，并且难以让您的API在不同的域中运行。 - MvdD

如果我想让应用程序独立于渠道，我认为使用cookies不是一个明智的决定，我听说一些移动设备在处理cookies时会出现问题。根据客户端应用程序，他们将决定如何存储令牌（对于浏览器应用程序，我想html5 web会话存储是一个选项）。现在，我需要根据需要使令牌失效，因此从服务器端来看，我需要为它们提供一些数据存储。您认为将它们保存在数据库中是否可以？ - Deibys

老实说，我仍然看不出使用JWT令牌的优势，相比之下，自定义生成的令牌可能更难被攻击，如果它们是哈希值，并且我在服务器上有一个数据存储来验证它们是否有效。 - Deibys

如果您需要使令牌失效，JWT 令牌可能不是最佳选择。但通常令牌的生命周期足够短，无需担心失效。我不会将 JWT 令牌存储在 cookie 中。通常使用承载者身份验证方案。 - MvdD

另外需要补充的是，JWT令牌并没有加密，因此在其中存储敏感信息存在问题，因为它驻留在客户端机器上，攻击者可以获取令牌，然后发现更多关于用户的信息。你可能会认为这不是什么大问题，因为他可以使用该令牌访问服务并可能接收相同的信息，但我认为会话令牌比仅签名更好地加密了。 - ArielB

Answer 2

从Django REST framework文档中，

引用：

JSON Web Token是一种相对较新的标准，可用于基于令牌的身份验证。与内置的TokenAuthentication方案不同，JWT身份验证不需要使用数据库来验证令牌。

- Chemical Programmer