API介面簽名驗證

2022-03-11 12:12:41 字數 1729 閱讀 8898

系統從外部獲取資料時,通常採用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等。

請求唯一性保證

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

秘鑰的儲存

totp:time-based one-time password algorithm(基於時間的一次性密碼演算法)

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

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

【服務端簽名校驗總關口放在應用程式級別,不必乙個乙個介面進行校驗】

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

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

totp流程

webos

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

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

API介面簽名驗證

系統從外部獲取資料時,通常採用api介面呼叫的方式來實現。請求方和介面提供方之間的通訊過程,有這幾個問題需要考慮 1 請求引數是否被篡改 2 請求 是否合法 3 請求是否具有唯一性。今天跟大家 一下主流的通訊安全解決方案。引數簽名方式 這種方式是主流。它要求呼叫方按照約定好的演算法生成簽名字串,作為...

API介面簽名驗證

api介面分為開放介面和私密介面。什麼是開放介面?什麼是私密介面?我們乙個乙個介紹它們簽名的驗證,先介紹開放api介面。下面我們稱呼發布介面方為 api arg1 value1,name fdfd,age 12 按照引數名的字母前後順序進行重新排序 3.然後再將排序好的引數,加上secrte 加上當...

開放api介面簽名驗證

在寫開放的api介面時如何保證資料的安全性?先來看看有哪些安全性問題在開放的api介面中,我們通過http post或者get方式請求伺服器的時候,會面臨著許多的安全性問題,例如 請求 身份 是否合法?請求引數被篡改?請求的唯一性 不可複製 為了保證資料在通訊時的安全性,我們可以採用引數簽名的方式來...