52 lines
2.9 KiB
Markdown
52 lines
2.9 KiB
Markdown
|
## JWT
|
|||
|
|
|
|||
|
|
JSON Web Token (JWT)是一个开放标准(RFC 7519)，它定义了一种紧凑的、自包含的方式，用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任，因为它是数字签名的。
|
|||
|
|
|
|||
|
|
由于其轻量级和易于使用的特性，JWT在现代的Web应用中非常流行，尤其是在需要跨域认证的场景中。
|
|||
|
|
|
|||
|
|
### JWT的组成
|
|||
|
|
|
|||
|
|
JWT由三部分组成，用点`.`分隔，形成`header.payload.signature`的结构：
|
|||
|
|
|
|||
|
|
1. **Header（头部）**：通常由两部分组成：算法（alg）和令牌类型（typ）。例如：`{"alg":"HS256","typ":"JWT"}`。
|
|||
|
|
|
|||
|
|
2. **Payload（负载）**：包含所谓的“Claims”，即声明。声明可以是注册声明，也可以是公开的声明。注册声明是预定义的声明，如`iss`（发行者），`sub`（主题），`aud`（观众），`exp`（过期时间），`iat`（签发时间），`jti`（JWT的唯一身份标识）等。公开的声明可以由发行者自行定义。
|
|||
|
|
|
|||
|
|
3. **Signature（签名）**：是一个使用头部中指定的算法对前两部分进行签名的结果。签名用于验证消息在传递过程中没有被篡改，并且，如果使用了私钥签名，还可以验证JWT的发行者。
|
|||
|
|
|
|||
|
|
### JWT的工作流程
|
|||
|
|
|
|||
|
|
1. **用户认证**：用户使用用户名和密码在客户端进行认证。
|
|||
|
|
|
|||
|
|
2. **认证服务器验证**：服务器验证用户的凭据，如果验证成功，服务器会生成一个JWT。
|
|||
|
|
|
|||
|
|
3. **发送JWT**：服务器将JWT发送回客户端。
|
|||
|
|
|
|||
|
|
4. **存储JWT**：客户端可以将其存储在本地存储（如LocalStorage）、SessionStorage或Cookies中。
|
|||
|
|
|
|||
|
|
5. **发送请求**：客户端在每次请求到受保护资源时，将JWT发送到服务器。
|
|||
|
|
|
|||
|
|
6. **服务器验证**：服务器接收到JWT后，会验证其签名的有效性，并检查如`exp`（过期时间）等声明，以确保JWT没有过期。
|
|||
|
|
|
|||
|
|
7. **访问资源**：如果JWT有效，服务器允许客户端访问请求的资源。
|
|||
|
|
|
|||
|
|
8. **刷新令牌**：如果JWT过期，客户端可以使用刷新令牌（如果存在）来获取新的JWT。
|
|||
|
|
|
|||
|
|
### 示例
|
|||
|
|
|
|||
|
|
假设一个用户登录了一个网站，以下是JWT的工作流程：
|
|||
|
|
|
|||
|
|
1. 用户输入用户名和密码。
|
|||
|
|
2. 网站将这些凭据发送到服务器。
|
|||
|
|
3. 服务器验证凭据，如果验证通过，生成一个JWT。
|
|||
|
|
4. 服务器将JWT发送回用户。
|
|||
|
|
5. 用户将JWT存储在浏览器的LocalStorage中。
|
|||
|
|
6. 用户想要访问一个受保护的页面。
|
|||
|
|
7. 用户的浏览器发送一个请求到服务器，并将JWT作为请求的一部分发送。
|
|||
|
|
8. 服务器验证JWT的签名，检查`exp`声明以确保它没有过期。
|
|||
|
|
9. 如果JWT有效，服务器提供受保护的页面内容。
|
|||
|
|
|
|||
|
|
JWT是一种无状态的认证机制，它使得用户状态不需要存储在服务器上，从而减轻了服务器的负担，并且可以跨不同的服务和API进行使用。
|
|||
|
|
|
|||
|
|
### 参考
|
|||
|
|
[深入浅出之JWT(JSON Web Token)](https://zhuanlan.zhihu.com/p/355160217)
|