登錄背後的秘密：Session、Token、OAuth 到底在幹什麼？
整理版優先睇
Session、JWT、OAuth三大鑑權方式全解析，教你點樣根據場景揀最合適方案。
呢篇文章係一篇技術整理，由作者（未署名）系統梳理咗Web開發中三大主流登錄鑑權方式：Session+Cookie、JWT Token同OAuth 2.0。作者想解決嘅問題係：HTTP無狀態協議之下，點樣令服務器認得「你」？整體結論係冇最好只有最合適，現代大型應用往往三者並存，要根據架構同場景組合使用。
文章先講Session+Cookie，係最經典方案，服務端存狀態，客戶端帶Cookie憑證，適合傳統服務端渲染嘅單體系統，但水平擴展需要共享存儲。跟住講JWT Token，佢將狀態下沉到客戶端，無狀態自描述，天然支援跨域同分佈式架構，但Token簽發後無法主動吊銷，需要配黑名單或雙Token機制。最後介紹OAuth 2.0，呢個係授權框架，核心係點樣畀第三方應用喺用戶授權後安全訪問資源，常見嘅「微信登錄」就係OAuth 2.0加OIDC嘅應用，流程較複雜但安全性高。
文章仲提供咗安全實踐備忘同選型決策樹，幫讀者喺實際項目中快速揀啱方案。整體嚟講，呢篇文章結構清晰，適合想做鑑權選型嘅開發者參考。
- Session+Cookie由服務端存狀態，適合單體架構，但水平擴展需共享存儲，Cookie跨域受限。
- JWT Token無狀態自描述，天然跨域，但Token無法主動吊銷，需用黑名單或雙Token機制（Access+Refresh Token）。
- OAuth 2.0係授權框架，用於第三方登錄，常配合OIDC認證身份；授權碼模式最安全，需驗證state參數防CSRF。
- 安全實踐：Cookie設HttpOnly+Secure+SameSite；JWT Payload唔好存敏感信息；OAuth要用PKCE增強保護。
- 選型建議：傳統SSR用Session，前後端分離用JWT雙Token，C端產品用OAuth，大型系統可以三者並存。
鑑權機制嘅基本概念
HTTP係無狀態協議，每一次請求對服務器嚟講都係陌生人。為咗令服務器認出「你」，工程師發明咗各種鑑權機制，由早期嘅Session到而家盛行嘅JWT，再到第三方登錄背後嘅OAuth，每種方案都有獨特嘅設計哲學同適用邊界。呢篇文章會系統梳理三大主流方案，對比優缺點，並畀出實際選型建議。
01 Session+Cookie：經典嘅服務端狀態方案
Session+Cookie係互聯網最經典嘅鑑權方案，誕生於Web早期，至今仍廣泛應用喺傳統MVC架構嘅服務端渲染項目。佢嘅核心思路係：服務端存狀態，客戶端帶憑證。
認證流程：用戶提交賬號密碼 → 服務端驗證通過，生成唯一Session ID，將會話數據存入內存 / Redis / 數據庫
服務端透過Set-Cookie響應頭將Session ID寫入瀏覽器Cookie；後續每次請求，瀏覽器自動攜帶Cookie，服務端根據Session ID查詢對應嘅用戶狀態。用戶退出登錄時，服務端銷燬Session，狀態立即失效。
優點：服務端可隨時主動吊銷會話，狀態集中管理，安全可控，實現簡單，框架內置支援。
但缺點都明顯：服務端有存儲壓力，用戶量大時內存消耗顯著；水平擴展困難（多台服務器需共享Session存儲）；Cookie跨域受限，唔適合前後端分離或App；CSRF攻擊面較大。
典型場景：傳統企業OA系統、後台管理平台（單體架構）、需要強制踢出登錄嘅金融/政務系統、對CSRF防護完善嘅服務端渲染應用。
02 JWT Token：無狀態嘅客戶端方案
JWT係近十年前後端分離浪潮中崛起嘅鑑權標準，由IETF RFC 7519定義。佢嘅核心哲學同Session完全相反：狀態下沉到客戶端，服務端無需存儲。
JWT Token結構：Header（算法+類型）、Payload（聲明信息，Base64非加密）、Signature（HMAC/RSA簽名防篡改）
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiIxMjM0NTYiLCJyb2xlIjoiYWRtaW4iLCJleHAiOjE3MDAwMDAwMDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c標準Payload字段包括sub（主題，用戶ID）、exp（過期時間）、iat（簽發時間）、iss（簽發方）等。
JWT嘅優點係服務端完全無狀態，天然支援水平擴展；跨域友好，適合SPA、App同微服務；Payload可攜帶自定義業務信息，減少查庫；標準化程度高，生態豐富。
缺點：Token一旦簽發，喺過期前無法主動吊銷（需黑名單）；Payload可被Base64解碼，唔可以存敏感信息；Token體積比Session ID大，每次請求增加帶寬開銷；密鑰泄露則全線淪陷。
典型場景包括前後端分離嘅SPA（React/Vue）、移動端App、微服務架構（API Gateway統一鑑權）、需要多端共用同一套接口嘅產品。
03 OAuth 2.0：授權框架與第三方登錄
OAuth 2.0嚴格嚟講係一個授權框架，而非單純嘅鑑權協議。佢解決嘅核心問題係：點樣讓第三方應用喺用戶授權後，安全地訪問用戶喺另一個平台上嘅資源，全程無需暴露用戶密碼。
OAuth 2.0嘅四個角色：Resource Owner（用戶）、Client（第三方應用）、Authorization Server（授權服務器）、Resource Server（資源服務器）
最安全最常用嘅係授權碼模式：用戶點擊「微信登錄」→應用將用戶重定向到微信授權頁面，攜帶client_id、redirect_uri、scope等參數；用戶喺微信側確認授權→微信將code回調至應用；應用後端用code+client_secret向微信服務器換取Access Token；最後持Access Token調用微信API獲取用戶信息。
優點包括：用戶免註冊一鍵登錄，大幅降低門檻；唔接觸用戶密碼，安全性高；權限範圍（scope）精細可控；標準協議可接入數十種主流平台。
缺點：流程複雜，需要維護與第三方平台嘅回調對接；依賴第三方服務可用性，存在單點風險；部分平台審核流程繁瑣；政策變化可能影響接入權限。
典型場景：面向C端用戶嘅產品（降低註冊門檻）、需要調用第三方平台API嘅應用（如讀取GitHub倉庫、發佈微博）、企業SSO單點登錄系統（SAML/OIDC）。
安全實踐與選型建議
三種方案並非互斥，實際項目中常常組合使用。以下係安全實踐備忘同簡明決策樹。
- 傳統服務端渲染 / 企業內部系統？→ Session + Cookie，配合Redis集中存儲即可。
- 前後端分離 / 多端（Web+App+小程序）？→ JWT（雙Token機制），API Gateway統一鑑權。
- 面向C端 / 需要一鍵登錄 / 調用第三方能力？→ OAuth 2.0 + OIDC，接入微信/Google/GitHub等。
- 對安全要求極高 / 需要立即吊銷？→ JWT + Redis黑名單或回歸Session，用存儲換安全可控性。
現代大型應用往往三者並存：自有賬號體系用JWT，「微信/Google登錄」走OAuth，後台管理系統保留Session。冇最好嘅方案，只有最合適嘅組合。
TL;DR：Session服務端存狀態，安全可控，擴展需共享存儲，適合單體架構；JWT無狀態自描述，天然跨域，吊銷需額外機制，適合分佈式/多端；OAuth授權委託框架，解決第三方登錄與跨系統資源訪問，非單純鑑權。
Web Security
主流登入鑑權方法全面拆解
Session + Cookie · JWT Token · OAuth 2.0
一篇文章搞掂由原理到揀方案
HTTP 係無狀態協議，每次請求對伺服器嚟講都係陌生人。為咗令伺服器認得「你」，工程師們發明咗各種鑑權機制。由早期嘅 Session，到而家流行嘅 JWT，再到第三方登入背後嘅 OAuth，每種方案都有佢獨特嘅設計哲學同適用邊界。
本文帶你係統梳理呢三大主流方案，對比優缺點，仲會俾出實際揀方案嘅建議。
01 Session + Cookie
Session + Cookie 係互聯網最經典嘅鑑權方案，誕生喺 Web 早期，到今日仍然廣泛用喺傳統 MVC 架構嘅伺服器端渲染項目。佢嘅核心思路係：伺服器端儲存狀態，客戶端帶住憑證。
✓ 優點
伺服器端可以隨時主動吊銷會話 狀態集中管理，安全又可控 實現簡單，框架內置支援 適合需要精細權限管理嘅系統
✗ 缺點
伺服器端有儲存壓力，用戶量大嗰陣內存消耗好明顯 水平擴展困難（多部伺服器需要共享 Session 儲存） Cookie 跨域受限，唔適合前後端分離 / App CSRF 攻擊面比較大
典型場景：傳統企業 OA 系統、後台管理平台（單體架構）、需要強制踢人登出嘅金融/政務系統、對 CSRF 防護完善嘅伺服器端渲染應用。
02 JWT Token
JWT（JSON Web Token）係近十年前後端分離浪潮中崛起嘅鑑權標準，由 IETF RFC 7519 定義。佢嘅核心哲學同 Session 完全相反：狀態下沉到客戶端，伺服器端唔需要儲存。
標準 Payload 欄位
💡 雙 Token 機制（最佳實踐）
實際項目通常配合使用Access Token（短期，5 至 15 分鐘）和Refresh Token（長期，7 至 30 日）。Access Token 過期之後，客戶端用 Refresh Token 無聲無色咁換新嘅 Access Token，兼顧安全同用戶體驗。Refresh Token 通常儲存喺 HttpOnly Cookie 入面以防 XSS。
✓ 優點
伺服器端完全無狀態，天然支援水平擴展 跨域友好，適合 SPA / App / 微服務 Payload 可以攜帶自定義業務資訊，減少查資料庫 標準化程度高，生態豐富
✗ 缺點
Token 一旦簽發，喺過期前冇得主動吊銷（要靠黑名單） Payload 可以被 Base64 解碼，唔可以存敏感資訊 Token 體積比 Session ID 大，每次請求會增加頻寬開銷 密鑰泄露就會全線淪陷，密鑰輪轉要好小心
典型場景：前後端分離嘅 SPA（React / Vue）、手機 App、微服務架構（API Gateway 統一鑑權）、需要多端共用同一套接口嘅產品。
03 OAuth 2.0
OAuth 2.0（RFC 6749）嚴格嚟講係一個授權框架，而唔係單純嘅鑑權協議。佢解決嘅核心問題係：點樣令第三方應用喺用戶授權之後，安全咁訪問用戶喺另一個平台嘅資源，而且全程唔需要暴露用戶密碼。
我哋每日用嘅「微信登入」「GitHub 登入」「Google 登入」，本質上都係 OAuth 2.0 + OIDC（OpenID Connect）嘅應用。
OAuth 2.0 嘅四個角色
Resource Owner
用戶，資源嘅真正擁有者，負責授權
Client
第三方應用，代表用戶訪問資源（例如你開發嘅 App）
Authorization Server
授權伺服器，負責驗證用戶身份同發放 Token（例如微信、GitHub）
Resource Server
資源伺服器，存放被保護嘅資源（例如 GitHub 倉庫、用戶頭像）
授權碼模式（最安全，最常用）
用戶撳「微信登入」→ 應用將用戶重新導向到微信授權頁面，帶住client_id、redirect_uri、scope等參數
用戶喺微信邊掃碼/確認授權 → 微信將code（授權碼）回調返去應用
應用後端用code+client_secret向微信伺服器換取 Access Token（伺服器端對伺服器端，唔經過瀏覽器）
用 Access Token 調用微信 API 拎用戶openid、頭像、暱稱等，完成登入或註冊
OAuth 2.0 vs OIDC
OAuth 2.0 只係解決「授權」（你可以做啲乜），唔解決「認證」（你係邊個）。OpenID Connect（OIDC）係建基喺 OAuth 2.0 上面嘅身份層，額外引入咗ID Token（一個 JWT）嚟攜帶用戶身份資訊。現代「用 xx 登入」嘅實現通常係 OAuth 2.0 + OIDC 嘅組合。
✓ 優點
用戶唔使註冊，一鍵登入，大幅降低門檻 不接觸用戶密碼，安全性高 權限範圍（scope）精細可控 標準協議，可以接入幾十種主流平台
✗ 缺點
流程複雜，需要維護同第三方平台嘅回調對接 依賴第三方服務嘅可用性，存在單點風險 部分平台審核流程好繁瑣（例如微信開放平台） 政策變化可能影響接入權限
典型場景：面向 C 端用戶嘅產品（降低註冊門檻）、需要調用第三方平台 API 嘅應用（例如讀取 GitHub 倉庫、發佈微博）、企業 SSO 單點登入系統（SAML / OIDC）。
橫向對比一覽（滑動睇完整表格）
安全實踐備忘
Cookie 一定要設定 HttpOnly + Secure + SameSite
HttpOnly防 XSS 腳本讀取，Secure限制 HTTPS 傳輸，SameSite=Strict/Lax抵禦 CSRF
JWT 嘅 Payload 唔可以存敏感資訊
Payload 只係 Base64 編碼，任何人都解碼到，千祈唔好放密碼、身份證等私隱欄位。如果需要加密，用 JWE 而唔係 JWS。
OAuth 一定要驗證 state 參數，防止 CSRF
發起授權請求嗰陣生成隨機state值，回調嗰陣校驗係咪匹配，避免授權碼劫持攻擊。公開客戶端仲應該用 PKCE（RFC 7636）增強保護。
全程 HTTPS，Token 傳輸用 Authorization Header
JWT 應該放喺Authorization: Bearer <token>Header 入面，而唔係 URL 查詢參數（會俾伺服器日誌記錄低）。
點樣揀方案？
三種方案並唔係互斥，實際項目成日會組合使用。下面係一份簡單決策樹：
傳統伺服器端渲染 / 企業內部系統？
→ Session + Cookie，配合 Redis 集中儲存已經滿足到大部份場景
前後端分離 / 多端（Web + App + 小程序）？
→ JWT（雙 Token 機制），API Gateway 統一鑑權，微服務入面無感通行
面向 C 端 / 需要一鍵登入 / 調用第三方能力？
→ OAuth 2.0 + OIDC，接入微信 / Google / GitHub 等，可以大幅提升轉化率
對安全要求極高 / 需要即刻吊銷？
→ JWT + Redis 黑名單或迴歸Session，用儲存換安全可控性
現代大型應用通常係三者並存：自有帳號體系用 JWT，「微信/Google 登入」行 OAuth，後台管理系統保留 Session。冇最好嘅方案，只有最合適嘅組合。
TL;DR
伺服器端存狀態，安全可控，擴展需共享儲存，適合單體架構
無狀態自描述，天然跨域，吊銷需額外機制，適合分佈式/多端
授權委託框架，解決第三方登入同跨系統資源訪問，唔係單純鑑權
如果有疑問或者更多諗法，歡迎留言交流 👇
Web Security
主流登錄鑑權方式全解析
Session + Cookie · JWT Token · OAuth 2.0
一文搞定從原理到選型
HTTP 是無狀態協議，每一次請求對服務器來說都是陌生人。為了讓服務器認出「你」，工程師們發明了各種鑑權機制。從早期的 Session，到如今盛行的 JWT，再到第三方登錄背後的 OAuth，每種方案都有其獨特的設計哲學與適用邊界。
本文帶你係統梳理這三大主流方案，對比優缺點，並給出實際選型建議。
01 Session + Cookie
Session + Cookie 是互聯網最經典的鑑權方案，誕生於 Web 早期，至今仍廣泛應用於傳統 MVC 架構的服務端渲染項目。它的核心思路是：服務端存狀態，客戶端帶憑證。
✓ 優點
服務端可隨時主動吊銷會話 狀態集中管理，安全可控 實現簡單，框架內置支持 適合需要精細權限管理的系統
✗ 缺點
服務端有存儲壓力，用戶量大時內存消耗顯著 水平擴展困難（多台服務器需共享 Session 存儲） Cookie 跨域受限，不適合前後端分離 / App CSRF 攻擊面較大
典型場景：傳統企業 OA 系統、後台管理平台（單體架構）、需要強制踢出登錄的金融/政務系統、對 CSRF 防護完善的服務端渲染應用。
02 JWT Token
JWT（JSON Web Token）是近十年前後端分離浪潮中崛起的鑑權標準，由 IETF RFC 7519 定義。它的核心哲學與 Session 截然相反：狀態下沉到客戶端，服務端無需存儲。
標準 Payload 字段
💡 雙 Token 機制（最佳實踐）
實際項目中通常配合使用Access Token（短期，5 至 15 分鐘）和Refresh Token（長期，7 至 30 天）。Access Token 過期後，客戶端憑 Refresh Token 靜默獲取新的 Access Token，兼顧安全與用戶體驗。Refresh Token 通常存儲在 HttpOnly Cookie 中以防 XSS。
✓ 優點
服務端完全無狀態，天然支持水平擴展 跨域友好，適合 SPA / App / 微服務 Payload 可攜帶自定義業務信息，減少查庫 標準化程度高，生態豐富
✗ 缺點
Token 一旦簽發，在過期前無法主動吊銷（需黑名單） Payload 可被 Base64 解碼，不可存敏感信息 Token 體積比 Session ID 大，每次請求增加帶寬開銷 密鑰泄露則全線淪陷，密鑰輪轉需謹慎
典型場景：前後端分離的 SPA（React / Vue）、移動端 App、微服務架構（API Gateway 統一鑑權）、需要多端共用同一套接口的產品。
03 OAuth 2.0
OAuth 2.0（RFC 6749）嚴格來說是一個授權框架，而非單純的鑑權協議。它解決的核心問題是：如何讓第三方應用在用戶授權後，安全地訪問用戶在另一個平台上的資源，且全程無需暴露用戶密碼。
我們每天使用的「微信登錄」「GitHub 登錄」「Google 登錄」，本質上都是 OAuth 2.0 + OIDC（OpenID Connect）的應用。
OAuth 2.0 的四個角色
Resource Owner
用戶，資源的真正擁有者，負責授權
Client
第三方應用，代表用戶訪問資源（如你開發的 App）
Authorization Server
授權服務器，負責驗證用戶身份併發放 Token（如微信、GitHub）
Resource Server
資源服務器，存放被保護資源（如 GitHub 倉庫、用戶頭像）
授權碼模式（最安全，最常用）
用戶點擊「微信登錄」→ 應用將用戶重定向到微信授權頁面，攜帶client_id、redirect_uri、scope等參數
用戶在微信側掃碼/確認授權 → 微信將code（授權碼）回調至應用
應用後端用code+client_secret向微信服務器換取 Access Token（服務端對服務端，不經瀏覽器）
持 Access Token 調用微信 API 獲取用戶openid、頭像、暱稱等，完成登錄或註冊
OAuth 2.0 vs OIDC
OAuth 2.0 只解決「授權」（你能做什麼），不解決「認證」（你是誰）。OpenID Connect（OIDC）是構建在 OAuth 2.0 上的身份層，額外引入了ID Token（一個 JWT）來攜帶用戶身份信息。現代「用 xx 登錄」實現通常是 OAuth 2.0 + OIDC 的組合。
✓ 優點
用戶免註冊，一鍵登錄，大幅降低門檻 不接觸用戶密碼，安全性高 權限範圍（scope）精細可控 標準協議，可接入數十種主流平台
✗ 缺點
流程複雜，需要維護與第三方平台的回調對接 依賴第三方服務可用性，存在單點風險 部分平台審核流程繁瑣（如微信開放平台） 政策變化可能影響接入權限
典型場景：面向 C 端用戶的產品（降低註冊門檻）、需要調用第三方平台 API 的應用（如讀取 GitHub 倉庫、發佈微博）、企業 SSO 單點登錄系統（SAML / OIDC）。
橫向對比一覽（滑動查看完整表格）
安全實踐備忘
Cookie 必須設置 HttpOnly + Secure + SameSite
HttpOnly防 XSS 腳本讀取，Secure限制 HTTPS 傳輸，SameSite=Strict/Lax抵禦 CSRF
JWT 的 Payload 不能存敏感信息
Payload 只是 Base64 編碼，任何人都可以解碼，切勿存放密碼、身份證等隱私字段。若需加密，使用 JWE 而非 JWS。
OAuth 必須驗證 state 參數，防止 CSRF
發起授權請求時生成隨機state值，回調時校驗是否匹配，避免授權碼劫持攻擊。公開客戶端還應使用 PKCE（RFC 7636）增強保護。
全程 HTTPS，Token 傳輸使用 Authorization Header
JWT 應放在Authorization: Bearer <token>Header 中，而非 URL 查詢參數（會被服務器日誌記錄）。
如何選型？
三種方案並非互斥，實際項目中常常組合使用。下面是一份簡明決策樹：
傳統服務端渲染 / 企業內部系統？
→ Session + Cookie，配合 Redis 集中存儲即可滿足大多數場景
前後端分離 / 多端（Web + App + 小程序）？
→ JWT（雙 Token 機制），API Gateway 統一鑑權，微服務內無感通行
面向 C 端 / 需要一鍵登錄 / 調用第三方能力？
→ OAuth 2.0 + OIDC，接入微信 / Google / GitHub 等，可大幅提升轉化率
對安全要求極高 / 需要立即吊銷？
→ JWT + Redis 黑名單或迴歸Session，用存儲換安全可控性
現代大型應用往往是三者並存：自有賬號體系用 JWT，「微信/Google 登錄」走 OAuth，後台管理系統保留 Session。沒有最好的方案，只有最合適的組合。
TL;DR
服務端存狀態，安全可控，擴展需共享存儲，適合單體架構
無狀態自描述，天然跨域，吊銷需額外機制，適合分佈式/多端
授權委託框架，解決第三方登錄與跨系統資源訪問，非單純鑑權
如有疑問或更多思考，歡迎留言交流 👇