JWT-auth的原理以及laravel中tymon/jwt-auth的安装使用

引言

最近后端准备用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的功能流程？

说多都是废话，最烦技术文章废话多，全是复制的，直接上官网的流程图，一目了然：