認證協議：OAuth 2.0 和 JWT的學習總結
生活化場景說明OAuth 2.0 和 JWT
- OAuth 2.0（酒店門禁）
用戶（房客）把門禁權限委托給酒店前臺（授權服務器），清潔工（第三方應用）拿到臨時門卡（access token）就能進門打掃，但開不了保險箱（敏感操作）。這個場景能覆蓋四個核心角色和token流轉邏輯。
- JWT（帶防偽印章的體檢報告）
醫生（資源服務器）拆開信封就能看到所有健康數據（payload），印章（簽名）保證沒人篡改
- OAuth 是鑰匙 ；JWT 是信息包
JWT常作為OAuth的token載體。就像酒店給的門卡（OAuth token）里嵌入了房客身份信息（JWT），保安刷卡時能直接顯示房號而不查數據庫
微信登錄用OAuth流程，返回的token如果是JWT格式就能直接解析用戶昵稱
一、OAuth 2.0：授權委托協議 (借鑰匙協議)
核心問題 OAuth 解決
- 想象一下：你有一個裝滿私人照片的網盤（資源服務器）?，F在有一個在線打印店（第三方應用）說可以幫你把照片打印成精美相冊。打印店需要訪問你的照片才能工作。
- 最差的做法： 你把網盤的用戶名和密碼直接告訴打印店。這太危險了！打印店不僅能看到你所有照片，還能刪除、修改它們，甚至用你的賬號干別的事。
- OAuth 要解決的問題： 如何讓打印店只獲得訪問你照片的權限，而不需要知道你的網盤密碼？并且，你還能控制這個權限的范圍（比如只讀）和有效期。
OAuth 2.0 是怎么做的？（授權碼模式 - 最常見）
把它想象成一個“借鑰匙”的過程，涉及幾個角色：
- 你 (資源擁有者)： 擁有照片的人。
- 你的網盤 (資源服務器)： 存放照片的地方。
- 打印店 (第三方應用/客戶端)： 想訪問你照片的應用。
- 網盤公司 (授權服務器)： 管理用戶賬號和權限發放的官方機構（通常和資源服務器是同一家）。
步驟：
- 打印店請求授權： 你去打印店下單。打印店說：“我們需要訪問你網盤里‘度假照片’文件夾的照片。請去網盤公司官方認證頁面確認一下?！?/li>
- 你登錄并授權 (關鍵！)： 你被重定向到網盤公司的官方登錄頁面。你輸入自己的用戶名和密碼（只給網盤公司看?。?/strong>。登錄后，頁面問你：“打印店申請訪問你的‘度假照片’文件夾，權限是【只讀】，有效期1小時。同意嗎？”
- 你同意授權： 你點擊“同意”。網盤公司認證服務器記錄下你的授權決定。
- 授權碼： 網盤公司服務器生成一個一次性的、短命的“授權碼”，通過瀏覽器重定向回傳給打印店。
- 打印店換取“鑰匙”： 打印店拿到授權碼后，連同它自己的身份證明（App ID + Secret），直接（不經過你的瀏覽器）發送給網盤公司的授權服務器，說：“看，用戶給了我授權碼，請給我真正的‘鑰匙’吧?！?/li>
- 發放“鑰匙”： 網盤公司授權服務器驗證打印店的身份和授權碼有效后，頒發一個 Access Token (訪問令牌)。這就是那把“鑰匙”！同時可能還會發一個 Refresh Token (刷新令牌，用于在鑰匙快過期時換新鑰匙)。
- 打印店使用“鑰匙”： 打印店拿著 Access Token 去訪問你的網盤（資源服務器），說：“用戶授權我來拿‘度假照片’文件夾的照片，這是憑證（Token）?！?網盤服務器驗證這個 Token 確實是自家授權服務器發的、且有效、且權限匹配（只讀、特定文件夾），就把照片給打印店了。
- 你用后即焚 (可選)： 打印店完成工作后，可以主動歸還鑰匙（使 Token 失效），或者鑰匙自己到期（Token 過期）。
OAuth 2.0 的精髓
- 你不需要告訴第三方應用你的密碼！ 密碼只給受信任的官方（授權服務器）。
- 細粒度控制： 你可以控制應用能訪問什么（范圍 Scope：如只讀照片）、能訪問多久（Token 有效期）。
- 隨時撤銷： 你可以在網盤公司的設置里隨時撤銷對某個應用的授權，那把“鑰匙”就立刻失效了。
- 應用獨立認證： 第三方應用也需要向授權服務器證明自己是誰（App ID + Secret）。
通俗總結 OAuth 2.0： 它是一套標準流程，讓你可以安全地授權一個應用（比如打印店）去訪問你在另一個服務（比如網盤）上的特定資源（比如照片），而無需把你的密碼告訴那個應用。核心是頒發一個代表特定權限的、有時效的“令牌”（Access Token）給第三方應用。
二、JWT：信息包裝和驗證標準 (帶印章的紙條)
核心問題 JWT 解決
- 在 OAuth 2.0 里，最后給第三方應用的是 Access Token。這個 Token 是什么？可以是一個隨機的字符串（像酒店房卡號），服務器需要查數據庫才能知道這個 Token 對應哪個用戶、有什么權限。
- JWT 提供另一種思路： 能不能把這個 Token 本身就包含用戶信息和權限？就像一個自帶信息的證件，服務器只要驗證這個證件是真實有效的，就能直接讀取里面的信息，不用每次都查數據庫。這就是 JWT。
JWT 是什么？
JWT 全稱 JSON Web Token。你可以把它想象成一張經過防偽處理、自帶信息的紙條。它由三部分組成，用點 . 連接：Header.Payload.Signature
- Header (頭)： 說明這個 JWT 的類型（JWT）和用了什么簽名算法（比如 HMAC SHA256 或 RSA）。就像紙條的抬頭，說明了紙條的格式和防偽方式。
- 示例：
{"alg": "HS256", "typ": "JWT"}(然后用 Base64 編碼)
- 示例：
- Payload (載荷)： 這里存放實際要傳遞的信息，也叫 Claims (聲明)。通常包含：
- 標準聲明：如 簽發者 (
iss)、過期時間 (exp)、受眾 (aud)、生效時間 (iat) 等。 - 自定義聲明： 這才是核心！ 比如用戶ID (
sub)、用戶名、用戶角色、權限范圍 (scope) 等。你想讓 Token 攜帶什么信息都可以放這里（注意不要放敏感信息如密碼）。 - 示例：
{"sub": "1234567890", "name": "小明", "iat": 1516239022, "exp": 1516239322, "scope": "read:photos"}(然后用 Base64 編碼)
- 標準聲明：如 簽發者 (
- Signature (簽名)： 這是最關鍵的部分，用于防偽！
- 服務器用 Header 里聲明的算法，一個只有服務器自己知道的密鑰 (Secret Key) 或 私鑰 (Private Key)，對
Header + '.' + Payload進行簽名計算。 - 計算結果就是 Signature。它像是一個獨特的“防偽印章”或“指紋”。
- 服務器用 Header 里聲明的算法，一個只有服務器自己知道的密鑰 (Secret Key) 或 私鑰 (Private Key)，對
最終 JWT = Base64(Header) + '.' + Base64(Payload) + '.' + Base64(Signature)
JWT 怎么工作？（以 OAuth Access Token 為例）
- 簽發： 授權服務器驗證用戶身份和授權后，生成包含用戶信息和權限的 Payload，加上 Header，然后用密鑰生成 Signature，組合成 JWT 發給客戶端（打印店）。
- 傳遞： 客戶端拿著這個 JWT（作為 Access Token）去訪問資源服務器（網盤）。
- 驗證： 資源服務器收到 JWT：
- 檢查簽名： 用預先和授權服務器約定好的密鑰（或授權服務器的公鑰）重新計算
Header + '.' + Payload的簽名。如果計算出來的簽名和 JWT 里的 Signature 完全一致，就證明：- 這個 JWT 是合法的授權服務器簽發的（因為只有它知道密鑰或持有私鑰）。
- JWT 的內容（Header + Payload）在傳輸過程中沒有被篡改（改一點簽名就對不上）。
- 檢查有效期： 讀取 Payload 里的
exp(過期時間) 和iat(簽發時間)，確認 Token 沒有過期。 - 檢查權限： 讀取 Payload 里的
scope等信息，確認客戶端請求的操作（如讀取照片）在授權范圍內。
- 檢查簽名： 用預先和授權服務器約定好的密鑰（或授權服務器的公鑰）重新計算
- 處理請求： 驗證通過后，資源服務器直接讀取 Payload 里的信息（如用戶ID
sub），就知道是誰在訪問、有什么權限，然后處理請求（返回照片）。整個過程不需要去查數據庫驗證 Token 有效性！
JWT 的精髓
- 自包含： Token 本身攜帶了有用的信息（Payload）。
- 可驗證： 通過簽名機制，接收方可以驗證 Token 是誰發的、內容是否被篡改。簽名是核心安全機制。
- 無狀態： 資源服務器不需要存儲 Token 的狀態（如 Session），只需驗證簽名和有效期即可。這使得擴展（加服務器）更容易。
- 靈活： Payload 可以自定義各種你需要的信息。
通俗總結 JWT： 它是一種標準格式的“加密小紙條”（JSON Web Token）。這個小紙條自身就寫明了包含哪些用戶信息（Payload），并且帶有一個特殊的防偽印章（Signature）。服務器只需要驗證這個印章是真的（用密鑰或公鑰），就能完全信任紙條上寫的信息是真實、未被篡改的。它常用于作為 OAuth 2.0 的 Access Token，讓資源服務器能快速驗證請求者身份和權限。
OAuth 2.0 和 JWT 的關系
- OAuth 2.0 是一個授權框架： 它定義了流程（怎么借鑰匙），規定了角色（你、網盤、打印店、網盤公司），以及核心概念（授權、Access Token）。
- JWT 是一種 Token 的實現方式： 它定義了 Access Token（鑰匙）可以長什么樣、里面裝什么信息、如何保證這個鑰匙是真實可靠的（通過簽名）。
- OAuth 2.0 不強制規定 Token 格式： Access Token 可以是一個隨機字符串（不透明令牌），也可以是一個 JWT（自包含令牌）。JWT 是 OAuth 2.0 中 Access Token 的一種非常流行和有用的格式選擇。
- JWT 不局限于 OAuth： JWT 也可以用在其他需要安全傳遞信息的場景，比如用戶登錄后，服務器生成一個包含用戶ID的 JWT 返回給瀏覽器（作為 Session Token），瀏覽器后續請求帶上它，服務器驗證簽名就能知道用戶是誰。
簡單來說：OAuth 2.0 是“怎么安全地借鑰匙”的規則說明書，而 JWT 是一種“自帶身份信息和防偽標識的智能鑰匙”的制作標準。 OAuth 2.0 可以選擇使用 JWT 這種智能鑰匙。
浙公網安備 33010602011771號