django restful中的 Jwt

本文主要对是认证的总结概况，方便大家梳理这一块的知识流程和文档资源：

1.django官方文档 的会话技术

2.jwt的介绍官方地址   https://jwt.io/introduction/ 

3.pyjwt   https://github.com/jeromeguiard/pyjwt

4.djangorestframework-jwt https://github.com/Exirel/django-rest-framework-jwt/blob/master/docs/index.m

目录

一.概述

二.cookie，session和token

三.jwt的介绍和实现原理

四.python 中的jwt 第三方：

1.pyjwt 

2. djangorestframework-jwt

---

 

一.概述

在Web应用程序上实现身份验证时，我们通常以下方案，基于Cookie的身份验证使用服务器端Cookie来对每个请求进行用户身份验证。这意味着无论是在数据库还是Redis之类的会话存储中，都需要保留。主要由以下三个局限：

1. 储存在服务器上面的，会占用少量内存，如果网站用户非常多的话，会影响服务器的性能。
2. 第二点拓展性:如果网站比较大，需要搭建有多个服务器，但是session是保存在当前服务器的，其他服务器调用不到。
3. 第三点：:session是基于cookie进行识别的，容易被CSRF跨站请求伪造拦截。

 jwt和传统的token验证的区别时：数据不需要存储在服务端。

 

二.cookie，session和token

我们先来回顾总结一下django中cookie，session和token的特点：

cookie

使用简结，服务器压力小，数据不安全。

session（session+cookie）

服务端会话技术，数据存储再服务器中（比如redis，数据，文件。 默认存储到数据库中。   1.会话数据已签名但未被加密 当使用cookie后端时，会话数据可以被客户端读取。 MAC(消息验证代码) 被用来保护数据不被客户端修改，因此会话数据在被篡改时失效。如果存储cookie 的客户端 (比如浏览器) 不能存储所有会话数据并丢弃数据，则会同样发生失效。即使 Django 压缩数据，它仍然完全有可能每个 cookie 超过4096字节的通用限制。 2.不保证时效性 注意虽然 MAC 可以保证数据(通过站点生成，而不是其他人)真实性和数据完整(它是完整和正确的)，但它不能保证时效性，也就是说，您最后发送给客户端的东西会被退回。这意味着cookie后端为了使用一些会话数据，可能会面临重播攻击。与其他会话后端(每个会话保持服务端记录，并且当用户退出时使会话失效)不同，基于cookie的会话在用户退出的时候并不会让会话失效。因此攻击者窃取用户cookie，即使用户登出了，攻击者还可以使用cookie登录该用户。如果 Cookie 比