接口權限驗證是保障 API 安全的核心機制，常見的方式有以下幾類，適用于不同場景和安全需求：

1. 基于令牌（token）的驗證

（1）JWT（JSON Web Token）

原理：
服務器驗證用戶身份后，生成包含用戶信息（如角色、權限）的加密令牌（Header.Payload.Signature），返回給客戶端。客戶端后續請求時在 Header 中攜帶令牌，服務器解密并驗證簽名有效性。

流程：
用戶登錄 → 服務器生成 JWT → 客戶端存儲（localStorage/cookie）
客戶端請求接口 → Header 攜帶 Authorization: Bearer
服務器驗證 token 有效性 → 解析權限信息 → 允許 / 拒絕訪問

特點：
無狀態（服務器不存儲 token），適合分布式系統；token 可包含權限信息，減少數據庫查詢；過期時間可控。

（2）OAuth 2.0 + Token

原理：
第三方授權協議，允許用戶通過第三方平臺（如微信、GitHub）授權訪問資源，核心是通過授權服務器生成訪問令牌（Access Token）。

場景：
開放平臺（如微信支付 API、GitHub API），允許第三方應用有限度訪問用戶資源。

流程：
授權碼模式（最常用）→ 用戶授權 → 第三方應用獲取授權碼 → 換取 Access Token → 用 Token 調用接口。

2. 基于 Session 的驗證

原理：
用戶登錄后，服務器創建 Session（存儲用戶信息和權限），生成 Session ID 返回給客戶端（通常存在 Cookie 中）。客戶端后續請求攜帶 Session ID，服務器通過 ID 查找 Session 驗證權限。

特點：
服務器需存儲 Session（內存 / Redis），有狀態；依賴 Cookie，可能受 CSRF 攻擊（需配合 CSRF Token 防護）；適合單體應用。

3. 基于 API 密鑰（API Key）的驗證

原理：
服務端為客戶端分配唯一 API Key（如字符串密鑰），客戶端請求時在 Header / 參數中攜帶，服務器驗證 Key 的有效性和關聯權限。

場景：
內部服務間調用、第三方合作接口（如天氣 API、支付接口）。
示例：Header: X-API-Key: abc123456

特點：
簡單易實現，但 Key 明文傳輸風險高，需配合 HTTPS；適合服務級別的驗證，而非用戶級。

4. 基于 HMAC 簽名的驗證

原理：
客戶端按規則（如時間戳 + 請求參數 + 密鑰）生成哈希簽名（如 SHA256），與請求一起發送。服務器用相同規則重新計算簽名，對比一致性驗證身份和數據完整性。

特點：
密鑰不直接傳輸，防篡改；通常結合時間戳防止重放攻擊（如簽名有效期 5 分鐘）；適合高安全性接口（如金融、支付）。

5. 基于角色的訪問控制（RBAC）

原理：
不直接驗證用戶，而是驗證用戶所屬的角色和角色對應的權限（如管理員、普通用戶）。權限與角色綁定，角色與用戶綁定。

流程：
預定義角色（如 admin、user）和權限（如 read:data、write:data）
用戶登錄后，服務器獲取其角色 → 檢查角色是否擁有接口所需權限

特點：
靈活易擴展，適合多用戶、多權限場景（如后臺管理系統）；常與 Token/Session 結合使用。

6. 基于 IP 的訪問控制

原理：
服務器配置允許訪問的 IP 白名單，僅白名單內的 IP 地址可調用接口。

場景：
內部服務間固定 IP 通信（如數據庫接口、內部統計 API），不暴露給公網。

特點：
簡單直接，但 IP 可偽造（需結合其他驗證）；適合限制來源的封閉場景。

7. 組合驗證方式

實際開發中常結合多種方式提升安全性，例如：

• JWT + RBAC：Token 攜帶用戶角色，服務器驗證 Token 后檢查角色權限。
• API Key + HMAC：服務間通信時，用 API Key 標識身份，HMAC 確保請求未被篡改。
• Session + CSRF Token：基于 Session 驗證時，添加 CSRF Token 防止跨站請求偽造。