1. JWT令牌详解
JWT是JSON Web Token的缩写,是一个轻巧的规范,一个开放的行业标准,它定义了一种简洁的、自包含的协议格式,这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的消息.
一个JWT实际上就是一个字符串,它由三部分组成,头部、荷载与签名
头部描述关于该JWT的最基本的信息,例如其类型以及签名所用的算法等
例如{"type":"JWT","alg":"HS256"}
其头部指明了签名算法是HS256算法
HMAC算法(非对称的)
SH256
RSA
荷载就是存放有效信息的地方
定义一个payload:{"sub":"1234567890","name":"John Doe","admin":true}
签证又由三部分组成,base64加密后的header和base64加密后的payload使用,连接组成的字符串
然后通过header中声明的加密方式进行加盐secret组合加密.
1、jwt基于json,非常方便解析
2、可以在令牌中自定义丰富的内容,易扩张
3、通过非对称加密算法以及数字签名技术,JWT防止篡改,安全性高
4、资源服务使用JWT可不依赖认证服务即可完成授权
JWT令牌较长,占存储空间比较大.
一个公钥对应一个私钥,私钥作为签名给JWT加密,那么这里需要生成与之对应的公钥:
输入密钥库口令: keytool -list -keystore changgou.jks
显示的信息为:
密钥库类型: jks
密钥库提供方: SUN
您的密钥库包含 1 个条目
changgou, 2020-7-28, PrivateKeyEntry,
证书指纹 (SHA1): 45:2E:51:8B:84:86:03:8C:AF:99:14:5F:4F:D6:98:33:39:92:33:79
输入命令后就可以得到公钥:
注释:classPathResource:私钥位置;
new KeyStoreKeyFactory:创建私钥工厂,需要私钥库密码和私钥位置两个参数;
keyStoreKeyFactory.getKeyPair(alias,password.toCharArray):获取keyPair对象,keyPair.getPrivate()即是获取私钥;
根据私钥获取令牌:JwtHelper.encode(JSON.toJSONString(map,new RsaSigner(rsaPrivateKey));
2. SpringSecurity+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和httpBasic的配置项，在配置中打开了它俩就对应着打开了上面的过滤器。
换言之，你配置了这两种认证方式，过滤器链中才会加入它们，否则它们是不会被加到过滤器链中去的。
因为Spring Security自带的过滤器中是没有针对JWT这种认证方式的，所以我们的demo中会 写一个JWT的认证过滤器，然后放在绿色的位置进行认证工作。
知道了Spring Security的大致工作流程之后，我们还需要知道一些非常重要的概念也可以说是组件：
上下文对象，认证后的数据就放在这里面，接口定义如下：
这个接口里面只有两个方法，其主要作用就是get or set Authentication。
可以说是SecurityContext的工具类，用于get or set or clear SecurityContext，默认会把数据都存储到当前线程中。
这几个方法效果如下：
Authentication只是定义了一种在SpringSecurity进行认证过的数据的数据形式应该是怎么样的，要有权限，要有密码，要有身份信息，要有额外信息。
AuthenticationManager定义了一个认证方法，它将一个未认证的Authentication传入，返回一个已认证的Authentication，默认使用的实现类为：ProviderManager。
接下来大家可以构思一下如何将这四个部分，串联起来，构成Spring Security进行认证的流程：
1. 先是一个请求带着身份信息进来
2. 经过AuthenticationManager的认证，
3. 再通过SecurityContextHolder获取SecurityContext，
4. 最后将认证后的信息放入到SecurityContext。
真正开始讲诉我们的认证代码之前，我们首先需要导入必要的依赖，数据库相关的依赖可以自行选择什么JDBC框架，我这里用的是国人二次开发的myabtis-plus。
接着，我们需要定义几个必须的组件。
由于我用的Spring-Boot是2.X所以必须要我们自己定义一个加密器：
这个Bean是不必可少的，Spring Security在认证操作时会使用我们定义的这个加密器，如果没有则会出现异常。
实现UserDetailsService的抽象方法并返回一个 UserDetails 对象，认证过程中SpringSecurity会调用这个方法访问数据库进行对用户的搜索，逻辑什么都可以自定义，无论是从数据库中还是从缓存中，但是我们需要将我们查询出来的用户信息和权限信息组装成一个 UserDetails 返回。
UserDetails 也是一个定义了数据形式的接口，用于保存我们从数据库中查出来的数据，其功能主要是验证账号状态和获取权限，具体实现可以查阅我仓库的代码。
由于我们是JWT的认证模式，所以我们也需要一个帮我们操作Token的工具类，一般来说它具有以下三个方法就够了：
在下文我的代码里面，JwtProvider充当了Token工具类的角色，具体实现可以查阅我仓库的代码。
有了前面的讲解之后，大家应该都知道用SpringSecurity做JWT认证需要我们自己写一个过滤器来做JWT的校验，然后将这个过滤器放到绿色部分。
在我们编写这个过滤器之前，我们还需要进行一个认证操作，因为我们要先访问认证接口拿到token，才能把token放到请求头上，进行接下来请求。
如果你不太明白，不要紧，先接着往下看我会在这节结束再次梳理一下。
访问一个系统，一般最先访问的是认证方法，这里我写了最简略的认证需要的几个步骤，因为实际系统中我们还要写登录记录啊，前台密码解密啊这些操作。
这里一共五个步骤，大概只有前四步是比较陌生的：
这样的话就算完成了，感觉上很简单，因为主要认证操作都会由authenticationManager.authenticate()帮我们完成。
接下来我们可以看看源码，从中窥得Spring Security是如何帮我们做这个认证的（省略了一部分）：
看了源码之后你会发现和我们平常写的一样，其主要逻辑也是查数据库然后对比密码。
登录之后效果如下：
我们返回token之后，下次请求其他API的时候就要在请求头中带上这个token，都按照JWT的标准来做就可以。
有了token之后，我们要把过滤器放在过滤器链中，用于解析token，因为我们没有session，所以我们每次去辨别这是哪个用户的请求的时候，都是根据请求中的token来解析出来当前是哪个用户。
所以我们需要一个过滤器去拦截所有请求，前文我们也说过，这个过滤器我们会放在绿色部分用来替代，所以我们新建一个JwtAuthenticationTokenFilter，然后将它注册为Bean，并在编写配置文件的时候需要加上这个：
addFilterBefore的语义是添加一个Filter到XXXFilter之前，放在这里就是把JwtAuthenticationTokenFilter放在之前，因为filter的执行也是有顺序的，我们必须要把我们的filter放在过滤器链中绿色的部分才会起到自动认证的效果。
接下来我们可以看看JwtAuthenticationTokenFilter的具体实现了：
代码里步骤虽然说的很详细了，但是可能因为代码过长不利于阅读，我还是简单说说，也可以直接去仓库查看源码：
这样的话，每一个带有正确token的请求进来之后，都会找到它的账号信息，并放在上下文对象中，我们可以使用SecurityContextHolder很方便的拿到上下文对象中的Authentication对象。
完成之后，启动我们的demo，可以看到过滤器链中有以下过滤器，其中我们自定义的是第5个：
就酱，我们登录完了之后获取到的账号信息与角色信息我们都会放到缓存中，当带着token的请求来到时，我们就把它从缓存中拿出来，再次放到上下文对象中去。
结合认证方法，我们的逻辑链就变成了：
登录拿到token请求带上tokenJWT过滤器拦截校验token将从缓存中查出来的对象放到上下文中
这样之后，我们认证的逻辑就算完成了。
认证和JWT过滤器完成后，这个JWT的项目其实就可以跑起来了，可以实现我们想要的效果，如果想让程序更健壮，我们还需要再加一些辅助功能，让代码更友好。
当用户未登录或者token解析失败时会触发这个处理器，返回一个非法访问的结果。
当用户本身权限不满足所访问API需要的权限时，触发这个处理器，返回一个权限不足的结果。
用户退出一般就是清除掉上下文对象和缓存就行了，你也可以做一下附加操作，这两步是必须的。
JWT的项目token刷新也是必不可少的，这里刷新token的主要方法放在了token工具类里面，刷新完了把缓存重载一遍就行了，因为缓存是有有效期的，重新put可以重置失效时间。
这篇文我从上周日就开始构思了，为了能讲的老妪能解，修修改改了几遍才发出来。
作者：和耳朵
链接：https://juejin.cn/post/6846687598442708999
3. JWT-token—前后端分离架构的api安全问题
前后端分离架构带来的好处一搜一大堆，我们来看一下分离后后端接口的安全问题。
前后端分离架构现状：
这样的情况后端api是暴露在外网中，因为常规的web项目无论如何前端都是要通过公网访问到后台api的，带来的隐患也有很多。
1.接口公开，谁都可以访问
2.数据请求的参数在传输过程被篡改
3.接口被重复调用
...
session和cookie都是客户端与服务端通讯需要提供的认证，当客户端的值和服务器的值吻合时，才允许请求api，解决了第1个问题，但是当攻击者获取到了传输过程中的session或者cookie值后，就可以进行第2、3种攻击了
JWT标准的token包含三部分：
头部用于描述关于该JWT的最基本的信息，例如其类型以及签名所用的算法等
将上面的JSON对象进行 [base64编码] 可以得到下面的字符串。这个字符串我们将它称作JWT的Header
Payload也是一个JSON对象。包含了一些其他的信息
这里面的前五个字段都是由JWT的标准所定义的。
将上面的JSON对象进行 [base64编码] 可以得到下面的字符串。这个字符串我们将它称作JWT的Payload
将上面的两个编码后的字符串都用句号 . 连接在一起（头部在前），就形成了
最后，我们将上面拼接完的字符串用 HS256算法 进行加密。在加密的时候，我们还需要提供一个 密钥（secret） 。如果我们用 mystar 作为密钥的话，那么就可以得到我们加密后的内容
这一部分叫做 签名
最后将这一部分签名也拼接在被签名的字符串后面，我们就得到了完整的JWT
签名解决了数据传输过程中参数被篡改的风险
一般而言，加密算法对于不同的输入产生的输出总是不一样的，如果有人 对Header以及Payload的内容解码之后进行修改，再进行编码的话，那么新的头部和载荷的签名和之前的签名就将是不一样的。 而且，如果不知道服务器加密的时候用的密钥的话，得出来的签名也一定会是不一样的。
解决了篡改数据的问题，还有第3个问题，那就是攻击者不修改数据，只是重复攻击
比如在浏览器端通过用户名/密码验证获得签名的Token被木马窃取。即使用户登出了系统，黑客还是可以利用窃取的Token模拟正常请求，而服务器端对此完全不知道， 因为JWT机制是无状态的。
可以在Payload里增加时间戳并且前后端都参与来解决：
4. ID Token - JWT
我们来继续前两章（ OAuth2 总结 , 对OpenID Connect的理解 ）的讨论，进入对JWT的理解。先来简单回顾一下OAuth2和OpenID：
OpenID建立在OAuth之上，完成了认证和授权。而认证和授权的结果就体现在这个ID token之上，而这个ID token通常会是JWT。那么为什么会是JWT呢？我们通过以下几点来逐一解释。
JWT RFC 7519 给出了官方定义的一些字段：
当然也不限于此，可以根据自己的需要，添加其他字段。到此，我们可以看出JWT提供了ID token所需要的能力。一个完整的JTW是由三部分组成：Header，Payload，Signature。三者之间由 . 隔开，刚才提到的认证授权的字段就存在于Payload中。
Header中存放的是JTW的元数据，包含签名的算法以及token的类型，如下所示：
Signature部分是对前两部分的签名， 防止数据篡改 。首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。
算出签名以后，把 Header、Payload、Signature三个部分经过base64序列化为三个字符串，再讲三个字符串由 . 为间隔拼接成一个字符串返回给客户端。
ID Token需要有足够的安全性，JWT是如何做到的呢？
刚看到了签名部分，签名的作用只是为了防止数据篡改，而JWT默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。比如认证服务器中使用私钥进行加密，把公钥分发给其他应用服务器，应用服务拿到加密后的token后用公钥解密，获取到JWT，再用签名的秘钥来验证数据是否经过的篡改。
我们来看看还有神马其他备选么？Simple Web Tokens (SWT)和Security Assertion Markup Language Tokens (SAML)。
JWT vs SAML：JWT基于json，而SAML基于XML，在大小上就有足够的优势，更适用于HTML和HTTP。
JWT vs SWT：在安全性上，SWT只支持对称加密，而JWT和SAML支持公私钥的加密方式。
作为一个mobile developer，也想在这里对比一下原先的简单token模式和SSO中的JWT：
在没有该机制前，我们通常会使用一个随机产生的字符串作为token，认证成功后返回给前端，之后前端的每个请求带上这个token。若后台服务的是个单体应用没有什么问题，请求来了，验证一下token是否有效即可，但当认证服务和其他的应用服务是分离的，怎么做呢？应用服务受到请求，再向认证服务发起一个请求来验证验证token是否合法，是否有权限访问该应用服务。这样做到没有什么问题，只是当服务变多时，比如微服务下，势必会造成认证服务器的压力过大。
在使用该机制后，客户端通过认证服务登录，获得这个JWT，之后其他应用服务自身便可以验证这个token的是否有效，是否有权访问。
看似完美，但也有它自身的问题，我们来看一个场景：权限变更。某用户原先是一个超级管理员，可以访问所有服务，并可进行任意的删除，更改操作，他在这个状态下拿到了JWT。随后，由于权限更改为普通管理员，便不应该具有所有权限，但此时他开始时的JWT被缓存在客户端仍然可用，其他应用服务也并无法知道这个用户的权限已经被更改，后果可想而知了。解决的方式无非是将这个token的有效时间设置的短一些。
5. JWT生成token及过期处理方案
## 业务场景
在前后分离场景下，越来越多的项目使用token作为接口的安全机制，APP端或者WEB端（使用VUE、REACTJS等构建）使用token与后端接口交互，以达到安全的目的。本文结合stackoverflow以及本身项目实践，试图总结出一个通用的，可落地的方案。
## 基本思路
- 单个token
1. token（A）过期设置为15分钟
2. 前端发起请求，后端验证token（A）是否过期；如果过期，前端发起刷新token请求，后端设置已再次授权标记为true，请求成功
3. 前端发起请求，后端验证再次授权标记，如果已经再次授权，则拒绝刷新token的请求，请求成功
4. 如果前端每隔72小时，必须重新登录，后端检查用户最后一次登录日期，如超过72小时，则拒绝刷新token的请求，请求失败
- 授权token加上刷新token
用户仅登录一次，用户改变密码，则废除token，重新登录
## 1.0实现
1.登录成功，返回access\_token和refresh\_token，客户端缓存此两种token;
2.使用access_token请求接口资源，成功则调用成功；如果token超时，客户端
携带refresh\_token调用中间件接口获取新的access\_token;
3.中间件接受刷新token的请求后，检查refresh_token是否过期。
如过期，拒绝刷新，客户端收到该状态后，跳转到登录页；
如未过期，生成新的access\_token和refresh\_token并返回给客户端（如有可能，让旧的refresh\_token失效），客户端携带新的access\_token重新调用上面的资源接口。
4.客户端退出登录或修改密码后，调用中间件注销旧的token(使access\_token和refresh\_token失效)，同时清空客户端的access\_token和refresh\_toke。
后端表
id user\_id client\_id client\_secret refresh\_token expire\_in create\_date del_flag
## 2.0实现
场景： access\_token访问资源 refresh\_token授权访问 设置固定时间X必须重新登录
1.登录成功，后台jwt生成access\_token（jwt有效期30分钟）和refresh\_token（jwt有效期15天），并缓存到redis（hash-key为token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全部token，也可以根据sub-key,废除部分设备的token。），设置过期时间为1个月，保证最终所有token都能删除)，返回后，客户端缓存此两种token;
2.使用access\_token请求接口资源，校验成功且redis中存在该access\_token（未废除）则调用成功；如果token超时，中间件删除access\_token（废除）；客户端再次携带refresh\_token调用中间件接口获取新的access_token;
3.中间件接受刷新token的请求后，检查refresh_token是否过期。
如过期，拒绝刷新，删除refresh_token（废除）； 客户端收到该状态后，跳转到登录页；
如未过期，检查缓存中是否有refresh\_token（是否被废除），如果有，则生成新的access\_token并返回给客户端，客户端接着携带新的access_token重新调用上面的资源接口。
4.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access\_token和refresh\_token（废除）)，同时清空客户端侧的access\_token和refresh\_toke。
5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。
6.以上3刷新access_token可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：失效，长时间未登录，频繁刷新）
2.0 变动
1.登录
2.登录拦截器
3.增加刷新access_token接口
4.退出登录
5.修改密码
## 3.0实现
场景：自动续期 长时间未使用需重新登录
1.登录成功，后台jwt生成access\_token（jwt有效期30分钟），并缓存到redis（hash-key为access\_token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全部token），设置access_token过期时间为7天，保证最终所有token都能删除)，返回后，客户端缓存此token;
2.使用access\_token请求接口资源，校验成功且redis中存在该access\_token（未废除）则调用成功；如果token超时，中间件删除access\_token（废除）,同时生成新的access\_token并返回。客户端收到新的access_token，
再次请求接口资源。
3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access\_token（废除）)，同时清空客户端侧的access\_token。
4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长时间未登录，频繁刷新）
5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。
3.0 变动
1.登录
2.登录拦截器
3.退出登录
4.修改密码
1.3 场景：token过期重新登录 长时间未使用需重新登录
1.登录成功，后台jwt生成access\_token（jwt有效期7天），并缓存到redis，key为 "user\_id:access\_token",value为access\_token（根据用户id，可以人工废除指定用户全部token），设置缓存过期时间为7天，保证最终所有token都能删除，请求返回后，客户端缓存此access_token；
2.使用access\_token请求接口资源，校验成功且redis中存在该access\_token（未废除）则调用成功；如果token超时，中间件删除access\_token（废除）,同时生成新的access\_token并返回。客户端收到新的access_token，
再次请求接口资源。
3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access\_token（废除）)，同时清空客户端侧的access\_token。
4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长时间未登录，频繁刷新）
5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。
1.3 变动
1.登录
2.登录拦截器
3.退出登录
4.修改密码
# 解决方案
2.0 场景： access\_token访问资源 refresh\_token授权访问 设置固定时间X必须重新登录
1.登录成功，后台jwt生成access\_token（jwt有效期30分钟）和refresh\_token（jwt有效期15天），并缓
存到redis（hash-key为token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全
部token，也可以根据sub-key,废除部分设备的token。），设置过期时间为1个月，保证最终所有token都
能删除)，返回后，客户端缓存此两种token;
2.使用access\_token请求接口资源，校验成功且redis中存在该access\_token（未废除）则调用成功；如果
token超时，中间件删除access\_token（废除）；客户端再次携带refresh\_token调用中间件接口获取新的
access_token;
3.中间件接受刷新token的请求后，检查refresh_token是否过期。
如过期，拒绝刷新，删除refresh_token（废除）； 客户端收到该状态后，跳转到登录页；
如未过期，检查缓存中是否有refresh\_token（是否被废除），如果有，则生成新的access\_token并返回给
客户端，客户端接着携带新的access_token重新调用上面的资源接口。
4.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access\_token和refresh\_token（
废除）)，同时清空客户端侧的access\_token和refresh\_toke。
5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。
6.以上3刷新access_token可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（
拒绝的场景：失效，长时间未登录，频繁刷新）
2.0 变动
1.登录
2.登录拦截器
3.增加刷新access_token接口
4.退出登录
5.修改密码
3.0 场景：自动续期 长时间未使用需重新登录
1.登录成功，后台jwt生成access_token（jwt有效期30分钟），并缓存到redis（hash-key为
access_token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全部token，也可以
根据sub-key,废除部分设备的token。），设置access_token过期时间为1个月，保证最终所有token都能删
除)，返回后，客户端缓存此token;
2.使用access\_token请求接口资源，校验成功且redis中存在该access\_token（未废除）则调用成功；如果
token超时，中间件删除access\_token（废除）,同时生成新的access\_token并返回。客户端收到新的
access_token，
再次请求接口资源。
3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token（废除）)，同时清
空客户端侧的access_token。
4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长
时间未登录，频繁刷新）
5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。
3.0 变动
1.登录
2.登录拦截器
3.退出登录
4.修改密码
4.0 场景：token过期重新登录 长时间未使用需重新登录
1.登录成功，后台jwt生成access_token（jwt有效期7天），并缓存到redis，key为
"user\_id:access\_token" + 用户id,value为access_token（根据用户id，可以人工废除指定用户全部
token），设置缓存过期时间为7天，保证最终所有token都能删除，请求返回后，客户端缓存此
access_token；
2.使用access\_token请求接口资源，校验成功且redis中存在该access\_token（未废除）则调用成功；如果
token超时，中间件删除access\_token（废除）,同时生成新的access\_token并返回。客户端收到新的
access_token，
再次请求接口资源。
3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token（废除）)，同时清
空客户端侧的access_token。
4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长
时间未登录，频繁刷新）
5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。
4.0 变动
1.登录
2.登录拦截器
3.退出登录
4.修改密码
## 最终实现
### 后端
1. 在登录接口中 如果校验账号密码成功 则根据用户id和用户类型创建jwt token(有效期设置为-1，即永不过期),得到A
2. 更新登录日期(当前时间new Date()即可)（业务上可选），得到B
3. 在redis中缓存key为ACCESS_TOKEN:userId:A(加上A是为了防止用户多个客户端登录 造成token覆盖),value为B的毫秒数（转换成字符串类型），过期时间为7天（7 * 24 * 60 * 60）
4. 在登录结果中返回json格式为{"result":"success","token": A}
5. 用户在接口请求header中携带token进行登录，后端在所有接口前置拦截器进行拦截，作用是解析token 拿到userId和用户类型（用户调用业务接口只需要传token即可），
如果解析失败（抛出SignatureException），则返回json（code = 0 ,info= Token验证不通过, errorCode = '1001'）；
此外如果解析成功，验证redis中key为ACCESS_TOKEN:userId:A 是否存在 如果不存在 则返回json（code = 0 ,info= 会话过期请重新登录, errorCode = '1002'）；
如果缓存key存在，则自动续7天超时时间（value不变），实现频繁登录用户免登陆。
6. 把userId和用户类型放入request参数中 接口方法中可以直接拿到登录用户信息
7. 如果是修改密码或退出登录 则废除access_tokens（删除key）
### 前端（VUE）
1. 用户登录成功，则把username存入cookie中，key为loginUser;把token存入cookie中，key为accessToken
把token存入Vuex全局状态中
2. 进入首页
6. 前端怎么解析json
不建议使用eval（）函数，因为eval（）接受任意的字符串，并当作JavaScript代码来处理,这个机制已经有安全隐患了var str='{ "name": "John" }';var obj = eval ('(' + str + ')');alert(obj.name); $.parseJSON()和JSON.parse()函数用于将格式完好的JSON字符串转为与之对应的JavaScript对象。所谓"格式完好"，就是要求指定的字符串必须符合严格的JSON格式，例如：属性名称必须加双引号、字符串值也必须用双引号。其次，JSON标准不允许字符串中出现"控制字符"，正确写法应该是使用两个反斜杠，以免被JS解析器直接转义。 1、JSON字符串转换为JSON对象var str='{ "name": "John" ,"age": "24" }';var obj = $.parseJSON(str);alert(obj.name); //John var str = '{ "name": "John", "age": "24" }';var obj = JSON.parse(str);alert(obj.name); //John 2、将JSON对象转换为字符串var obj={name: "John", age: "24"};var last=JSON.stringify(obj);alert(last); //'{name: "John", age: "24"}' var obj={name: "John", age: "24"};var last=obj.toJSONString();alert(last); //'{name: "John", age: "24"}' 3、解析读取json对象var str={ "result":{ "age":"33", "id":"2server", "name":"mady" }};alert(str.result.age); //33 var result = $.parseJSON( '[ 1, true, "CodePlayer" ]' );alert( result[1] ); // CodePlayer var result = $.parseJSON( "\"专注于编程开发技术分享\"" );alert(result); //专注于编程开发技术分享
7. Springboot security oauth2 jwt实现权限控制，实现微服务获取当前用户信息
在原先bbo+zookeeper项目中，web模块只暴露Restful接口，各服务模块只暴露boo接口，此时用户登录后由web项目进行token的鉴权和验证，并通过bbo的隐式传参将sessionID传递给bbo服务模块, 拦截器再根据sessionID从Redis中获取用户信息设置到当前线程
然鹅，在springcloud中，各个微服务直接暴露的是restful接口，此时如何让各个微服务获取到当前用户信息呢？最佳的方式就是token了，token作为BS之间的会话标识（一般是原生随机token），同时也可以作为信息的载体传递一些自定义信息（jwt， 即Json web token）。
为了能更清楚的了解本文，需要对spring-security-oauth 及 jwt有一定了解，本文只关注用户信息传递这一块
认证服务器配置
自定义token转换器
CustomJwtAccessTokenConverter
此时按照固定格式访问授权服务器token接口获取token，如图，可以获取到jwt格式的token，并且额外信息nick_name也已经添加
直接解析jwt字符串可以获取到以下信息，即用户名和授权信息
只需要指定和授权服务器一模一样的token store 和token converter
在securiy的过滤器中 会从token中获取相关信息进行鉴权
源码：
注意，资源服务器主要配置在
微服务获取jwttoken中的用户信息，两种方式，使用security上下文可以直接获取当前用户名和权限，另一种自定义拦截器获取额外信息。
这个就简单了，获取header头解析验证token
然后获取之前从授权服务器中的添加的 nick_name的额外信息放入线程变量
其中用户上下文类
启动拦截器注册webmvc配置类
在controller中获取用户信息如图
在默认的认证异常如图
假设我们做了全局异常处理，前端希望在token过期时做统一的登录跳转如何做？
实现 AuthenticationEntryPoint 接口重写 commence 方法即可
注意，直接抛出异常并不会走 @RestControllerAdvice , 因为在这里是response直接返回，并没有使用到Controller处理
此时返回我自定义的Response对象，如图