一個完善的 API 流程標準（草圖）

目的

1. 保證 API 自己是安全的，不會受到如下（包括但不限於）手段的攻擊：

   1. 重入攻擊；

2. 保證調用方是能夠管理的，包括但不限於：

   1. 來源模塊是可控的；

   2. 來源設備是可控的；

   3. 調用頻率是可控的；

3. 整個調用鏈條是可追蹤的，即從接入層一直到數據層是相關的；

設計思路

概念

1. APPID: 標明調用方的惟一標識；

2. JWT: Json Web Token，一種標準化的對稱加密機制；

3. JWT-Signature: 使用 JWT 加密後的密文；

4. LOGID: 由接入層生成的調用鏈條惟一標識；

思路說明

1. 調用方在使用 API 時，須要先進行受權申請，獲取惟一的 APPID 及 APPSECRET；

2. 調用方須要報備調用設備的請求 ip；

3. 調用方須要申請必定的請求頻率（在使用默認值的狀況下，這個步驟能夠忽略）；

4. 調用方在請求 API 時，須要進行以下步驟：

   1. 將下游傳給本身的 LOGID 做爲調用鏈條的惟一標識，繼續向上遊進行傳遞，若是調用方是接入層，則按必定規則生成一個惟一串做爲本次調用鏈條的惟一 LOGID（這個步驟是爲了完成目的 3）；

   2. 使用申請到的 APPSECRET 對包括當前請求時間 + 請求參數的組合的簽名 進行 JWT 加密；

   3. 將 APPID 和 第 2) 步生成的簽名一併傳遞給上游；

5. 服務提供方在接到請求時，按如下步驟驗證其合法性：

   1. APPID、JWT-Signature、LOGID 是否存在，不然不合法；

   2. APPID 是否被受權訪問該 API，不然不合法；

   3. 實際請求 ip 是否和 APPID 報備的請求 ip 匹配，不然不合法；

   4. 根據 APPID 對應的 APPSECRET 解密 JWT-Signature 是否正確，不然不合法；

   5. 請求時間是否超時，不然不合法；

   6. 請求參數的組合的簽名是否一致，不然不合法；

   7. 請求頻率是否小於分配給該 APPID 的頻率限制，不然不合法；

   8. 請求頻率是否小於該 API 的全局頻率限制，不然不合法；

6. 在服務提供方記錄日誌及請求其上游時，將 LOGID 進行記錄及傳遞；