引言
最近后端准备用laravel来编写一个微信小程序的后端,那么首先涉及到的就是用户登录授权访问后端api的逻辑实现,之前还自己封装点token验证的类来处理登录状态,但是一接触laravel,就知道了tymon/jwt-auth的鼎鼎大名。那就必须来探究和学习一下了。
一.JWT auth知识及原理
想在laravel中使用tymon/jwt-auth之前,有些概念我们必须要学习。下面我将用自己的语言来描述一下。
1.什么是所谓的token?
我们都知道http协议是无状态的协议,unstate,这些都不再赘述,为了记录用户在http通信过程中的状态,我们的前人也是想尽了办法,比如:在客户端使用cookie,在服务端使用session等等方法。
近年来,前后端的代码,服务都已经分离,前端一般都是调用后端接口进行数据的获取和处理,在调用后端api的过程中,我们需要调用的凭证,这个凭证就是token。也就是用户首先登陆认证之后,后端会给api调用者一个token凭证,客户端手握这个token进行接下来的接口调用。这就是token。
2.什么是JWT?
一般情况下,token返回客户端之后,会被客户端记录在cookie或者文件缓存之中,在后端,也需要相应的对应记录,以用来验证。这就是最早的token记录验证方法:比对验证,这种方法在后端将token一般记录在session,文件缓存,或者redis,mysql数据表中。随着应用业务的增大,服务器会进行分布式部署,数据表会进行分表处理,这个时候,记录对比型的token在查找验证过程中就显得力不从心。那该怎么客服这个弊端呢?
JWT auth就来了。JWT从原理上更改了token的使用流程。JWT的全称是json web token。字面意思就是json形式的网络token。当然在网络中传输时不可能是明文的json数据了。那为什么要说是json形式的呢?
这就要明白JWT工作流程的核心就是加密和解密。token的验证其实就是一个token数据还原的过程。JWT的核心思想就是将某个json形式的数据进行加密,形成密文,该密文就是token,发送给客户端,客户端进行记录,当客户端传至后端时,后端根据相应的解密方法进行解密,如果能够成功正常解密,则证明该token是正确的且经过授权的。
JWT的数据结构
典型的,一个JWT看起来如下图。
该对象为一个很长的字符串,字符之间通过"."分隔符分为三个子串。注意JWT对象为一个长字串,各字串之间也没有换行符,此处为了演示需要,我们特意分行并用不同颜色表示了。每一个子串表示了一个功能块,总共有以下三个部分:
JWT的三个部分如下。JWT头、有效载荷和签名,将它们写成一行如下。
我们将在下面介绍这三个部分。
JWT头
JWT头部分是一个描述JWT元数据的JSON对象,通常如下所示。
{
“alg”: “HS256”,
“typ”: “JWT”
}
在上面的代码中,alg属性表示签名使用的算法,默认为HMAC SHA256(写为HS256);typ属性表示令牌的类型,JWT令牌统一写为JWT。
最后,使用Base64 URL算法将上述JSON对象转换为字符串保存。
有效载荷
有效载荷部分,是JWT的主体内容部分,也是一个JSON对象,包含需要传递的数据。 JWT指定七个默认字段供选择。
iss:发行人
exp:到期时间
sub:主题(一般记录生成token用户信息的数据库记录主键)
aud:用户
nbf:在此之前不可用
iat:发布时间
jti:JWT ID用于标识该JWT
除以上默认字段外,我们还可以自定义私有字段,如下例:
{
“sub”: “1234567890”,
“name”: “wanglihong”,
“admin”: true
}
请注意,默认情况下JWT是未加密的,任何人都可以解读其内容,因此不要构建隐私信息字段,存放保密信息,以防止信息泄露。
JSON对象也使用Base64 URL算法转换为字符串保存。
签名哈希
签名哈希部分是对上面两部分数据签名,通过指定的算法生成哈希,以确保数据不会被篡改。
首先,需要指定一个密码(secret)。该密码仅仅为保存在服务器中,并且不能向用户公开。然后,使用标头中指定的签名算法(默认情况下为HMAC SHA256)根据以下公式生成签名。
HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload),secret)
在计算出签名哈希后,JWT头,有效载荷和签名哈希的三个部分组合成一个字符串,每个部分用"."分隔,就构成整个JWT对象。
Base64URL算法
如前所述,JWT头和有效载荷序列化的算法都用到了Base64URL。该算法和常见Base64算法类似,稍有差别。
作为令牌的JWT可以放在URL中(例如api.example/?token=xxx)。 Base64中用的三个字符是"+","/“和”=",由于在URL中有特殊含义,因此Base64URL中对他们做了替换:"=“去掉,”+“用”-“替换,”/“用”_"替换,这就是Base64URL算法,很简单把。
3.JWT有什么优点?
1.JWT token不用一直记录在后端,节约了存储空间,只需要在后端获取之后进行解密即可进行授权核验流程。
2.不需要针对分部署的服务端部署浪费额外的资源,不管是在哪个主,从服务器上,只要有解密算法,就可以对jwt token进行验证。
3.jwt token本身就是可用数据,载荷payload(包含token的相关信息及自定义数据)以及token拥有客户端的用户信息。而对比验证型的数据就只是一个token而已,一个对比的凭证。
4.JWT有什么缺点?
1.JWT默认不加密,但可以加密。生成原始令牌后,可以使用该令牌再次对其进行加密。
2.当JWT未加密方法时,一些私密数据无法通过JWT传输。
5.JWT的功能流程?
说多都是废话,最烦技术文章废话多,全是复制的,直接上官网的流程图,一目了然: