jwttoken过期解决方法

用户登录时调用后端认证接口，后端验证用户成功之后生成两个token，access_token和refresh_token，后端将用户信息和这两个token打包成JWT后并返回给前端。前端在获取到登录成功返回的两个token之后，将之存放到localStorage本地存储中。

JWT设置了过期时间以后，一定超过，那么接口就不能访问了，需要用户重新登录获取token。如果经常需要用户重新登录，显然这种体验不是太好，因此很多应用会采用token过期后自动续期的方案，只有特定条件下才会让用户重新登录。

JWT是一种授权的场景，可以用来在非常有限的时间内允许用户使用服务终端访问服务器，在整个会话过程中JWT用户身份认证，JWT也会存在过期，这时就需要进行更新处理，以达到提升安全性的目的。

本文适合： 对Spring Security有一点了解或者跑过简单demo但是对整体运行流程不明白的同学，对SpringSecurity有兴趣的也可以当作你们的入门教程，示例代码中也有很多注释。

大家在做系统的时候，一般做的第一个模块就是 认证与授权 模块，因为这是一个系统的入口，也是一个系统最重要最基础的一环，在认证与授权服务设计搭建好了之后，剩下的模块才得以安全访问。

市面上一般做认证授权的框架就是shiro和Spring Security，也有大部分公司选择自己研制。出于之前看过很多Spring Security的入门教程，但都觉得讲的不是太好，所以我这两天在自己鼓捣Spring Security的时候萌生了分享一下的想法，希望可以帮助到有兴趣的人。

Spring Security框架我们主要用它就是解决一个认证授权功能，所以我的文章主要会分为两部分：

我会为大家用一个Spring Security + JWT + 缓存的一个demo来展现我要讲的东西，毕竟脑子的东西要体现在具体事物上才可以更直观的让大家去了解去认识。

学习一件新事物的时候，我推荐使用自顶向下的学习方法，这样可以更好的认识新事物，而不是盲人摸象。

注 ：只涉及到用户认证授权不涉及oauth2之类的第三方授权。

想上手 Spring Security 一定要先了解它的工作流程，因为它不像工具包一样，拿来即用，必须要对它有一定的了解，再根据它的用法进行自定义 *** 作。

我们可以先来看看它的工作流程：

在Spring Security的官方文档上有这么一句话：

Spring Security 的web基础是Filters。

这句话展示了Spring Security的设计思想： 即通过一层层的Filters来对web请求做处理。

放到真实的Spring Security中，用文字表述的话可以这样说:

一个web请求会经过一条过滤器链，在经过过滤器链的过程中会完成认证与授权，如果中间发现这条请求未认证或者未授权，会根据被保护API的权限去抛出异常，然后由异常处理器去处理这些异常。

用表述的话可以这样画，这是我在百度找到的一张：

如上图，一个请求想要访问到API就会以从左到右的形式经过蓝线框框里面的过滤器，其中绿色部分是我们本篇主要讲的负责认证的过滤器，蓝色部分负责异常处理，橙色部分则是负责授权。

图中的这两个绿色过滤器我们今天不会去说，因为这是Spring Security对form表单认证和Basic认证内置的两个Filter，而我们的demo是JWT认证方式所以用不上。

如果你用过Spring Security就应该知道配置中有两个叫formLogin和>

JWT(JsonWebToken)，刷新令牌存在的意义是当客户端异常时，也只会在访问令牌过期时间内异常，换取新的访问令牌时，服务端可以介入重新验证客户端身份，它不是解决了安全问题，而是降低了安全风险。

客户端和服务端的交互通常是这样的：

1 用户输入用户名和密码，调登录 API, 返回访问令牌(access_token：假设10分钟过期)和刷新令牌(refresh_token：假设3天过期)

2 登录后10分钟没有 *** 作，需要使用刷新令牌换取新的访问令牌和新的刷新令牌(此时重新计算3天过期时间)，然后用新的访问令牌调业务API

3 然后3天没有换过新的访问令牌，此时刷新令牌也过期了，重新请求业务API服务端会返回401，前端跳登录页，用户再次输入密码验证身份。

回到刷新令牌的作用

假设用户登录后(登录接口同时记录了用户的IP地址)，黑客截获了访问令牌和刷新令牌，此时黑客只能在访问令牌过期前做破环，因为当黑客用自己的IP地址拿着刷新令牌换访问令牌时，服务端很容易甄别(IP变化), 此时服务端返回 401，让用户重新输入密码验证身份。

假设用户登录后，每秒1000次调用某个业务API，这显然也是不合理的(机器人)，那么服务端最多允许它在访问令牌过期前这么干，换令牌时可以做拉黑处理。

问：你说只用访问令牌也能做到这个，把访问令牌过期时间设置的短一点不就行了

