當向外部服務暴露 API 時，確保安全通信至關重要，以防止未經授權的訪問和數據泄露。

兩種常用的 API 安全方法是基于 Token 的身份認證和基于 HMAC（哈希消息認證碼）的認證。

下面我們來介紹這兩種方法的工作原理，并比較它們的不同之處。

圖片

01 基于令牌

• 第 1 步 - 用戶在客戶端輸入密碼，客戶端將密碼發送給驗證服務器。
• 第 2 步 - 驗證服務器驗證憑據并生成一個有有效期的令牌。
• 第 3 步和第 4 步 - 現在，客戶端可以發送請求，客戶端在每個 API 請求的 Authorization 頭中包含這個Token，訪問服務器資源。這種訪問在令牌過期前一直有效。

優點

• 無狀態：服務器不需要維護會話狀態，Token 本身包含驗證所需的所有信息。
• 靈活性：Token 可以包含角色或權限等元數據，支持細粒度的訪問控制。
• 支持 OAuth 集成：與OAuth 2.0 兼容，適合第三方集成場景。

缺點

• Token 泄露風險：如果 Token 被攔截，攻擊者可以在 Token 過期前濫用它，除非有其他機制（如 Token 吊銷）在起作用。
• Token 存儲：客戶端需要安全存儲 Token，對于 Web 或移動應用程序來說，這可能比較復雜。

02 基于 HMAC

該機制使用哈希函數（SHA256 或 MD5）生成消息驗證碼（簽名）。

• 第 1 和 2 步 - 服務器生成兩個密鑰，一個是公共 APP ID（公鑰），另一個是 API 密鑰（私鑰）。
• 第 3 步：現在我們在客戶端生成一個 HMAC 簽名（hmac A）。該簽名是根據圖中列出的一組屬性生成的。
• 第 4 步 - 客戶端發送訪問服務器資源的請求，HTTP 頭中包含 hmac A。
• 第 5 步 - 服務器收到包含請求數據和身份驗證標頭的請求。它從請求中提取必要的屬性，并使用存儲在服務器端的 API 密鑰生成簽名（hmac B。）
• 第 6 和 7 步 - 服務器會比較 hmac A（在客戶端生成）和 hmac B（在服務器端生成）。如果兩者匹配，請求的資源將返回給客戶端。

優點

• 防篡改：HMAC 確保請求在傳輸過程中未被篡改，哪怕只改變一個字節，簽名也會不匹配。
• 簡單：不需要 Token 的發放或刷新，僅依賴共享密鑰和哈希算法。
• 無 Token 泄露風險：因為沒有 Token 可被盜取，這種方法天然安全。

缺點

• 密鑰管理：客戶端和服務器都必須安全地管理和存儲共享密鑰。一旦密鑰泄露，安全性就會受到影響。
• 無狀態 API 較復雜：HMAC 不提供內嵌元數據的無狀態認證，訪問控制需要單獨處理。

在 HMAC 簽名中加入時間戳是為了防止重放攻擊（replay attack）。重放攻擊是一種網絡攻擊方式，攻擊者攔截合法的請求并在之后重復發送相同的請求，試圖偽造身份或重復操作。通過時間戳，服務器可以驗證請求是否在合理的時間范圍內，從而大大提高系統的安全性。