基于JWT的token身份认证方案（转）

https://www.cnblogs.com/xiangkejin/archive/2018/05/08/9011119.html

 

1、使用JSON Web Token的好处？

1.性能问题。

JWT方式将用户状态分散到了客户端中，相比于session，能够明显减轻服务端的内存压力。

Session方式存储用户id的最大弊病在于Session是存储在服务器端的，因此须要占用大量服务器内存，

对于较大型应用而言可能还要保存许多的状态，通常还需借助nosql和缓存机制来实现session的存储，若是是分布式应用还需session共享。 

2.单点登陆。

JWT能轻松的实现单点登陆，由于用户的状态已经被传送到了客户端。

token 可保存自定义信息，如用户基本信息，web服务器用key去解析token，就获取到请求用户的信息了。

咱们也能够配置它以便包含用户拥有的任何权限。这意味着每一个服务不须要与受权服务交互才能受权用户。

3.先后端分离。

之前的传统模式下，后台对应的客户端就是浏览器，就可使用session+cookies的方式实现登陆，

可是在先后分离的状况下，后端只负责经过暴露的RestApi提供数据，而页面的渲染、路由都由前端完成。由于rest是无状态的，所以也就不会有session记录到服务器端。

4.兼容性。

支持移动设备，支持跨程序调用，Cookie 是不容许垮域访问的，而 Token 则不存在这个问题。

5.可拓展性。

jwt是无状态的，特别适用于分布式站点的单点登陆（SSO）场景。

好比有3台机器（A、B、C）组成服务器集群，若session存在机器A上，session只能保存在其中一台服务器，此时你便不能访问机器B、C，由于B、C上没有存放该Session，

而使用token就可以验证用户请求合法性，而且我再加几台机器也没事，因此可拓展性好。

6.安全性。由于有签名，因此JWT能够防止被篡改。

2、JSON Web Token是什么？

JWT是基于token的身份认证的方案。

json web token全称。能够保证安全传输的前提下传送一些基本的信息，以减轻对外部存储的依赖，减小了分布式组件的依赖，减小了硬件的资源。

可实现无状态、分布式的Web应用受权，jwt的安全特性保证了token的不可伪造和不可篡改。

本质上是一个独立的身份验证令牌，能够包含用户标识、用户角色和权限等信息，以及您能够存储任何其余信息（自包含）。任何人均可以轻松读取和解析，并使用密钥来验证真实性。

 

缺陷：

1）JWT在生成token的时候支持失效时间，可是支持的失效时间是固定的，好比说一天。

可是用户在等出的时候是随机触发的，那么咱们jwt token来作这个失效是不可行的，由于jwt在初始化的时候已经定死在何时过时了。

采用其余方案，在redis中存储token，设置token的过时时间，每次鉴权的时候都会去延长时间

2）jwt不适合存放大量信息，信息越多token越长

 

JWT就是一个字符串，通过加密处理与校验处理的字符串，形式为：

    A.B.C

A由JWT头部信息header加密获得
B由JWT用到的身份验证信息json数据加密获得
C由A和B加密获得，是校验部分

分别是头部、载荷、签名。 
头部部分header 
{ 
“alg”: “HS256”, 
“typ”: “JWT” 
} 
alg描述的是签名算法。默认值是HS256。

将header用base64加密，获得A。

 

载荷部分payload 
{ 
“iss”: “发行者”, 
“sub”: 主题”, 
“aud”: “观众”， 
“exp”:”过时时间”, 
“iat”:”签发时间” 
如下能够添加自定义数据 
“id”:”1”, 
“nickname”:”昵称” 
} 

根据JWT claim set[用base64]加密获得的。claim set是一个json数据，是代表用户身份的数据，可自行指定字段很灵活，也有固定字段表示特定含义（但不必定要包含特定字段，只是推荐）。
Base64算法是可逆的，不能够在载荷部分保存用户密码等敏感信息。若是业务须要，也能够采用对称密钥加密。

 

签名部分signature 
HMACSHA256(Base64(Header) + “.” + Base64(Payload), secret)，secret是加密的盐。
签名的目的是用来验证头部和载荷是否被非法篡改。 
验签过程描述：获取token值，读取Header部分并Base64解码，获得签名算法。根据以上方法算出签名，若是签名信息不一致，说明是非法的。

 

3、JSON Web Token工做原理

1. 初次登陆：用户初次登陆，输入用户名密码

2. 密码验证：服务器从数据库取出用户名和密码进行验证

3. 生成JWT：服务器端验证经过，根据从数据库返回的信息，以及预设规则，生成JWT

4. 返还JWT：服务器的将token放在cookie中将JWT返还

5. 带JWT的请求：之后客户端发起请求，带上cookie中的token信息。

 

4、jwt+redis的登陆方案流程：

• 前端服务器收到用户登陆请求，传给后台API网关。

• API网关把请求分发到用户服务里进行身份验证。

• 后台用户服务验证经过，而后从帐号信息抽取出userName、login_time等基本信息组成payload，进而组装一个JWT，把JWT放入redis(由于退出的时候没法使jwt当即做废，因此使用保存在redis中，退出的时候delete掉就能够了，鉴权的时候加一层判断jwt是否在redis里，若是不在则证实jwt已过时做废)，而后包装cookie中返回到前端服务器，这就登陆成功了。

• 前端服务器拿到JWT，进行存储（能够存储在缓存中，也能够存储在数据库中，若是是浏览器，能够存储在 localStorage 中，我实现的是放入到cookie里面）

• 登陆后，再访问其余微服务的时候，前端会携带jwt访问后台，后台校验 JWT，验签经过后，返回相应资源和数据就能够了。

 

（这里没有将redis画出来）

 

结合拦截器与上篇session-cookie方式的区别：

首次登陆步骤：

1.首先AuthInterceptor拦截器拦截用户请求，在preHandle中看cookie中是否有token信息，没有就接着拦截器AuthActionInterceptor拦截须要登陆的url，看threadlocal当中是否有user对象，若是没有就跳转到登陆页面进行登陆，登陆成功后会将user对象放到threadlocal中。（注意这个地方和上篇中提到的登陆成功后将user放到session的不一样）

登陆处理流程：在数据库中查询验证用户名密码，经过就讲帐号信息抽取出username、email等信息组成一个payload，进而组装成一个JWT，而后将JWT放到redis当中，设置过时时间。

生成token：

给定签名算法、给定载荷的map、进行签名

2.当业务逻辑处理完以后在AuthInterceptor的postHandle中，从threadlocal获取user对象中的token信息，将token放到cookie中返回给前端。

3.请求结束后在AuthInterceptor的afterCompletion将user从threadlocal中移除。

 

验证流程：

前端将携带jwt的cookie传到后台，AuthInterceptor会根据token验证解析出user，（注意根以前在session中取对象的不一样）验证后再将user放到threadlocal中，AuthActionInterceptor一看threadlocal有user对象，直接经过。后面的步骤同样。

验证token：

1）从token的Header中拿出签名算法，看和以前生成token的签名算法是否一致。

2）验证签名，获取载荷map，从中获取用户标识email，在redis中看是否失效，若是失效，抛出未登陆错误；若是未失效，更新redis的失效时间，返回用户的信息。

AuthInterceptor

  View Code

AuthActionInterceptor

  View Code

 UserService

  View Code

 JWTHelper

  View Code