認證與授權全攻略：從 Basic、JWT 到 RBAC、ABAC，開發者該怎麼選？

引言：別搞混！認證和授權是兩回事

做開發時，我們常把“認證”和“授權”掛在嘴邊，但很多人其實沒分清二者的核心區別：

• 認證（Authentication）：解決“你是誰”的問題——比如登錄時輸密碼、掃人臉，本質是確認“用户身份合法”。
• 授權（Authorization）：解決“你能做什麼”的問題——比如登錄 GitHub 後，你能 push 代碼還是隻能看倉庫，本質是控制“合法用户的操作權限”。

簡單説：先“認證”通過，再“授權”判斷。少了前者，系統會認錯人；少了後者，合法用户可能亂操作（比如普通員工刪了公司財務數據）。

這篇文章就把「認證技術」和「授權模型」揉在一起講透：從基礎的賬號密碼認證，到複雜的第三方授權，再到企業級的權限控制，幫你搞懂不同場景該用什麼方案～

第一部分：認證技術——先確認“你是誰”

認證是授權的前提。目前主流的認證技術有 5 種，各有適用場景，別盲目跟風用“高大上”的方案。

1. 最樸素的認證：Basic Auth（基本認證）

工作原理

説穿了就是“賬號密碼直接傳”：客户端把“用户名：密碼”用 Base64 編碼（注意！不是加密），放在 HTTP 請求頭的Authorization裏發給服務器，服務器解碼後驗證身份。 請求頭示例：

Authorization: Basic dXNlcjE6cGFzc3dvcmQxMjM= 
# 解碼後：user1:password123

適合場景

• 僅用於內部極簡單的小系統（比如公司內部的測試工具、臨時後台）；
• 必須搭配 HTTPS 使用（否則 Base64 編碼能被輕易破解，等於裸奔）。

避坑點

絕對不能用在公開系統！比如用户可訪問的 App、官網——Base64 解碼太容易，隨便搜個“Base64 在線解碼”就能拿到賬號密碼。

2. 輕量升級：Bearer Auth（承載認證）

工作原理

比 Basic Auth 靈活一步：用户登錄成功後，服務器生成一個隨機“令牌（Token）”返回給客户端；之後客户端每次請求，都把 Token 放在Authorization頭裏，服務器驗證 Token 有效性即可。 請求頭示例：

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... 
# 後面的長字符串就是服務器頒發的Token

適合場景

• 中小型前後端分離項目（比如 Vue/React 官網、小體量 App）；
• 不需要複雜權限管理的場景（比如只需要“確認用户已登錄”，不用區分“管理員/普通用户”）。

核心優勢

Token 可以隨時吊銷（比如用户登出時，服務器把 Token 加入“黑名單”），而 Basic Auth 的“用户名+密碼”一旦泄露，只能讓用户改密碼——靈活性差很多。

3. 第三方登錄的核心：OAuth 2.0（開放授權協議）

先釐清：OAuth 2.0 是“授權”，不是“認證”！

很多人以為 OAuth 2.0 是“登錄方式”，其實它本質是委派授權協議：允許用户把“自己在 A 系統的權限”委派給 B 系統，不用把 A 系統的密碼告訴 B 系統。

比如你用“微信登錄某外賣 App”：

• 你不用把微信密碼告訴外賣 App；
• 你只需要授權外賣 App“獲取你的微信暱稱和頭像”；
• 微信給外賣 App 發一個“授權令牌”，App 用這個令牌拿你的信息——這就是 OAuth 2.0 的核心邏輯。

適合場景

• 所有“第三方登錄”場景（用 QQ 登錄遊戲、用 GitHub 登錄開源工具、用支付寶登錄生活類 App）；
• 跨系統權限共享（比如公司內部“CRM 系統”授權“財務系統”獲取客户基本信息，不用重複登錄）。

國內常用流程：授權碼模式（Authorization Code）

這是最安全的 OAuth 2.0 流程，國內大廠基本都用它：

1. 外賣 App 跳轉到微信登錄頁，你輸入微信密碼完成認證；
2. 微信給 App 返回一個“授權碼”（臨時、一次性有效）；
3. App 拿着“授權碼”向微信服務器申請“訪問令牌（Access Token）”；
4. 微信返回“訪問令牌”，App 用它獲取你的暱稱、頭像（只能拿你授權的信息）。

4. 前後端分離寵兒：JWT（JSON Web Token）

工作原理

JWT 不是“新認證技術”，而是一種 Token 的標準化格式——把用户信息（比如用户 ID、角色）用 JSON 封裝，加上“頭部（算法）”和“簽名（防篡改）”，生成“頭部。載荷。簽名”三段式字符串。

示例 JWT：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcxNjQyMDgwMH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

• 頭部：説明簽名算法（比如HS256）；
• 載荷：存放非敏感用户信息（比如userId:1、role:admin）；
• 簽名：用服務器“密鑰”生成，服務器收到 JWT 後會重新計算簽名，確認是否被篡改。

適合場景

• 前後端分離項目（前端存 JWT，後端不用存 Session，直接解析 Token 拿用户信息）；
• 分佈式系統（多個服務共享用户信息，不用每個服務都查數據庫）。

避坑點

• 載荷是 Base64 編碼明文，絕對不能存密碼、手機號等敏感數據；
• 密鑰要保管好！一旦密鑰泄露，攻擊者能偽造任意 JWT；
• JWT 本身不能吊銷（除非加“黑名單”機制），所以過期時間別設太長（比如 1-2 小時）。

5. 企業級統一登錄：SSO（單點登錄）

工作原理

