為什么要做API 接口簽名？

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

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

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

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

請求是否合法：是否是我規(guī)定的那個人

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

防止重復(fù)請求（防重放）：是否重復(fù)請求

簽名算法邏輯

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

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

在params的最后再拼接appKey密鑰

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

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

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

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

防重放攻擊

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

timestamp

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

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

nonce

nonce 是由請求方生成的隨機數(shù)（在規(guī)定的時間內(nèi)保證有充足的隨機數(shù)產(chǎn)生，即在10s 內(nèi)產(chǎn)生的隨機數(shù)重復(fù)的概率為0）也作為參數(shù)之一加入 sign 簽名。

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。