分布式统一授权方案JWT

分布式统一授权方案

一、微服务架构下的统一授权

为了识别客户端的身份，并且能够保存这个身份的状态，基于HTTP的无状态协议实现方案：

• 浏览器的Cookie（disk / mem），客户端的状态存储
• 服务器端的session（服务端的状态存储）

但是会话在分布式集群模式下会丢失

二、Session Sticky

• IPHASH |hash(ip)|%目标服务器的数量=目标服务器的地址
• HASH算法， MD5 、SHA-1 、SHA-256
• 一致性hash算法，虚拟节点构建hash环

缺点：

1. 如果有一台服务器宕机或者重启，那么这台机器上的会话数据会全部丢失
2. 负载均衡器将变成一个有状态的节点，要将会话保存到具体Web服务器的映射。和无状态节点相比，内存消耗更大，容灾方面也会更麻烦

三、Session统一存储

缺点：

1. 读写Session数据是网络IO操作，这相对于本机的数据读取，存在时延和不稳定性，通信发生在内网，则问题不大。
2. 如果存储Session的组件或集群出现问题，则会影响应用。

四、Session Replication（复制）

session复制，通过相关技术实现session复制，使得集群中的各个服务器相互保存各自节点存储的session数据。tomcat本身就可以实现session复制的功能，基于IP组播放方式。

缺点：

1. 同步session数据会造成网络开销，随着集群规模越大，同步session带来的带宽影响也越大
2. 每个节点需要保存集群中所有节点的session数据，就需要比较大的内存来存储。

五、JWT（JSON Web Token）

JWT token由三个部分组成，头部（header）、有效载荷（payload）、签名（signature）。参考官网

5.1、header

header部分由 typ 和 alg 组成，typ的全称是(type，类型)、alg全称（algorithm，算法），类型可以自己定义，没有限制。而alg： HS256，表示当前的token是使用HS256算法来进行加密的。

Header部分的数据，是通过base64位进行编码

5.2、payLoad

Payload 里面是 Token 的具体内容，也是一个json字符串，这些内容里面有一些是标准字段，你也可以添加其它需要的内容；

它的json结构实际上是对JWT要传递的数据的一组声明，这些声明被JWT标准称为claims , JWT默认提供了一些标准的Claim，具体内容如下。

• iss(Issuser)：代表这个JWT的签发主体；
• sub(Subject)：代表这个JWT的主体，即它的所有人；
• aud(Audience)：代表这个JWT的接收对象；
• exp(Expiration time)：是一个时间戳，代表这个JWT的过期时间；
• nbf(Not Before)：是一个时间戳，代表这个JWT生效的开始时间，意味着在这个时间之前验证JWT 是会失败的；
• iat(Issued at)：是一个时间戳，代表这个JWT的签发时间；
• jti(JWT ID)：是JWT的唯一标识。

同样，payLoad中的数据，也是拼接好之后，通过base64进行编码，得到一个目标字符串

5.3、signature

signature表示签名，它的组成是：signature=HS256(base64(header)+"."+base64(payload),secret_key)

这里需要指定一个secret_key：

secret_key**是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，所以，它在任何场景都不应该流露出去。一旦客户端得知这个secret_key, 那就意味着客户端是可以自我签发jwt了。

最后JWT完整的字符串构成了JWT：base64(header)+”.”+base64(payload)+”.”+sinature 。

5.4、JWT 流程

1. 客户端通过用户名和密码登录服务器；
2. 服务端对客户端身份进行验证；
3. 服务端对该用户生成Token，返回给客户端；
4. 客户端将Token保存到本地（缓存或者浏览器）；
5. 客户端发起请求，需要携带该Token；
6. 服务端收到请求后，首先验证Token是否合法，然后返回数据。

优点：

• 安全、无状态、可扩展
• 可提供接口给第三方服务
• 多平台跨域

目前主流的微服务架构下的统一授权方案都是JWT。