【筆記】API 接口簽名驗證

寫在前面：

很多時候在開發對外接口的時候，為了保證接口的安全以及服務的穩定，要對接口的通路添加一定的限制規則。

那麼就有幾個問題需要注意一下：

1. 請求參數是否被篡改；
2. 請求來源是否合法；
3. 請求是否具有唯一性；

參數簽名方式：

定義規則：

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

1. 接口提供方給出 appid 和 appsecret
2. 調用方根據 appid 和 appsecret 以及請求參數，按照一定算法生成簽名 sign
3. 接口提供方驗證簽名

生成簽名的步驟如下：

1. 将所有業務請求參數按字母先後順序排序
2. 參數名稱和參數值連結成一個字元串 A
3. 在字元串 A 的首尾加上 appsecret 組成一個新字元串 B
4. 對字元串進行 md5 得到簽名 sign
5. 假設請求的參數為：f=1,b=23,k=33，排序後為 b =23,f=1,k=33，參數名和參數值連結後為 b23f1k33，首尾加上 appsecret 後 md5：
6. md5(secretkey1value1key2value2…secret)。

以上簽名方法安全有效地解決了參數被篡改和身份驗證的問題，如果參數被篡改，沒事，因為别人無法知道 appsecret，也就無法重新生成新的 sign。

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

請求唯一性保證：

md5 簽名方法可以保證來源及請求參數的合法性，但是請求連結一旦洩露，可以反複請求，對于某些拉取資料的接口來說并不是一件好事，相當于是洩露了資料。

在請求中帶上時間戳，并且把時間戳也作為簽名的一部分，在接口提供方對時間戳進行驗證，隻允許一定時間範圍内的請求，例如 1 分鐘。

因為請求方和接口提供方的伺服器可能存在一定的時間誤差，建議時間戳誤差在 5 分鐘内比較合适。允許的時間誤差越大，連結的有效期就越長，請求唯一性的保證就越弱。是以需要在兩者之間衡量。

秘鑰的儲存：

在簽名的過程中，起到決定性作用之一的是 appsecret，是以如何儲存成為關鍵。

我們分類讨論：

接口調用方的代碼跑在伺服器的情況比較好辦，除非伺服器被攻陷，否則外接無法知道 appsecret，當然，要注意不能往日志裡寫入 appsecret 的值，其他敏感值也禁止寫入日志，如賬号密碼等資訊。

假如是用戶端請求接口，就需要多想一步了。假如把 appsecret 寫死到用戶端，會有反編譯的風險，特别是 android。可以在用戶端登陸驗證成功後，傳回給用戶端的資訊中帶上 appsecret(當然，傳回的資料也可能被攔截，真是防不勝防啊。。。)。

特别說明一下，在 android 開發中，假如硬要把 appsecret 寫死，建議把 appsecret 放到 NDK 中編譯成 so 檔案，app 啟動後去讀取。

喜歡(2) 打賞