APP接口安全設計

APP接口安全是APP接口設計中一個很重要的環節，良好的安全機制能夠保護後端接口服務不被非法使用，限制和跟蹤用戶訪問狀況。下面是筆者從網上查找一些資料並結合公司實際業務設計的一個APP安全調用時序圖，歡迎你們拍磚，以改良該設計。

該方案分兩部分（公司產品需求）：
1.須要認證的接口
2.不須要認證的接口

須要認證的接口在用戶登陸時，將根據傳入的app_key，生成對應的app_secret，並返回給客戶端，客戶端將存儲該app_secret值。後續請求時，將app_key和由md5(app_key + timestamp + app_secret)生產的簽名寫入請求消息頭中，傳遞到服務器端，由服務器端進行校驗，因爲本案使用Openresty構建了接口網關，因此簽名校驗動做將在該網關中完成，若是簽名校驗成功，則將請求轉發到後端服務器，不然將返回簽名錯誤響應。
在調用不須要認證的接口時，因爲沒法對app_key進行確認，因此只是簡單的根據app_key生成一個ticket，返回給客戶端，客戶端請求時將在請求消息頭中攜帶該ticket值，服務器端進行簡單校驗(ticket是否確實由服務端簽發)。該方案固然沒法真正作到接口安全，畢竟沒有創建信任機制，app_key徹底能夠僞造。但結合公司實際業務，有兩個緣由，能夠接受這一方案。緣由一，公司產品絕大部分業務場景是要求登陸的，免登請求只限於不多一部分展現類的請求，接口被惡意利用的意義不大。緣由二，因爲免登請求有限，因此在服務器端創建白名單機制，白名單上列出全部免登接口URI，限定免登機制的影響範圍，防止非法用戶惡意修改重要業務數據。
方案二中的ticket並不設置過時時間，由於能夠重複獲取ticket，因此設置過時意義不大，用戶在至少一次登陸後，因爲服務端有簽發密鑰，這時 ticket將被清除，在客戶端已獲取密鑰的狀況下，服務端將再也不接收基於ticket機制的接口請求，所有接口請求將走簽名機制。