SpringCloud之JWT

登录状态

有状态登录

即服务端需要记录每次会话的客户端信息，从而识别客户端身份，根据用户身份进行请求的处理.
典型的设计如tomcat中的session。

• 缺点是什么？
  服务端保存大量数据，增加服务端压力
  客户端请求依赖服务端，多次请求必须访问同一台服务器。

无状态登录

无状态服务，服务端不保存任何客户端请求者信息，客户端的每次请求必须具备自描述信息，通过这些信息识别客户端身份。

• 优点是什么呢？
  减小服务端存储压力
  客户端请求不依赖服务端的信息，任何多次请求不需要必须访问到同一台服务

【说明】如果用session的话。有3台服务器A、B、C组成服务器集群，session存在A上，则B、C就无法访问成功。
【说明】如果用token的话。三台服务器只需要使用token验证用户的合法性就OK了，不存在服务器限制。

JWT(Json Web Token)

顾名思义，JWT就是以Json格式在Web中传递信息的令牌。
JWT的非对称加密

JWT三部分

header.payload.signature。

header

{
“typ”: “JWT”,
“alg”: “HS256”
}

• typ(type):声明类型
• alg(algorithm):JWT的签名算法

用Base64对这个JSON编码就得到JWT的第一部分

payload 负载

{
“iss”: “Online JWT Builder”,
“iat”: 1416797419,
“exp”: 1448333419,
“aud”: “www.gusibi.com”,
“sub”: “uid”,
“nickname”: “goodspeed”,
“username”: “goodspeed”,
“scopes”: [ “admin”, “user” ]
}

• iss: 该JWT的签发者，是否使用是可选的；
• iat(issued at):在什么时候签发的(UNIX时间)，是否使用是可选的；
• exp(expires): 什么时候过期，这里是一个Unix时间戳，是否使用是可选的；
• aud: 接收该JWT的一方，是否使用是可选的；-
• sub: 该JWT所面向的用户，是否使用是可选的；
• jti：JWT 的唯一身份标识，主要用来作为一次性 token，从而回避重放攻击。

base64 加密之后得到 JWT 的第二部分信息。

signature 数字签名

要签名我们要有secret，就是一个字符串（密钥）。
将前两部分编的码用秘钥和第一部分的签名算法结合可以得到signature。

var encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload);
// 这里的 HMACSHA256() 就是我们在第一部分定义的加密算法。
var signature = HMACSHA256(encodedString, 'secret');

签名是用于验证消息在传递过程中有没有被更改。

将这三个部分用 . 连接成一个完成的字符串就得到了最终的 JWT。

JWT使用

当客户端第一次请求服务时，需要登陆他的账户。
客户端就发送账号密码，服务端对用户进行信息认证（登录）。
认证微服务验证通过后，就会将一个有效负载（payload）和一个密钥创建成一个令牌（Token），并返回给客户端。
以后每次请求，客户端都携带认证的token，客户端会将这个令牌放在请求头的 x-access-token。
这时只需要Zuul网关对token进行解密过滤，无需再回到鉴权中心。

令牌验证

• 客户端向服务器请求，服务端读取请求头信息(request.header)获取Token
• 如果找到Token信息，则根据配置文件中的签名加密秘钥，调用JJWT Lib对Token信息进行解密和解码；
• 完成解码并验证签名通过后，对Token中的exp、nbf、aud等信息进行验证；
• 全部通过后，根据获取的用户的角色权限信息，进行对请求的资源的权限逻辑判断；
• 如果权限逻辑判断通过则通过Response对象返回；否则则返回HTTP 401；

token刷新

每当用户在页面操作就应该刷新token的过期时间。也就是每当用户查询其个人信息时刷新token，写入cookie。

JWT缺点

• 无法作废已颁布的令牌，因为所有的认证信息都在JWT中，由于在服务端没有状态，即使你知道了某个JWT被盗取了，你也没有办法将其作废。