如何在SpringBoot中集成JWT(JSON Web Token)鉴权

这篇博客主要是简单介绍了一下什么是JWT，以及如何在Spring Boot项目中使用JWT(JSON Web Token)。

1.关于JWT

1.1 什么是JWT

老生常谈的开头，咱们要用这样一种工具，首先得知道如下几个问题。

• 这个工具是什么，这个工具解决了什么问题
• 是否适用于当前咱们所处得业务场景
• 用了以后是否会带来任何其余问题
• 怎么用才是最佳实践

那什么是JWT呢？如下是我对jwt官网上对JWT介绍的翻译。

JSON Web Token （JWT）是一种定义了一种紧凑而且独立的，用于在各方之间使用JSON对象安全的传输信息的一个开放标准（RFC 7519）。

如今咱们知道，JWT实际上是一种开放标准，用于在多点之间安全地传输用JSON表示的数据。在传输的过程当中，JWT以字符串的形式出如今咱们的视野中。该字符串中的信息能够经过数字签名进行验证和信任。

1.2 应用场景

JWT在实际的开发中，有哪些应用场景呢？

1.2.1 受权

这应该算是JWT最多见的使用场景。在前端界面中，一旦用户登陆成功，会接收到后端返回的JWT。后续的请求都会包含后端返回的JWT，做为对后端路由、服务以及资源的访问的凭证。

1.2.2 信息交换

利用JWT在多方之间相互传递信息具备必定的安全性，例如JWT能够用HMAC、RSA非对称加密算法以及ECDSA数字签名算法对JWT进行签名，能够确保消息的发送者是真的发送者，并且使用header和payload进行的签名计算，咱们还能够验证发送的消息是否被篡改了。

2.JWT的结构

通俗来说JWT由header.payload.signature三部分组成的字符串，网上有太多帖子介绍这一块了，因此在这里就简单介绍一下就行了。

2.1 header

header由使用的签名算法和令牌的类型的组成，例如令牌的类型就是JWT这种开放标准，而使用的签名算法就是HS256，也就是HmacSHA256算法。其余的加密算法还有HmacSHA512、SHA512withECDSA等等。

而后将这个包含两个属性的JSON对象转化为字符串而后使用Base64编码，最终造成了JWT的header。

2.2 payload

payload说直白一些就相似你的requestBody中的数据。只不过是分了三种类型，预先申明好的、自定义的以及私有的。像iss发件人，exp过时时间都是预先注册好的申明。

预先申明在载荷中的数据不是强制性的使用，可是官方建议使用。而后这串相似于requestBody的JSON通过Base64编码造成了JWT的第二部分。

2.3 signature

若是要生成signature，就须要使用jwt自定义配置项中的secret，也就是Hmac算法加密所须要的密钥。将以前通过Base64编码的header和payload用.相连，再使用自定义的密钥，对该消息进行签名，最终生成了签名。

生成的签名用于验证消息在传输的过程当中没有被更改。在使用非对称加密算法进行签名的时候，还能够用于验证JWT的发件人是否与payload中申明的发件人是同一我的。

3.JWT在Spring项目中的应用场景

3.1 生成JWT

代码以下。

public String createJwt(String userId, String projectId) throws IllegalArgumentException, UnsupportedEncodingException {
    Algorithm al = Algorithm.HMAC256(secret);
    Instant instant = LocalDateTime.now().plusHours(outHours).atZone(ZoneId.systemDefault()).toInstant();
    Date expire = Date.from(instant);
    String token = JWT.create()
            .withIssuer(issuer)
            .withSubject("userInfo")
            .withClaim("user_id", userId)
            .withClaim("project_id", projectId)
            .withExpiresAt(expire)
            .sign(al);
    return token;
}

传入的两个Claim是项目里自定义的payload，al是选择的算法，而secret就是对信息签名的密钥，subject则是该token的主题，withExpiresAt标识了该token的过时时间。

3.2 返回JWT

在用户登陆系统成功以后，将token做为返回参数，返回给前端。

3.3 验证token

在token返回给前端以后，后端要作的就是验证这个token是不是合法的，是否能够访问服务器的资源。主要能够经过如下几种方式去验证。

