認證與授權全攻略：從 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 流程，國內大廠基本都用它：
- 外賣 App 跳轉到微信登錄頁，你輸入微信密碼完成認證；
- 微信給 App 返回一個“授權碼”（臨時、一次性有效）；
- App 拿着“授權碼”向微信服務器申請“訪問令牌（Access Token）”；
- 微信返回“訪問令牌”，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）
- 認證：用户用賬號密碼登錄，服務器生成 JWT（載荷包含
userId和role）； - 授權：前端每次請求帶 JWT，後端解析出
role，用 RBAC 判斷權限（比如role=admin才能訪問“刪用户”接口）； - 優勢：不用存 Session，前後端分離友好，權限管理簡單。
案例 2：第三方登錄 App（OAuth 2.0 + RBAC）
- 認證：用户用“微信登錄”App，App 通過 OAuth 2.0 拿到微信的“訪問令牌”，獲取用户暱稱/頭像；
- 授權：App 給用户分配“普通用户”角色（RBAC），用户只能操作“下單”“查訂單”等權限；
- 優勢：用户不用註冊新賬號，App 不用存用户密碼，安全又方便。
案例 3：企業內部系統（SSO + ABAC）
- 認證：用户登錄“企業認證中心”（SSO），之後訪問 OA、CRM 系統不用再登錄；
- 授權：訪問“員工檔案”時，系統用 ABAC 判斷（比如“HR 部門員工+工作時間”才能查看）；
- 優勢：統一認證提升體驗，複雜條件滿足企業合規需求（比如 GDPR、等保）。
第四部分：選型指南——不同場景該怎麼選？
用一張表總結所有技術/模型的核心差異，幫你快速選型：
| 類型 | 技術/模型 | 核心優勢 | 適合場景 | 避坑點 |
|---|---|---|---|---|
| 認證技術 | Basic Auth | 實現簡單 | 內部極小系統（搭配 HTTPS） | 別用在公開系統，Base64 易解碼 |
| Bearer Auth | Token 可吊銷，比 Basic 靈活 | 中小型前後端分離項目 | Token 要防 XSS（前端別存 localStorage） | |
| OAuth 2.0 | 第三方授權，不用傳密碼 | 第三方登錄、跨系統權限共享 | 公開 App 用“授權碼模式”，別用“密碼模式” | |
| JWT | 無狀態，適合分佈式 | 前後端分離、多服務共享用户信息 | 載荷不存敏感數據，密鑰要保管好 | |
| SSO | 多系統統一登錄 | 企業內部多系統、同公司多產品 | 認證中心要高可用，否則所有系統癱瘓 | |
| 授權模型 | RBAC | 簡單易管理，易擴展 | 絕大多數系統（後台、CMS） | 別過度設計角色（比如角色超過 10 個） |
| ABAC | 靈活，支持複雜規則 | 銀行、醫療等合規要求高的場景 | 小系統別用，複雜度高 | |
| ACL | 權限粒度細，用户可自主 | 雲存儲、個人文件協作 | 資源多了難擴展，需工具抽象 |
結尾：學習資源推薦
如果想深入實戰，推薦兩個方向：
- 工具實踐：用 Keycloak（開源認證授權工具）搭建 SSO+RBAC 系統，國內可訪問文檔：Keycloak 中文指南；
- 視頻學習：原作者的 YouTube 視頻（若無法訪問，可搜 B 站“OAuth2 JWT 實戰”，有很多國內開發者的講解）。
認證授權是系統安全的基石，別一開始就用“最複雜的方案”——先明確業務需求，再選最適合的技術，才是高效的開發思路～
