JWT实战之升级Java JWT

最新推荐文章于 2025-04-29 11:28:25 发布

johnny233

最新推荐文章于 2025-04-29 11:28:25 发布

阅读量2.3k

点赞数 29

分类专栏： Java 文章标签： java

本文链接：https://blog.csdn.net/lonelymanontheway/article/details/136630642

版权

本文详细描述了从JWT0.9.1版本升级到0.12.5版本过程中遇到的依赖更新、编译错误、废弃API替换、安全问题（如弱密钥和算法要求）以及postman配置中的挑战，展示了升级过程中的学习和调试过程。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

概述

关于JWT的基础概念，如JWT组成部分，以及入门实战，如：如何生成Token、如何解析Token、怎么加入自定义字段等，可参考JWT入门教程。

如前文提到的blog所述，大多数公司都会使用如下（版本）的Maven依赖：

<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt</artifactId>
    <version>0.9.1</version>
</dependency>

看一下Maven仓库：
在这里插入图片描述
可以看到有64个CVE安全漏洞！很多！！

使用JWT（以及其他安全框架，如Spring Security或Spring Security OAuth2）的目标是加强应用的认证和鉴权，结果Java JWT工具包本身有这么多CVE安全隐患，有点搞笑了。

于是产生依赖库升级这样一个技术改造需求，本文记录升级遇到的问题。

问题

GAV变更

谈到依赖三方库升级，必然需要借助于Maven仓库。搜索不难发现，artifactId发生变更，需要引入如下依赖：

<properties>
    <jjwt.version>0.12.5</jjwt.version>
</properties>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-api</artifactId>
    <version>${jjwt.version}</version>
</dependency>

编译问题

在这里插入图片描述
如上截图，编译报错是比@deprecated API更严重的问题。使用过期的，即将废弃的API，即@deprecated API，IDEA会给出屎黄色的warning提示。一般而言，某个过期API，再经过几次版本升级迭代后，就会变成removed API，即编译报错，也就是上面截图看到的红色。执行mvn compile失败，应用启动失败。

代码片段如下：

public static Claims getClaimsFromToken(String token) {
   
    Claims claims;
    try {
   
        claims = Jwts.parser()
                .setSigningKey(secret)
                .parseClaimsJws(token)
                .getBody();
    } catch (Exception e) {
   
        claims = null;
    }
    return claims;
}

关于如何替换被标记为@deprecated或removed的API，一般都是看源码。

比如上面的setSigningKey源码注释里有提到in favor of verifyWith(SecretKey) as explained in the above Deprecation Notice and will be removed in 1.0.0.告知，故而可以考虑使用verifyWith(SecretKey)来作为替换。

但是如果版本升级跨度太大（API被废弃后标红，根本就不能通过IDEA去查看源码），或是开源代码维护者没有提供替换API等解决方案，则比较麻烦。此时一般都是去查看官方文档，或Google搜索。好在Java JWT提供维护良好的文档。

调整后的代码片段如下：