基于token机制鉴权架构

常见的鉴权方式有两种，一种是基于session，另外一种是基于token方式的鉴权，咱们来浅谈一下两种 鉴权方式的区别。

两种鉴权方式对比

session

1. 安全性：session是基于cookie进行用户识别的，cookie若是被截获，用户很容易受到跨站请求伪造的攻击。
2. 扩展性：session是有状态的，是具备IP黏贴性和有中心化特性的，在分布式环境下，虽然每台服务器业务逻辑同样，可是session是保存在各个服务器中的，并且每一个服务器内存是不共享的，若是使用session去实现分布式部署的话，须要使用其余的一些技术手段去实现，好比spring session，将session保存在第三方服务中，好比redis，这样一旦第三方服务出现问题，整个验权系统就会奔溃，在电商系统及高并发系统中的集群化处理显然是不合适的。
3. 抗压能力：一般session是存储在内存中的，每一个用户经过认证后都会将session存储在服务器内存中，当用户量增大的状况下服务器的压力也随之增大。

token

1. 安全性：浏览器会将接收到的token值存储在Local Storage中，（经过js代码写入Local Storage，经过js获取，并不会像cookie同样自动携带）
2. 扩展性：token是无状态的，是去中心化的，在分布式环境下，各个服务器中的服务只对token进行数据查询，它不须要在服务端保留用户信息或者会话信息，这意味着用户不须要考虑登陆的是哪一台服务器，高效的解决了session扩展性的弊端。
3. 抗压能力：token与session的不一样主要在认证成功后，会对当前用户数据进行加密，生成一个加密字符串token，返还给客户端（服务器端并不进行保存）

基于token的鉴权方式

业界经常使用的受权标准有两种，一种是使用auth2，这种方式更适合于相似第三方受权登陆，好比微信、微博、QQ信任登陆业务。另外一种是oauth，即第三方无需知道用户和密码就能够申请得到该资源的受权，更适用于对用户的权限校验并分配访问权限，好比常见的登陆后分配可见资源（按钮、菜单等）类型网站。

Javashop电商系统 采用的是oauth方式的鉴权标准。咱们以系统的应用为例来介绍oauth的方案。

 

1. 登陆
服务端校验密码，成功后返回access_token和refresh_token，客户端记录上述token。
2. 访问API
在访问API以前解析access_token，而且查看是否过时，若是不过 期则请求API，若是过时，则要刷新令牌，在请求API。
3. 刷新token
携带有效期的refresh_token换回有效token，若是refresh_token过时，则须要用户从新登陆。
4. 注销
请求注销api，服务器端和客户端应同时删除token的存储。

 

1. 客户端请求API
携带access_token信息，若是生成环境不会直接携带access_token，会使用加密后的签名校验。祥见如下防重放机制。
2. 获取token
根据环境不一样而有不一样的获取token方式。
3. 解析token
经过JWT工具将token解析。
4. 由redis读取token
根据uid拼接key读取access_token, 若是不存在这个用户的token说明已经登出。
5. 验证token
判断次token是否属于此uid，判断token是否过时，若是过时则进行如下刷新token的流程。
6. 注入权限
若是token验证成功，根据user信息生成权限注入到spring安全上下文中。

 

 

 

刷新token流程

 

 

 

1. 客户端请求API
携带refresh_token，若是是生产环境不会直接携带refresh_token信息，详见如下防重放攻击。
2. 获取token
根据环境不一样而有不一样的获取token方式。
3. 解析token
经过JWT工具将token解析。
4. token读取
根据uid拼接key读取出access_token，若是不存在这个用户的token说明用户已经登出。
5. 验证token
判断此token是否属于此uid，判断token是否已通过期，若是过时，则返回refresh_token过时错误，此时用户须要从新登陆。
6. 刷新token
若是refresh_token 验证成功，则从新生成access_token和refresh_token，上述有效期以当前时间向后计算，替换此用户在redis中的token，并将token返回给客户端。

 

防重放机制

 

 

 

1、 参数的读取
1. 在生产环境时，不能直接传递token,而是要传递签名数据，服务器端验签后由Redis中获取签名。
2. 若是是非生产环境，直接由header中读取token。
2、 生产环境传递以下参数
memberid (用户id)
nonce（随机字串，6位）
timestamp(当前时间戳，到秒)
sign= md5( uid+ nonce + timestamp +token )
3、 验证逻辑
1. 验证时间戳
判断时间戳是否起过60s，大于60s则判别为重放攻击。

2. 验证nonce
首先验证nonce在 reids中是否存在，若是存在，则判别为重放攻击，不然将nonce记录在redis中（key为："nonce"+uid+"_"+nonce），失效时间为60s。
3. 验证sign
md5( uid+ nonce + timestamp +token ) 验证是签名是否经过。
4. 验证token
经过uid拿到token ，验证逻辑同验权流程。

 

 

固然在不一样的业务场景下实现方案是多种多样的，仅以此方案抛砖引玉，供你们参考。 

易族智汇（javashop）原创文章