3、Signature
三者组合在一起
Header.Payload.Signature
案例
看上去是不是满乱,我们来依次看下里面的结构。
Header
这个是JWT第一段数据,表示头部信息,主要的作用是描述JWT的元数据,上面的案例就是:
{
alg: “HS256”,
typ: “JWT”
}
1、alg属性表示签名的算法,默认算法为HS256,可以自行别的算法。
2、typ属性表示这个令牌的类型,JWT令牌就为JWT。
上面的JSON数据会通过Base64算法进行编码而成,看工具图
Payload
此为JWT第二段数据,用来存放实际需要传递的数据。JWT官方也规定了7个字段供选用
当然除了官方字段,我们可以自定义字段,以上面的案例,我们看下实际的数据
注意:这段也是用Base64算法,JWT默认是不加密的,任何人都可以获取,只要进行Base64解码就行了,所以不要把隐密的信息放到JWT中
Signature
此为JWT第三段数据,主要作用是对前面两段的数据进行签名,防止数据篡改。一般我们进行签名的时候会有个密钥(secret),只有服务器知道,然后利用Header中的签名算法进行签名,公式如下:
HMACSHA256(
base64UrlEncode(header) + “.” + base64UrlEncode(payload),
secret)
算出签名后,把Header、Payload、Signature三个部分拼成一个字符串,之间用(.)分隔,这样就可以把组合而成的字符串返回给用户了。
JWT的工作方式
在用户进行认证登录时,登录成功后服务器会返回一个JWT给客户端;那这个JWT就是用户的凭证,以后到哪里去都要带上这个凭证token。尤其访问受保护的资源的时候,通常把JWT放在Authorization header中。要用 Bearer schema,如header请求头中:
Authorization: Bearer
基于JWT的身份认证
上面的JWT的工作方式,其实就是一个完整的身份认证流程,我们这里把这个讲的在通俗一点。
1、用户提供用户名和密码登录
2、服务器校验用户是否正确,如正确,就返回token给客户端,此token可以包含用户信息
3、客户端存储token,可以保存在cookie或者local storage
4、客户端以后请求时,都要带上这个token,一般放在请求头中
5、服务器判断是否存在token,并且解码后就可以知道是哪个用户
6、服务器这样就可以返回该用户的相关信息了
这个流程小伙伴们有没有发现,用户信息是放在JWT中的,是存放在客户端(cookie,local storage)中的,服务器只需解码验证就行了,就可以知道获取到用户信息。而我们之前的Session方式就不一样。
与Session-Cookie方式的区别
Session-Cookie方式的这里就不多作介绍了,之前文章已经介绍了。直接上图说明区别
上图是Sesson服务器方式,我们发现Session用户信息是在服务器端存储的。
我们再来看看JWT方式
我们再来看看JWT方式
[外链图片转存中…(img-5UL75IRJ-1646115542611)]