摘要：在使用非对称加密算法进行签名的时候，还可以用于验证的发件人是否与中申明的发件人是同一个人。如果没有用非对称加密算法的话，把复制之后直接可以去官网在线解析。
这篇博客主要是简单介绍了一下什么是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 headerheader由使用的签名算法和令牌的类型的组成，例如令牌的类型就是JWT这种开放标准，而使用的签名算法就是HS256，也就是HmacSHA256算法。其他的加密算法还有HmacSHA512、SHA512withECDSA等等。
然后将这个包含两个属性的JSON对象转化为字符串然后使用Base64编码，最终形成了JWT的header。
2.2 payloadpayload说直白一些就类似你的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官网
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/73766.html
摘要：在使用非对称加密算法进行签名的时候，还可以用于验证的发件人是否与中申明的发件人是同一个人。如果没有用非对称加密算法的话，把复制之后直接可以去官网在线解析。 这篇博客主要是简单介绍了一下什么是JWT，以及如何在Spring Boot项目中使用JWT(JSON Web Token)。 1.关于JWT 1.1 什么是JWT 老生常谈的开头，我们要用这样一种工具，首先得知道以下几个问题。 这...
摘要：框架具有轻便，开源的优点，所以本译见构建用户管理微服务五使用令牌和来实现身份验证往期译见系列文章在账号分享中持续连载，敬请查看在往期译见系列的文章中，我们已经建立了业务逻辑数据访问层和前端控制器但是忽略了对身份进行验证。 重拾后端之Spring Boot（四）：使用JWT和Spring Security保护REST API 重拾后端之Spring Boot（一）：REST API的搭建...
摘要：今天我们来结合实例给大家讲述的实战应用，就是如何使用前端与后端实现用户登录鉴权认证的过程。只用了一个串，建立前后端的验证的数据传递，实现了有效的登录鉴权过程。 今天我们来结合实例给大家讲述JWT(Json Web Token)的实战应用，就是如何使用前端Axios与后端PHP实现用户登录鉴权认证的过程。 文中涉及的重要知识点： axios异步请求：axios-基于Promise的HTT...
摘要：小程序官方流程图如下，官方地址如果此图理解不清楚的地方也可参看我的博客本文是对接微信小程序自定义登录的一个完整例子实现，技术栈为。调用微信接口获取和根据和自定义登陆态返回自定义登陆态给小程序端。 小程序官方流程图如下，官方地址 : https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/login....
摘要：作为目前最主流的微服务框架，发展速度很快，成为了最全面的微服务解决方案。通过认证后，转发给内部相应的服务器。所有远程访问资源服务器相关的必须提供。 Part 1 - 理论相关 作者 freewolf 关键词 微服务、Spring Cloud、OAuth 2.0、JWT、Spring Security、SSO、UAA 写在前面 作为从业了十多年的IT行业和程序的老司机，今天如果你说你不懂...
阅读 1073·2021-11-11 10:57
阅读 3476·2021-09-07 10:10
阅读 3300·2021-08-03 14:03
阅读 2949·2019-08-30 13:45
阅读 571·2019-08-29 11:19
阅读 924·2019-08-28 18:07
阅读 2935·2019-08-26 13:55
阅读 676·2019-08-26 12:17
