API介面簽名驗證2

2021-09-26 10:04:32 字數 1556 閱讀 1781

系統從外部獲取資料時,通常採用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分鐘。因為請求方和介面提供方的伺服器可能存在一定的時間誤差,建議時間戳誤差在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介面呼叫的方式來實現。請求方和 介面提供方之間的通訊過程,有這幾個問題需要考慮 1 請求引數是否被篡改 2 請求 是否合法 3 請求是否具有唯一性。今天跟大家 一下主流的通訊安全解決方案。引數簽名方式 這種方式是主流。它要求呼叫方按照約定好的演算法生成簽名字串,作...