3.3.1 解析token

使用JWTVerifier解析token，这是验证token是否合法的第一步，例如前端传过来的token是一串没有任何意义的字符串，在这一步就能够抛出错误。示例代码以下。

try {
    Algorithm algorithm = Algorithm.HMAC256(secret);
    JWTVerifier verifier = JWT.require(algorithm).build();
    DecodedJWT jwt = verifier.verify(token);
} catch (JWTVerificationException e) {
    e.printStackTrace();
}

JWTVerifier可使用用制定secret签名的算法，指定的claim来验证token的合法性。

3.3.2 判断token时效性

判断了token是有效的以后，再对token的时效性进行验证。

try {
    Algorithm algorithm = Algorithm.HMAC256(secret);
    JWTVerifier verifier = JWT.require(algorithm).build();
    DecodedJWT jwt = verifier.verify(token);
    if (jwt.getExpiresAt().before(new Date())) {
        System.out.println("token已过时");
        return null;
    }
} catch (JWTVerificationException e) {
    e.printStackTrace();
    return null;
}

若是该token过时了，则不容许访问服务器资源。具体的流程以下。

3.3.3 刷新过时时间

上面建立token的有效时间是能够配置的，假设是2个小时，而且用户登陆进来连续工做了1小时59分钟，在进行一个很重要的操做的时候，点击肯定，这个时候token过时了。若是程序没有保护策略，那么用户接近两个小时的工做就成为了无用功。

遇到这样的问题，咱们以前的流程设计必然面对一次重构。可能你们会有疑问，不就是在用户登陆以后，每次操做对去刷新一次token的过时时间吗？

那么问题来了，咱们知道token是由header.payload.signature三段内容组成的，而过时时间则是属于payload，若是改变了过时的时间，那么最终生成的payload的hash则势必与上一次生成的不一样。

换句话说，这是一个全新的token。前端要怎么接收这个全新的token呢？可想到的解决方案无非就是每次请求，根据response header中的返回不断的刷新的token。可是这样的方式侵入了前端开发的业务层。使其每个接口都须要去刷新token。

你们可能会说，无非就是加一个拦截器嘛，对业务侵入不大啊。即便这部分逻辑是写在拦截器里的，可是前端由于token鉴权的逻辑而多出了这部分代码。而这部分代码从职能分工上来讲，实际上是后端的逻辑。

说的直白一些，刷新token，对token的时效性进行管理，应该是由后端来作。前端不须要也不该该去关心这一部分的逻辑。

3.3.4 redis大法好

综上所述，刷新token的过时时间势必要放到后端，而且不能经过判断JWT中payload中的expire来判断token是否有效。

因此，在用户登陆成功以后并将token返回给前端的同时，须要以某一个惟一表示为key，当前的token为value，写入Redis缓存中。而且在每次用户请求成功后，刷新token的过时时间，流程以下所示。

通过这样的重构以后，流程就变成了这样。

在流程中多了一个刷新token的流程。只要用户登陆了系统，每一次的操做都会刷新token的过时时间，就不会出现以前说的在进行某个操做时忽然失效所形成数据丢失的状况。

在用户登陆以后的两个小时内，若是用户没有进行任何操做，那么2小时后再次请求接口就会直接被服务器拒绝访问。

4.总结

总的来讲，JWT中是不建议放特别敏感信息的。若是没有用非对称加密算法的话，把token复制以后直接能够去jwt官网在线解析。若是请求被拦截到了，里面的全部信息等因而透明的。

可是JWT能够用来看成一段时间内运行访问服务器资源的凭证。例如JWT的payload中带有userId这个字段，那么就能够对该token标识的用户的合法性进行验证。例如，该用户当前状态是否被锁定？该userId所标识的用户是否存在于咱们的系统？等等。

而且经过实现token的公用，能够实现用户的多端同时登陆。像以前的登陆以后建立token，就限定了用户只能同时在一台设备上登陆。

欢迎你们浏览以前的文章：我的博客，若是有说的不对的地方，还请不吝赐教。

5.参考

• JWT官网