JWT认证阐述

脚本后续更新及迭代将由kkitDeploy项目代替
https://github.com/luckman666/kkitdeploy_server
请大家持续关注kkitDeploy

哥发达了，是时候实现一下儿时的梦想了，怡红院开起！

店面门脸装修如何？做生意，谁还没个镇店之宝啊？有请我的店长如花小姐！

没事哈！别怕，扭曲的五官往往都藏着一颗纯洁的心灵。

不管如何吧，我的怡红院算是开起来了。

附近各大有名的英俊才子，达官贵人，地痞流氓啥的蜂拥而至。火爆异常，由于我没有开店经验。过大的客流导致了一个问题。

“”哎呀老板呀！你是有所不知道呀！咱们店那可是贵宾旗舰店。那能让人随便进呀？所以要对每一个顾客进行登记，留存他们的信息，这样才能在他们进了咱们店之后，根据他们留的信息找到他们。所以大家都得排队登记哦！“

“哪不对呀，我看王公子刚才不是已经登记过了嘛？咋又跑前台去了？”

如花回到：“王公子，刚才出去了一趟，在出去的时候我们给了他一个临时暗号，他再进来的时候呢需要到前台报暗号，然后我们根据暗号翻账本找他的信息。所以他还得去前台核实身份信息！”

“what？老子开店是让顾客消费的，而你们却让顾客来回登记玩？赶紧给我想办法解决这个问题。”

这时，店内的一个新来的小职员说了：“老板我们何不给每个顾客定制一个VIP会员卡？把顾客的信息都记录在这个卡里面，然后顾客第一次来的时候就发放给他，以后他再来凭这个VIP卡就可以进店，无需登记啦！”，这小子是我年初招来的叫劲舞团，名字太怪了，我们还是简称叫他JWT吧！

“你这小屁孩，就瞎说，那万一顾客把卡借给别人呢？”如花愤愤的说到。如花是老员工从业经验丰富，这句话说得确实没错。

“哦！~没关系我这几天就在研究咱们店的情况，所以呢？我专门设计了这种VIP卡，二位还请慢慢听我说。”JWT慢条斯理的说。

这种卡分内的信息分三部分组成。

1、头部（Header）：

算法名称和tocken类型

2、有效存储区（Payload）：

这里面呢存储用户的相关信息，用户名啊，性别呀，年龄呀等等吧

3、防伪logo（Signature）

这里是根据前两个声明的信息，按照声明的方法，然后我们再混里咱们店独有的配方加密。保证别人都看不懂，只有我们店才能看懂。

拿一张图来说明吧！

“看到没？右侧就是那三部分的示例。

然后我们再设定这张卡的有效期，多久之后还得重新签发一次哦，这样就没问题啦，顾客在卡有效期内就不用老去前台啦！“JWT兴奋的说到。

如花被JWT如上一说也是沉吟许久没有说话。

“明天你全权负责这套认证机制，保证我们店顾客不要因为排队而放弃来我们店消费的念头”我对JWT说。

“谢谢老板，我马上就去办”JWT得到我的首肯后一溜烟的跑了。

上面这个故事就是我要对各位说的关于传统认证和JWT认证的区别：

由于http是无状态的，传统方式如何区别谁来了？谁走了呢？

1、传统认证客户端信息保留在服务器端的内存中，这里就是我们说的session,客户端下次再来需要拿着sessionID去内存查询相关信息。记得那个可怜的王公子嘛？他就是！而上面的前台客户及时我们说的服务器端的内存。

缺点：这样做的毛病就是客户端信息都放在服务器内存中，服务器不光要提供相关资源还得存储客户端信息。当数据越来越多的时候就会臃肿无比。这就是咱们常说的设计上的热点！

JWT就不一样了：当客户端第一次携带用户名密码请求认证成功后，会返回给他一个tocken。里面有其加密过后的对于该客户端描述信息。在以后访问任何接口只需要在API后边携带该tocken就可以正常使用其API了

我再写第三版devops时就是用的JWT认证方式，为了让大家看的更清晰我再上两个图：

首先访问loginAPI：

因为用的rest_framework写的，所以自带的API调试界面

然后我们输入正确的用户名密码，进行认证

再看上面的返回值：

这个tocken值就是上面那个JWT说的VIP会员卡。分三部分哦！每个部分有一个点分开：

 "token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxLCJ1c2VybmFtZSI6InJvb3QiLCJleHAiOjE1NTc1NDYzMTgsImVtYWlsIjoiMTIzQDEyMy5jb20ifQ.JRfA0t_Ft5229Bvg5gioLk2uoQ-0L30sl3MKGAqR_IQ"

至于每部分是什么？小职员JWT已经替我说清楚了。

行啦小伙伴们，是不是对JWT有了一定的了解呢？

我还没吃饭呐！先闪了！

记得来我店里玩哈！

关注公众号：