開放api接口簽名驗證

不要急，源代碼分享在最底部，先問你們一個問題，你在寫開放的API接口時是如何保證數據的安全性的？先來看看有哪些安全性問題在開放的api接口中，咱們經過http Post或者Get方式請求服務器的時候，會面臨着許多的安全性問題，例如：

1. 請求來源(身份)是否合法？
2. 請求參數被篡改？
3. 請求的惟一性(不可複製)

爲了保證數據在通訊時的安全性，咱們能夠採用參數簽名的方式來進行相關驗證。

案列分析

咱們經過給某 [移動端(app)] 寫 [後臺接口(api)] 的案例進行分析：     

   客戶端： 如下簡稱app   

後臺接口：如下簡稱api

咱們經過app查詢產品列表這個操做來進行分析：

app中點擊查詢按鈕==》調用api進行查詢==》返回查詢結果==>顯示在app中

上代碼啦 -_-！

1、不進行驗證的方式

api查詢接口：

app調用：http://api.test.com/getproducts?參數1=value1.......

如上，這種方式簡單粗暴，經過調用getproducts方法便可獲取產品列表信息了，可是 這樣的方式會存在很嚴重的安全性問題，沒有進行任何的驗證，你們均可以經過這個方法獲取到產品列表，致使產品信息泄露。
那麼，如何驗證調用者身份呢？如何防止參數被篡改呢？

2、MD5參數簽名的方式

咱們對api查詢產品接口進行優化：

1.給app分配對應的key、secret

2.Sign簽名，調用API 時須要對請求參數進行簽名驗證，簽名方式以下： 

    a. 按照請求參數名稱將全部請求參數按照字母前後順序排序獲得：keyvaluekeyvalue...keyvalue  字符串如：將arong=1,mrong=2,crong=3 排序爲：arong=1, crong=3,mrong=2  而後將參數名和參數值進行拼接獲得參數字符串：arong1crong3mrong2。 

    b. 將secret加在參數字符串的頭部後進行MD5加密 ,加密後的字符串需大寫。即獲得簽名Sign

新api接口代碼:

app調用：http://api.test.com/getproducts?key=app_key&sign=BCC7C71CF93F9CDBDB88671B701D8A35&參數1=value1&參數2=value2.......

注：secret 僅做加密使用, 爲了保證數據安全請不要在請求參數中使用。

 

如上，優化後的請求多了key和sign參數，這樣請求的時候就須要合法的key和正確簽名sign才能夠獲取產品數據。這樣就解決了身份驗證和防止參數篡改問題，若是請求參數被人拿走，沒事，他們永遠也拿不到secret,由於secret是不傳遞的。再也沒法僞造合法的請求。

可是...這樣就夠了嗎？細心的同窗可能會發現，若是我獲取了你完整的連接，一直使用你的key和sign和同樣的參數不就能夠正常獲取數據了...-_-!是的，僅僅是如上的優化是不夠的

請求的惟一性：

爲了防止別人重複使用請求參數問題，咱們須要保證請求的惟一性，就是對應請求只能使用一次，這樣就算別人拿走了請求的完整連接也是無效的。
惟一性的實現：在如上的請求參數中，咱們加入時間戳 ：timestamp（yyyyMMddHHmmss），一樣，時間戳做爲請求參數之一，也加入sign算法中進行加密。

新的api接口：

app調用：
http://api.test.com/getproducts?key=app_key&sign=BCC7C71CF93F9CDBDB88671B701D8A35&timestamp=201603261407&參數1=value1&參數2=value2.......

如上，咱們經過timestamp時間戳用來驗證請求是否過時。這樣就算被人拿走完整的請求連接也是無效的。

Sign簽名安全性分析：

經過上面的案例，咱們能夠看出，安全的關鍵在於參與簽名的secret，整個過程當中secret是不參與通訊的，因此只要保證secret不泄露，請求就不會被僞造。

總結

上述的Sign簽名的方式可以在必定程度上防止信息被篡改和僞造，保障通訊的安全，這裏使用的是MD5進行加密，固然實際使用中你們能夠根據實際需求進行自定義簽名算法，好比：RSA，SHA等。

 

源碼下載：

源代碼：http://git.oschina.net/daimali/Daimali.ISV

歡迎關注我的技術類公衆號CodeL