Web 安全與系統設計

Web存在的問題：Web 是無狀態的

HTTP 協議是“無狀態”的，意思是：每次請求都是獨立的，服務器不會自動記住“上一次是誰來的”。

舉例說明：
你訪問了電商首頁，下一步點進購物車，但服務器根本“不知道你是剛才那個訪問首頁的人”。

🚨 于是問題來了：

• 登錄一次后，如何在后續請求中識別你是誰？
• 登錄后你是“管理員”還是“普通用戶”，怎么讓系統知道？
• 如何控制你能不能查看某些敏感信息？

這就是認證、授權、鑒權、Session、Cookie、Token、鑒權這些概念誕生的原因。

解決方案

一、早期解決方案：Session + Cookie 的誕生

Session

• 服務端用來保存“用戶的登錄狀態”
• 登錄后創建一個 session，里面保存用戶信息（比如用戶名、權限）

Cookie

• 瀏覽器存儲的“小紙條”，由服務器發給客戶端
• 瀏覽器下次訪問自動帶上，服務器通過它知道“你是誰”

Session + Cookie 工作流程：

• 用戶登錄成功，服務器保存一個 Session（如：userId=1）
• 服務器發送一個 Cookie：Set-Cookie: sessionId=abc123
• 瀏覽器保存 Cookie
• 后續每次請求都自動帶上 Cookie
• 服務器根據 sessionId 找回用戶信息

場景適合：

• 傳統網站：如早期的 JSP、PHP、ASP 網頁
• 登錄狀態依賴服務端 Session 內存或 Redis

?? 問題：

• Session 保存在服務端，不好擴展（如分布式服務）
• 前后端不分離，適合頁面渲染型項目，不適合 App / 移動端

二、第二階段：Token 的出現（前后端分離 + 移動端的解決方案）

為什么需要 Token？

• 前端 Vue/React，后端 SpringBoot 分開部署
• 客戶端不能自動發送 Cookie（安全或跨域問題）
• 希望服務器是無狀態的，方便橫向擴展、容災

什么是 Token？

• 一段字符串，用來代表用戶身份
• 登錄成功后由服務器生成，發給前端
• 前端以后每次請求都帶上 Token（放在請求頭）

JWT（JSON Web Token）：主流 Token 形式

• 格式固定、支持加密、不易偽造
  -通常結構為三段：header.payload.signature

Token 登錄流程：

• 用戶輸入賬號密碼，后端驗證成功
• 后端生成 Token 返回前端
• 前端存到 localStorage 或 sessionStorage
• 每次請求都在請求頭加上 Token
• 后端解析 Token，識別用戶身份

適合場景：

• 前后端分離的 Web 系統
  -移動端、小程序、App
  -分布式系統、微服務架構

三、分析總結：

1.早期版本：session+cookie存在的問題分析

①分布式服務

早期session+cookie無法解決分布式服務的原因：
舉例如下：
你的服務不止部署在一臺服務器上，而是：

用戶請求 → 隨機到 A 服務器 或 B 服務器 或 C 服務器（負載均衡）

Session 是默認保存在“當前服務器內存中的”，也就是說：

• 用戶第一次登錄 → 分配到 A 服務器 → A 創建了一個 Session
• 用戶第二次請求 → 分配到 B 服務器 → B 根本沒有 A 上那個 Session！

結果：用戶雖然登錄了，但在 B 看來是“未登錄”，因為找不到 Session。

優雅解決：Token 模式
因為JWT 是“無狀態”的，后端服務使用同一套驗證機制。

驗證過程：

• 用戶登錄后，生成的 JWT Token 本身就包含用戶信息（如 userId、role）
• 后端只需驗證 Token 是否有效，就能識別身份，無需存任何會話
• 不需要服務器保存登錄狀態：哪臺服務器收到請求都能獨立完成校驗 → 完全支持分布式！

②非瀏覽器和前后端分離場景

App、小程序不會自動攜帶 Cookie

• Session 模式依賴瀏覽器自動發送 Cookie（尤其是跨頁面請求）
• 但 App / 小程序 / Postman 這類非瀏覽器客戶端 不會自動管理 Cookie
• 即使發送了，也很容易出現“session 丟失”、“登錄失效”等問題

前后端分離：

• 前后端分離中，前端（如 localhost:8080）和后端（如 api.xx.com）是不同域名
• 跨域訪問默認不會攜帶 Cookie

token優勢：

Token 模式特點	對應優勢
登錄后發一個 Token（如 JWT）	不依賴 Cookie，跨域沒問題
Token 放在前端（localStorage、App 本地）	多端可統一管理
每次請求手動帶上 Authorization: Bearer xxx	客戶端完全控制，通用性強
服務端無狀態（不用保存登錄信息）	更適合分布式架構、微服務系統
網關統一攔截 Token 驗證	方便統一接入與安全控制
Token 結構中可附帶用戶信息（如 userId、role）	減少服務端查詢

2.總結

項目	Session + Cookie（傳統方式）	Token（現代方式）
客戶端是否自動帶登錄信息	? 瀏覽器自動帶 Cookie	? 客戶端需手動加 Header
是否依賴瀏覽器	? 是	? 否，通用性強
是否易于跨域	? 需特殊配置	? 天然支持
是否需要服務端保存狀態	? 需要	? 無狀態
是否適合分布式架構	? 不適合	? 適合
是否適合前后端分離	? 不適合	? 非常適合
是否適合 App、小程序等	? 不適合	? 非常適合