登录状态
有状态登录
即服务端需要记录每次会话的客户端信息,从而识别客户端身份,根据用户身份进行请求的处理.
典型的设计如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被盗取了,你也没有办法将其作废。