在APP開放接口API的設計中，避免不了的就是安全性問題。
一、https協議
對於一些敏感的API接口，需要使用https協議。https是在http超文本傳輸協議加入SSL層，它在網絡間通信是加密的，所以需要加密證書。
二、設計簽名
原理：用戶登錄時向服務器提供用戶認證信息（如賬號和密碼），服務器認證完后給客戶端返回一個Token令牌，用戶再次獲取信息時，需帶上此令牌。如果令牌正確，則返回數據。
對於獲得Token令牌信息后，訪問用戶相關接口，客戶端請求的url需要帶上如下參數：
時間戳：timestamp
Token令牌：token
Sign簽名：sign
Sign生成規則可以是：將所有用戶請求的參數按照字母排序（包括timestamp、token），然后根據MD5（可以加點salt），全部大寫，生成sign簽名，這就是所說的url簽名算法。
然后登陸后每次調用用戶信息時，帶上sign、timestamp、token參數。
三、具體實現
1、客戶端向服務器端發送用戶認證信息（如用戶名和密碼），服務器端接收到請求后，驗證用戶信息是否正確。
如果正確：則返回一個唯一不重復的字符串（一般為UUID），然后在Redis中維護Token——Uid的用戶信息關系，以便其他API對token驗證。
如果錯誤：則返回錯誤代碼。
2、服務器設計一個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都需要攔截。