显而易见，这样需要频繁验证用户身份，让用户多次输入密码，不仅增加了密码泄露的几率，而且体验会很差，另外访问令牌的过期时间设置多久也是个问题，长了，增加了客户端攻击的时间段，短了，用户不断输密码更不安全，而且还烦。

所以双 token 机制 

1 允许你掌控，根据 *** 作的安全等级，设置不同的过期时间也是一种办法，服务端可以灵活的控制。

2 如果用户一直在刷新令牌过期前有 *** 作，理论上可以一直不用输入密码验证，体验会很好。

JWT全称“JSON Web Token”，是基于JSON的用户身份认证的令牌。可跨域身份认证，所以JWT很适合做分布式的鉴权，单点登录（SingleSign,SSO）。

jwt有三部分组成用符号""隔开，

HEADER：token头，描述token是什么类型，加密方式是什么，把json内容转为base64

PAYLOAD:内容，是暴露出来的信息，不可存敏感信息,把json内容转为base64

SIGNATURE:签名，按token头的加密方式把HEADER和PAYLOAD的信息加密生成签名，下面是官网上面的介绍，地址： >

12 认证服务器依赖

13 配置文件 applicationyml

14 认证服务器配置（核心类AuthorizationServerConfigurerAdapter）

认证服务器配置类必须继承AuthorizationServerConfigurerAdapter类

141 内存存储token方案

142 配置Spring Security的安全认证

143 自定义ClientDetailsService实现类

144 相关实体类

15 gateway 网关

151 pom依赖

152 applicationyml配置文件

153 security安全配置

154 gateway全局过滤器

155 其他类

16 资源服务器

161 依赖配置

162 资源服务器配置

继承ResourceServerConfigurerAdapter类

安全配置继承WebSecurityConfigurerAdapter

163 token过滤器

获取从网关处转发的token，填充到认证的安全上下文中，实现身份权限识别

22 安全配置

23 其他配置

24 身份信息过滤

1问题描述

jwt与token+redis，哪种方案更好用？

问题结论

刚好最近有项目使用了jwt，而且是定制化的jwt的认证机制，就个人的理解而言，各自有其优缺点，并且针对不同的场景需要进行约束性开发，如用户剔除、同一用户每2h只生成一次jwt等。

2Token机制简述

21Token的用途

用户在登录APP时，APP端会发送加密的用户名和密码到服务器，服务器验证用户名和密码，如果验证成功，就会生成相应位数的字符产作为token存储到服务器中，并且将该token返回给APP端。以后APP再次请求时，凡是需要验证的地方都要带上该token，然后服务器端验证token，成功返回所需要的结果，失败返回错误信息，让用户重新登录。其中，服务器上会给token设置一个有效期，每次APP请求的时候都验证token和有效期。

在存储的时候把token进行对称加密存储，用到的时候再解密。文章最开始提到的签名sign：将请求URL、时间戳、token三者合并，通过算法进行加密处理。

22token+redis机制

用户验证通过后，服务端通过如uuid相关的方法，生成token，存储用户信息。当请求服务时，客户端将token带上来，进行查询验证，如token存在并在有限期内，请求有效，否则请求非法。

token+redis机制是中心化的，每次验证token有效性时，都需要访问redis，其核心优点实服务端可以主动让token失效，缺点是每次都要进行redis查询。占用redis存储空间。

23jwt机制

这是一种无状态身份验证机制，因为用户状态永远不会保存在服务器内存中。服务器受保护的路由将在授权头中检查有效的JWT，如果存在，则允许用户访问受保护的资源。由于JWT是独立的，所有必要的信息都在那里，减少了多次查询数据库的需求。

Javajwt普遍选用java-jwt工具包依赖，gradle依赖：compile'comauth0:java-jwt:320'用户发起登录请求，验证通过后，服务端创建一个加密后的JWT信息，作为Token返回。在后续请求中JWT信息作为请求头，发给服务端。服务端拿到JWT之后进行解密，正确解密表示此次请求合法，验证通过；解密失败说明Token无效或者已过期。

jwt的有点主要有：a其是去中心化的，便于分布式系统使用；2基本信息可以直接放在token中。user_id，session_id；3功能权限信息可以直接放在token中。用bit位表示用户所具有的功能权限。其缺点有：服务端无法主动让token失效，另一个是无法很好的控制payload的数据量。

3小结

jwt和token+redis两种方案，没有最优，只有结合不同的业务场景，需求最适合的方案。就比如token2h过期，同一用户每15h只生成一次token，当两次token并存时，同时有效。大家可以考虑在这两种方案的前提下，分别如何实现？

以上就是关于jwttoken过期解决方法全部的内容，包括:jwttoken过期解决方法、SpringSecurity+JWT认证流程解析、JWT, 为什么需要刷新令牌等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！