DRFJWT自证-CSDN博客

本文链接：https://blog.csdn.net/m0_58310590/article/details/138992163

jwt（重点）

【 1 】cookie的执行原理

1.2 Cookie 工作原理

浏览器向服务器发送请求，服务器需要创建cookie，服务器会通过响应携带cookie，在产生响应时会产生Set-Cookie响应头，从而将cookie信息传递给了浏览器；
当浏览器再次向服务器发送请求时，会产生cookie请求头，将之前服务器的cookie信息再次发送给了服务器，然后服务器根据cookie信息跟踪客户端状态。

【 2 】session的执行原理

执行流程:

用户第一次请求服务器时，服务器端会生成一个sessionid
服务器端将生成的sessionid返回给客户端，通过set-cookie
客户端收到sessionid会将它保存在cookie中，当客户端再次访问服务端时会带上这个sessionid
当服务端再次接收到来自客户端的请求时，会先去检查是否存在sessionid，不存在就新建一个sessionid重复1,2的流程，如果存在就去遍历服务端的session文件，找到与这个sessionid相对应的文件，文件中的键值便是sessionid，值为当前用户的一些信息
此后的请求都会交换这个 Session ID，进行有状态的会话。

##全称是：json web token

-是一种前后端登陆认证的方案，区别于之前的 cookie，session
-它有签发阶段–》登陆成功后签发
-它有认证阶段–》需要登陆后才能访问的接口，通过认证后，才能继续操作

【 3 】jwt的执行原理

什么是jwt

JSON Web Token (JWT) 是一种开放标准，它定义了一种紧凑且独立的方式，用于在各方之间以 JSON 对象的形式安全地传输信息。该信息可以被验证和信任，因为它是经过数字签名的。官网Jwt.io

它是一个很长的字符串，中间用点（.）分隔成三个部分。注意，JWT 内部是没有换行的，这里只是为了方便展示，而将它写成了几行。

【 4 】Header（头信息）

Header的主要作用是用来标识。通常是两部分组成：

typ：type 的简写，令牌类型，也就是JWT。
alg：Algorithm 的简写，加密签名算法。一般使用HS256，jwt官网提供了12种的加密算法：

一般我们用HS256

Header的明文示例：

import json
import base64

# 定义 JSON 对象
data = {
    "alg": "HS256",
    "typ": "jwt"
}

# 将 JSON 对象转换为 JSON 字符串
json_str = json.dumps(data)

# 对 JSON 字符串进行 UTF-8 编码
utf8_bytes = json_str.encode('utf-8')

# 对 UTF-8 编码的字符串进行 Base64 编码
base64_encoded = base64.b64encode(utf8_bytes)

# 打印 Base64 编码结果
print(base64_encoded.decode('utf-8'))

经过Base64编码之后的明文，变为：

eyJhbGciOiJIUzI1NiIsInR5cCI6Imp3dCJ9

也就是第一个.之前的密文串。以下是Header部分常用部分的声明：

key	name	说明
typ	令牌类型	如果存在，则必须将其设置为已注册的 IANA 媒体类型。
cty	内容类型	如果使用嵌套签名或加密，建议将其设置为 ;否则，请省略此字段。
alg	消息身份验证代码算法	发行者可以自由设置算法来验证令牌上的签名。但是，某些受支持的算法不安全。
kid	密钥标识	指示客户端用于生成令牌签名的密钥的提示。服务器将此值与文件上的密钥匹配，以验证签名是否有效以及令牌是否真实。
x5c	x.509 证书链	RFC4945 格式的证书链，对应于用于生成令牌签名的私钥。服务器将使用此信息来验证签名是否有效以及令牌是否真实。
x5u	x.509 证书链网址	服务器可在其中检索与用于生成令牌签名的私钥对应的证书链的 URL。服务器将检索并使用此信息来验证签名是否真实。
crit	危急	服务器必须理解的标头列表，以便接受令牌为有效令牌

【 5 】Payload（负载信息）

也称为JWT claims，放置需要传输的信息，有三类：

保留claims：主要包括iss发行者、exp过期时间、sub主题、aud用户等。
公共claims：定义新创的信息，比如用户信息和其他重要信息。
私有claims：用于发布者和消费者都同意以私有的方式使用的信息。

以下是Payload的官方定义内容：

key	name	说明
iss	发送者	标识颁发 JWT 的发送主体。
sub	主题	标识 JWT 的主题。
aud	接收者	标识 JWT 所针对的接收者。每个在处理 JWT 的主体都必须使用受众声明中的值来标识自己。如果处理的主体在存在此声明时未将自己标识为声明中的值，则必须拒绝 JWT。
exp	到期时间	标识不得接受 JWT 进行处理的过期时间。该值必须是日期类型，而且是1970-01-01 00：00：00Z 之后的日期秒。
nbf	jwt的开始处理的时间	标识 JWT 开始接受处理的时间。该值必须是日期。
iat	jwt发出的时间	标识 JWT 的发出的时间。该值必须是日期。
jti	jwt id	令牌的区分大小写的唯一标识符，即使在不同的颁发者之间也是如此。

JWT 的三个部分依次如下。

Header（头部）第一段：头 header {“alg”:“HS256”,“typ”:“JWT”}
- 一般放：公司信息，加密方式，是jwt，一般都是固定的
  -Doe",“admin”:true}
Payload（负载）第二段：荷载 payload {“sub”:“1234567890”,“name”:"John
- -一般放：登录用户的信息：用户名，用户id，过期时间，签发时间，是否是超级用户。
Signature（签名）
- 第三段：签名 signature 二进制数据

【 6 】jwt的工作流程

用户使用凭据（例如用户名和密码）登录到服务器。
服务器验证用户的凭据，生成一个包含用户信息的 JWT 并返回给客户端。
客户端将 JWT 存储在本地（通常是在浏览器的本地存储或 Cookie 中）。
客户端在每个请求中使用该 JWT 来验证身份和授权。
服务器接收到请求时，使用密钥对 JWT 进行验证和解码，并检查其中的信息是否有效和可信。

如果 JWT 验证通过，服务器处理请求并返回响应。如下图：

【 7 】jwt的优缺点

优点：

可扩展性好 应用程序分布式部署的情况下，如果使用session机制，那就要要做多台机器的数据共享，通常可以存在数据库或者redis里面。而使用jwt不需要共享。
jwt是无状态的 jwt不在服务端存储任何状态。RESTful API的原则之一是无状态，发出请求时，总会返回带有参数的响应，不会产生附加影响。用户的认证状态引入这种附加影响，这破坏了这一原则。另外jwt的载荷中可以存储一些常用信息，用于交换信息，有效地使用 JWT，可以降低服务器查询数据库的次数。

缺点：