[docs updagte]jwt部分内容完善

Snailclimb · Snailclimb · commit ad3be6fbfda5 · 2022-05-30T22:59:55.000+08:00
diff --git a/docs/system-design/security/advantages&disadvantages-of-jwt.md b/docs/system-design/security/advantages&disadvantages-of-jwt.md
@@ -5,17 +5,17 @@ tag:
   - 安全
 ---
 
-## Token 认证的优势
+## JWT 的优势
 
  相比于 Session 认证的方式来说，使用 Token 进行身份认证主要有下面四个优势：
 
-### 1.无状态
+### 无状态
 
 Token 自身包含了身份验证所需要的所有信息，因此，我们的服务器不需要存储 Session 信息。这显然增加了系统的可用性和伸缩性，大大减轻了服务端的压力。
 
 不过，也正是由于 Token 的无状态，也导致了它最大的缺点：当后端在Token 有效期内废弃一个 Token 或者更改它的权限的话，不会立即生效，一般需要等到有效期过后才可以。另外，当用户 Logout 的话，Token 也还有效。除非，我们在后端增加额外的处理逻辑比如将失效的 Token 存储起来，后端先验证 Token 是否有效再进行处理。
 
-### 2.有效避免了 CSRF 攻击
+### 有效避免了 CSRF 攻击
 
 **CSRF（Cross Site Request Forgery）** 一般被翻译为 **跨站请求伪造**，属于网络攻击领域范围。相比于 SQL 脚本注入、XSS 等安全攻击方式，CSRF 的知名度并没有它们高。但是,它的确是每个系统都要考虑的安全隐患，就连技术帝国 Google 的 Gmail 在早些年也被曝出过存在  CSRF 漏洞，这给 Gmail 的用户造成了很大的损失。
 
@@ -64,19 +64,19 @@ public class XSSFilter implements Filter {
 }
 ```
 
-### 3.适合移动端应用
+### 适合移动端应用
 
 使用 Session 进行身份认证的话，需要保存一份信息在服务器端，而且这种方式会依赖到 Cookie（需要 Cookie 保存 `SessionId`），所以不适合移动端。
 
 但是，使用 Token 进行身份认证就不会存在这种问题，因为只要 Token 可以被客户端存储就能够使用，而且 Token 还可以跨语言使用。
 
-### 4.单点登录友好
+### 单点登录友好
 
 使用 Session 进行身份认证的话，实现单点登录，需要我们把用户的 Session 信息保存在一台电脑上，并且还会遇到常见的 Cookie 跨域的问题。但是，使用 Token 进行认证的话， Token 被保存在客户端，不会存在这些问题。
 
-## Token 认证常见问题以及解决办法
+## JWT 身份认证常见问题及解决办法
 
-### 1.注销登录等场景下 Token 还有效
+### 注销登录等场景下 Token 还有效
 
 与之类似的具体相关场景有：
 
@@ -95,7 +95,7 @@ public class XSSFilter implements Filter {
 
 对于修改密码后 Token 还有效问题的解决还是比较容易的，说一种我觉得比较好的方式：**使用用户的密码的哈希值对 Token 进行签名。因此，如果密码更改，则任何先前的令牌将自动无法验证。**
 
-### 2.Token 的续签问题
+### Token 的续签问题
 
 Token 有效期一般都建议设置的不太长，那么 Token 过期后如何认证，如何实现动态刷新 Token，避免用户经常需要重新登录？
 
diff --git a/docs/system-design/security/basis-of-authority-certification.md b/docs/system-design/security/basis-of-authority-certification.md
@@ -131,7 +131,7 @@ public String readAllCookies(HttpServletRequest request) {
 
 很多时候我们都是通过 `SessionID` 来实现特定的用户，`SessionID` 一般会选择存放在 Redis 中。举个例子：
 
-1. 用户成功登陆系统，然后返回给客户端具有 `SessionID` 的 `Cookie`
+1. 用户成功登陆系统，然后返回给客户端具有 `SessionID` 的 `Cookie` 。
 2. 当用户向后端发起请求的时候会把 `SessionID` 带上，这样后端就知道你的身份状态了。
 
 关于这种认证方式更详细的过程如下：
@@ -146,8 +146,8 @@ public String readAllCookies(HttpServletRequest request) {
 
 使用 `Session` 的时候需要注意下面几个点：
 
-1. 依赖 `Session` 的关键业务一定要确保客户端开启了 `Cookie`。
-2. 注意 `Session` 的过期时间。
+- 依赖 `Session` 的关键业务一定要确保客户端开启了 `Cookie`。
+- 注意 `Session` 的过期时间。
 
 另外，Spring Session 提供了一种跨多个应用程序或实例管理用户会话信息的机制。如果想详细了解可以查看下面几篇很不错的文章：
 
diff --git a/docs/system-design/security/jwt-intro.md b/docs/system-design/security/jwt-intro.md
@@ -121,7 +121,7 @@ HMACSHA256(
 
 算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用"点"（`.`）分隔，成为 JWT 的第三部分。
 
-## 如何基于 Token 进行身份验证？
+## 如何基于 JWT 进行身份验证？
 
 在基于 Token 进行身份验证的的应用程序中，服务器通过 Payload、Header 和 `Secret`(密钥)创建`Token`（令牌）并将 `Token` 发送给客户端。客户端接收到 `Token` 之后，会将其保存在 Cookie 或者 localStorage 里面，以后客户端发出的所有请求都会携带这个令牌。
 
@@ -141,7 +141,7 @@ HMACSHA256(
 
 **[spring-security-jwt-guide](https://github.com/Snailclimb/spring-security-jwt-guide)** 就是一个基于 JWT 来做身份认证的简单案例，感兴趣的可以看看。
 
-## JWT 是如何防止 Token 被篡改的？
+## JWT 如何防止 Token 被篡改？
 
 有了签名之后，即使 Token 被泄露或者解惑，黑客也没办法同时篡改 Signature 、Header 、Payload。
 