解決“多系統只登一次”的痛點：企業搭建一個“統一認證中心”，所有內部系統都信任這個中心。你在任何一個系統登錄，其實都是在“認證中心”登錄；之後訪問其他系統時，系統會向“認證中心”確認你的登錄狀態，不用再輸密碼。

比如你登錄阿里的“淘寶”後，再打開“支付寶”“天貓”，不用重新登錄——背後就是 SSO 在工作。

適合場景

• 企業內部多系統（OA、CRM、財務、人事系統）；
• 同一公司旗下的多個產品（比如字節的“抖音”登錄後，“今日頭條”自動登錄）。

和 OAuth 2.0 的區別

• OAuth 2.0：側重“跨公司/跨平台的授權”（比如外賣 App 用微信授權）；
• SSO：側重“同一公司內部的統一認證”（比如阿里系產品統一登錄）。

第二部分：授權模型——再判斷“你能做什麼”

認證通過後，系統需要明確“用户能操作哪些資源”。目前主流的授權模型有 3 種，實際系統常混合使用。

1. 最常用：RBAC（基於角色的訪問控制）

核心邏輯：“用户→角色→權限”三層映射

先定義“角色”，給角色分配“權限”，再把角色分配給用户——不用給每個用户單獨設置權限，管理起來很簡單。

示例：

• 角色 1：Admin（管理員）→ 權限：刪用户、改配置、看所有數據；
• 角色 2：Editor（編輯）→ 權限：改內容、發文章、不能刪用户；
• 角色 3：Viewer（查看者）→ 權限：只能看內容，不能改。

適合場景

• 絕大多數系統（Stripe 控制枱、CMS 工具、企業後台）；
• 權限層級清晰、變化不頻繁的場景（比如公司只有“管理員/編輯/普通用户”三類角色）。

優勢：簡單、易擴展

比如公司新增 10 個“編輯”，不用給每個人分配“發文章”權限——直接把“Editor”角色分配給他們就行，管理成本極低。

2. 最靈活：ABAC（基於屬性的訪問控制）

核心邏輯：“屬性+條件”動態判斷

不依賴固定角色，而是根據“用户屬性”“資源屬性”“環境屬性”動態判斷權限。條件可以寫得很精細，比如：

允許操作 = （用户部門 == "HR"） && （操作時間 < 18:00） && （資源類型 == "員工檔案"）

適合場景

• 權限規則複雜、需要動態調整的場景；
• 行業特定需求（比如銀行系統：“只有本支行員工，在工作時間內，才能查看本支行客户的賬户信息”）。

優勢與缺點

• 優勢：靈活性極高，能滿足複雜業務規則；
• 缺點：複雜度高，需要專門的“政策引擎”管理規則（比如 Auth0、Keycloak），小系統用起來沒必要。

3. 最精細：ACL（基於訪問控制列表）

核心邏輯：“資源→用户/組”直接映射

給每個資源單獨設置“訪問控制列表（ACL）”，明確“哪些用户/組能操作這個資源”。

示例：

• 資源：你在 Google Drive 的“2024 財務報表。xlsx”;

• ACL 設置：

  • 張三：可編輯；
  • 李四：可評論；
  • 其他同事：只能查看。

適合場景

• 資源粒度極細的場景（雲存儲文件、個人項目協作）；
• 用户需要自主管理資源權限的場景（比如你分享自己的文件給同事）。

優勢與缺點

• 優勢：權限控制到單個資源，粒度最細；
• 缺點：難擴展——如果有 100 萬個文件，每個文件都要維護 ACL，管理成本會爆炸（除非用工具抽象，比如阿里雲 OSS 的訪問控制）。

第三部分：實戰結合——認證與授權怎麼搭配用？

實際系統裏，認證和授權不是孤立的，而是配合工作的。舉幾個常見搭配案例：

案例 1：中小型後台系統（RBAC + JWT）

1. 認證：用户用賬號密碼登錄，服務器生成 JWT（載荷包含userId和role）；
2. 授權：前端每次請求帶 JWT，後端解析出role，用 RBAC 判斷權限（比如role=admin才能訪問“刪用户”接口）；
3. 優勢：不用存 Session，前後端分離友好，權限管理簡單。

案例 2：第三方登錄 App（OAuth 2.0 + RBAC）

1. 認證：用户用“微信登錄”App，App 通過 OAuth 2.0 拿到微信的“訪問令牌”，獲取用户暱稱/頭像；
2. 授權：App 給用户分配“普通用户”角色（RBAC），用户只能操作“下單”“查訂單”等權限；
3. 優勢：用户不用註冊新賬號，App 不用存用户密碼，安全又方便。

案例 3：企業內部系統（SSO + ABAC）

1. 認證：用户登錄“企業認證中心”（SSO），之後訪問 OA、CRM 系統不用再登錄；
2. 授權：訪問“員工檔案”時，系統用 ABAC 判斷（比如“HR 部門員工+工作時間”才能查看）；
3. 優勢：統一認證提升體驗，複雜條件滿足企業合規需求（比如 GDPR、等保）。

第四部分：選型指南——不同場景該怎麼選？

用一張表總結所有技術/模型的核心差異，幫你快速選型：

結尾：學習資源推薦

如果想深入實戰，推薦兩個方向：

1. 工具實踐：用 Keycloak（開源認證授權工具）搭建 SSO+RBAC 系統，國內可訪問文檔：Keycloak 中文指南；
2. 視頻學習：原作者的 YouTube 視頻（若無法訪問，可搜 B 站“OAuth2 JWT 實戰”，有很多國內開發者的講解）。

認證授權是系統安全的基石，別一開始就用“最複雜的方案”——先明確業務需求，再選最適合的技術，才是高效的開發思路～