APP開放接口API安全性——Token令牌Sign簽名的設計與實現

　　在APP開放接口API的設計中，避免不了的就是安全性問題。

　　1、https協議

　　對於一些敏感的API接口，須要使用https協議。https是在http超文本傳輸協議加入SSL層，它在網絡間通訊是加密的，因此須要加密證書。

　　2、設計簽名

　　原理：用戶登陸時向服務器提供用戶認證信息（如帳號和密碼），服務器認證完後給客戶端返回一個Token令牌，用戶再次獲取信息時，需帶上此令牌。若是令牌正確，則返回數據。

　　對於得到Token令牌信息後，訪問用戶相關接口，客戶端請求的url須要帶上以下參數：

　　時間戳：timestamp

　　Token令牌：token

　　Sign簽名：sign

　　Sign生成規則能夠是：將全部用戶請求的參數按照字母排序（包括timestamp、token），而後根據MD5（能夠加點salt），所有大寫，生成sign簽名，這就是所說的url簽名算法。

　　而後登錄後每次調用用戶信息時，帶上sign、timestamp、token參數。

　　3、具體實現

　　一、客戶端向服務器端發送用戶認證信息（如用戶名和密碼），服務器端接收到請求後，驗證用戶信息是否正確。

　　若是正確：則返回一個惟一不重複的字符串（通常爲UUID），而後在Redis中維護Token——Uid的用戶信息關係，以便其餘API對token驗證。

　　若是錯誤：則返回錯誤代碼。

　　二、服務器設計一個url請求攔截規則

　　（a）、判斷是否包含timestamp、token、sign參數，若是不含或缺乏，則返回錯誤代碼。

　　（b）、判斷服務器接到請求的時間和參數中的時間戳（timestamp）是否相差很長一段時間（時間自定義如半小時），若是超過則說明該url已通過期（若是url被盜，他改變了時間戳，可是會致使sign簽名不相等）。

　　（c）、判斷token是否有效，根據請求過來的token，查詢Redis緩存中的Uid，若是獲取不到這說明token已過時。

　　（d）、根據用戶請求的url參數，服務器端按照一樣的規則生成sign簽名，對比簽名是否相等，若是相等，則放行。（天然url簽名，也沒法100%保證其安全，也能夠經過公鑰AES對數據和url加密，但這樣沒法確保公鑰丟失，因此簽名只是很大程度上保證安全）。

　　（e）、此url攔截只需對獲取身份認證的url放行（如登陸url），其餘全部的url都須要攔截。