為什么要做API 接口簽名？

我先描述一個場景：微信中一個好久沒有聊天的朋友突然向你借錢，你會這么想 ？

我想大部分人馬上的反應就是：他是不是被盜號了？他是本人嗎？

其實這個就和公司中前端調用對應的API 或者是提供接口給其他公司調用一樣，在進行數據傳輸的過程中，其實數據都是可以被抓包工具進行截取，甚至被篡改的。因而數據傳輸就存在著極大的危險，為了保證接口的安全性，需要設計一些方式來對接口進行保護，市面上常見的保護措施有 IP 白名單與API接口簽名。
IP 白名單實現起來其實很簡單，使用AOP切面去，斷接口調用者 IP 是否在設定的白名單 IP 之中即可。但是 IP 白名單這種方式有個很大的弊端就是維護白名單 IP 列表成了體力活，調用方增加服務器或者減少服務器就要更新白名單，維護起來異常麻煩。
所以一般來說都會去考慮API接口簽名。

API接口簽名核心需要解決三個問題：

請求是否合法：是否是我規定的那個人

請求是否被篡改：是否被第三方劫持并篡改參數

防止重復請求（防重放）：是否重復請求

簽名算法邏輯

一般來說，接口簽名方式主要是這樣的，所有的接口都需要傳遞這幾個公共參數appKey、 sign、timestamp、nonce，sign 的計算規則為：

拼接接口的所有參數，參數名按照 ASCII 碼從小到大排序，拼接的格式如 k1=v1&k2=v2&k3=v3 得到params

在params的最后再拼接appKey密鑰

通過某種加密算法或通過hash算法得到 sign 值（一般為Base64(HMAC_SHA1(params, appSecret))）

sign加到params 中，將params放入請求頭中發送請求目標接口

以上就是生成簽名的過程。

這樣后端就可以從請求頭中拿到對應的簽名，后端再通過前端相同的算法去生成sign，如果生成的sign和前端請求頭中的sgin相同，則表示該請求并沒有被篡改

防重放攻擊

但是以上措施依然不是最嚴謹的，雖然仿冒者無法輕易模仿簽名規則再生成一模一樣的簽名，可實際上，如果仿冒者監聽并截取到了請求片段，然后把簽名單獨截取出來模仿正式請求方欺騙服務器進行重復請求，這也會造成安全問題，這攻擊方式就叫重放攻擊（replay 攻擊）。
我們一般使用 timestamp + nonce 兩個參數來控制請求有效性，防止重放攻擊。

timestamp

timestamp 由請求端生成，代表著請求發送的時間，將其放到params中一同放在請求頭中發出，同時將timestamp也作為一個參數加入sign的計算之中

后端收到請求后，將timestamp解析出來，判斷當前時間和請求發送的時間是否相差10s（這個時間就由前后端自己商量一個恰當的時間），如果不超出這個時間則認為時間正常，如果超出則直接拋出對應的異常。

nonce

nonce 是由請求方生成的隨機數（在規定的時間內保證有充足的隨機數產生，即在10s 內產生的隨機數重復的概率為0）也作為參數之一加入 sign 簽名。

后端在接受到請求后，將timestamp解析出來，去判定 nonce 是否被請求過(一般請求過的noces會放到redis中），如果redis中存在對應的nonce就證明這次請求是重放攻擊，直接拋出對應的異常

我對于API 接口簽名的大概就是這些，如果有什么不對的地方歡迎指正

總結

以上是生活随笔為你收集整理的API 接口签名的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。