关于JWT（JSON Web Token）的基础知识，您可回顾之前的博客：快速了解会话管理中的cookie、session与JWT。
在前一篇文章《深度解析JWT在鉴权登录的应用》中，我们详细介绍了JWT在鉴权登录中的应用。若不当使用JWT，可能会对应用程序的安全性产生威胁。
本文将进一步探讨在鉴权登录业务场景下JWT的安全性问题。
由于JWT的载荷部分是明文传输的，若其中包含敏感信息，则存在信息的风险。
由于JWT的传输是公开的，获得令牌的可能继续使用该JWT访问应用程序。推荐使用双JWT机制来降低安全风险，具体使用方法详见《深度解析JWT在鉴权登录的应用》。
在Payload中添加业务相关字段，可用于校验当前JWT是否被滥用。例如，加入设备标识、用户唯一标识符（UUID）及权限信息等，这些信息可与上下文信息进行比对，从而提高爬虫的门槛和接口安全性。
在JWT头部的可选参数中，kid（密钥标识）用于指定加密算法的密钥。由于该参数可能由用户输入，若未经验证即直接使用，攻击者可能读取系统中的任意文件，甚至导致SQL注入或命令注入等安全漏洞。
对从用户接收的所有数据进行验证和过滤是至关重要的。
若加密密钥的强度不足，攻击者可能通过的方式来获取密钥。为此，可以使用PyJWT、John Ripper或c-jwt-cracker等工具进行密钥测试。
虽然秘钥的定期变更可以提高安全性，但这也给用户带来了不便。这有助于避免安全事件的发生。
签名算法能够确保JWT在传输过程中不被恶意篡改。头部中的alg字段若被设置为None，即不使用签名算法，当signature为空时，后端将不执行签名验证。
若将alg字段改为none后生成JWT并提交至服务器进行校验，那么有必要在服务端设置已授权算法的，并移除所有不符合授权算法的JWT。
在使用非对称算法进行令牌签名的情况下，应确保使用私钥进行签名而使用公钥进行验证。但某些JWT库可能存在逻辑错误，导致公钥被误用为签名验证的密钥。当网站采用非对称加密验证且不对签名算法进行限制时，存在被攻击的风险。
为说明这一问题，以下实验内容节选自参考文档7的部分内容。
以非对称加密算法RS256为例，新建一个JWT如下:
转换为JWT后的情况为：在此过程中，使用RS256算法进行签名需要公钥和私钥的配合。
公钥部分如下:
私钥部分如下:
为验证JWT的有效性，可利用参考文档2提供的网站进行验证。其头部和载荷部分转换如下:
在此只需使用公钥来读取签名。
- 首先将密钥转换为十六进制表示法。
- 然后使用openssl工具生成一个签名。
- 将特定值添加到网站上的“secret”中（确保选择了“secret base64 encoded”），最终的JWT如下:
从网站显示的结果来看，JWT已成功通过验证。建议仅使用一种加密方式，以避免类似的安全漏洞。
市面上有多种JWT库可供选择，由于选型建议具有时效性，本文不做具体推荐。您可参考网上的选型对比文章进行选择。
参考文档列表：