三層 API 驗證

概述

源自台灣金流串接經驗的 API 驗證機制，由三層防護組成，各自解決不同的安全問題。適用於兩個獨立部署的網站之間的 REST API 通訊。

步驟

第一層：API Key — 解決「你是誰」

1. B 站產生 64 字元隨機金鑰
2. 管理員複製 Key 貼到 A 站完成配對
3. B 站只儲存 Key 的 Hash 值，不存明文
4. 每次請求帶上 Key，B 站驗證通過才放行

第二層：SHA-256 簽章 — 解決「請求有沒有被竄改」

1. A 站將三個值串接：目標網站網址 | API Key | 當前時間戳
2. 用 SHA-256 算出 Hash
3. Hash 放在請求 Header 中送出
4. B 站用同樣的材料重新計算，比對一致才通過

第三層：時間戳驗證 — 解決「重送攻擊」

1. 請求帶上發送時的 Unix 時間戳
2. B 站檢查時間戳與當前時間的差異
3. 超過 5 分鐘即拒絕
4. 攻擊者無法修改時間戳（會破壞簽章），也無法重算簽章（不知道 Key）

驗證順序

1. 有沒有帶 API Key → 沒有就擋
2. API Key 是否正確 → 不正確就擋
3. 時間戳是否在 5 分鐘以內 → 過期就擋
4. Hash 比對是否一致 → 不一致就擋

四關全過才放行。

適用場景

• 雙站 API 通訊
• Webhook 接收端驗證
• 第三方整合的回呼驗證

適用邊界：這是一對一的信任模型。 當一個服務方要同時代理 N 個彼此不可見的租戶時，問題從「怎麼證明是你」變成「怎麼讓各租戶可驗證卻無法互相冒充、也無法上溯主憑證」，三層驗證不足以涵蓋，需改用 [[API 中繼站設計流程]]，見 [[一對多信任邊界]]。

限制

• 依賴 HTTPS（簽章不加密）
• 依賴 NTP 時間同步
• 不含權限分級（RBAC）
• Key 管理靠人為紀律
• 僅適用一對一，多租戶場景見上方適用邊界
• 時間戳窗口內的重送仍可成功，需搭配一次性 nonce 才擋得住（實作見 [[重送攻擊防禦]]）

關聯概念

• [[請求簽章]]
• [[API 金鑰管理]]
• [[重送攻擊防禦]]
• [[HMAC 驗證]]
• [[一對多信任邊界]]
• [[API 中繼站設計流程]]