API介面簽名驗證

系統從外部獲取資料時，通常採用api介面呼叫的方式來實現。請求方和介面提供方之間的通訊過程，有這幾個問題需要考慮：

1、請求引數是否被篡改；

2、請求**是否合法；

3、請求是否具有唯一性。

今天跟大家**一下主流的通訊安全解決方案。

引數簽名方式

這種方式是主流。它要求呼叫方按照約定好的演算法生成簽名字串，作為請求的一部分，介面提供方驗算簽名即可知是否合法。步驟通常如下：

③介面提供方驗證簽名

生成簽名的步驟如下：

①將所有業務請求引數按字母先後順序排序

②引數名稱和引數值鏈結成乙個字串a

④對字串進行md5得到簽名sign

簽名的php版本實現：?

if (!is_array($params))

$params = array();

ksort($params);

$text = '';

foreach ($params as $k => $v)

}

介面呼叫方的請求位址類似於：?

/api/?f=1&b=23&k=33&sign=signvalue

這裡使用了md5的演算法進行簽名，也可以自行選擇其他簽名方式，例如rsa，sha等。

請求唯一性保證

md5簽名方法可以保證**及請求引數的合法性，但是請求鏈結一旦洩露，可以反覆請求，對於某些拉取資料的介面來說並不是一件好事，相當於是洩露了資料。

在請求中帶上時間戳，並且把時間戳也作為簽名的一部分，在介面提供方對時間戳進行驗證，只允許一定時間範圍內的請求，例如1分鐘。因為請求方和介面提供方的伺服器可能存在一定的時間誤差，建議時間戳誤差在5分鐘內比較合適。允許的時間誤差越大，鏈結的有效期就越長，請求唯一性的保證就越弱。所以需要在兩者之間衡量。

秘鑰的儲存

totp：time-based one-time password algorithm（基於時間的一次性密碼演算法）

在一些小型專案中，可能不需要複雜的簽名校驗，只需要做呼叫方的身份驗證。totp (rfc6238)即可滿足。

totp是基於時間的一次性演算法，客戶端和伺服器端約定秘鑰，加入時間作為運算因子得到乙個6位數字。客戶端請求服務端時生成乙個6位數字，服務端使用相同演算法驗證這個6位數字是否合法。

下面再展開一下討論，跟本文討論的主題關係不大。

與totp類似的還有htop，它是基於次數的驗證演算法。這裡不展開討論。

webos

支付寶、qq令牌、銀行客戶端等這些手機客戶端中也有類似的應用，在驗證密碼之後會多出一道動態口令的驗證，他們使用的方案都類似於google-authenticator。

大公司的運維人員，甚至是所有員工登入內部oa系統（單點登入），都需要pin+令牌碼的雙重驗證（pin是自行設定的固定密碼，令牌碼則是動態口令碼），他們通常使用rsa securid雙因素動態口令身份認證解決方案。