1、https：https SSL證書安裝的搭配(搭配https ssl本地測試環境)
2、接口參數加密+時效性驗證+私鑰 ：實作方式參考
現在，大部分App的接口都采用RESTful架構，RESTFul最重要的一個設計原則就是，用戶端與伺服器的互動在請求之間是無狀态的，也就是說，當涉及到使用者狀态時，每次請求都要帶上身份驗證資訊。實作上，大部分都采用token的認證方式，一般流程是：
1. 使用者用密碼登入成功後，伺服器傳回token給用戶端；
2. 用戶端将token儲存在本地，發起後續的相關請求時，将token發回給伺服器；
3. 伺服器檢查token的有效性，有效則傳回資料，若無效，分兩種情況：
• token錯誤，這時需要使用者重新登入，擷取正确的token
• token過期，這時用戶端需要再發起一次認證請求，擷取新的token
然而，此種驗證方式存在一個安全性問題：當登入接口被劫持時，黑客就擷取到了使用者密碼和token，後續則可以對該使用者做任何事情了。使用者隻有修改密碼才能奪回控制權。
如何優化呢？第一種解決方案是采用HTTPS。HTTPS在HTTP的基礎上添加了SSL安全協定，自動對資料進行了壓縮加密，在一定程式可以防止監聽、防止劫持、防止重發，安全性可以提高很多。不過，SSL也不是絕對安全的，也存在被劫持的可能。另外，伺服器對HTTPS的配置相對有點複雜，還需要到CA申請證書，而且一般還是收費的。而且，HTTPS效率也比較低。一般，隻有安全要求比較高的系統才會采用HTTPS，比如銀行。而大部分對安全要求沒那麼高的App還是采用HTTP的方式。
我們目前的做法是給每個接口都添加簽名。給用戶端配置設定一個密鑰，每次請求接口時，将密鑰和所有參數組合成源串，根據簽名算法生成簽名值，發送請求時将簽名一起發送給伺服器驗證。這樣，黑客不知道密鑰，不知道簽名算法，就算攔截到登入接口，後續請求也無法成功操作。不過，因為簽名算法比較麻煩，而且容易出錯，隻适合對内的接口。如果你們的接口屬于開放的API，則不太适合這種簽名認證的方式了，建議還是使用OAuth2.0的認證機制。
我們也給每個端配置設定一個appKey，比如Android、iOS、微信三端，每個端分别配置設定一個appKey和一個密鑰。沒有傳appKey的請求将報錯，傳錯了appKey的請求也将報錯。這樣，安全性方面又加多了一層防禦，同時也友善對不同端做一些不同的處理政策。
另外，現在越來越多App取消了密碼登入，而采用手機号+短信驗證碼的登入方式，我在目前的項目中也采用了這種登入方式。這種登入方式有幾種好處：
4. 不需要注冊，不需要修改密碼，也不需要因為忘記密碼而重置密碼的操作了；
5. 使用者不再需要記住密碼了，也不怕密碼洩露的問題了；
6. 相對于密碼登入其安全性明顯提高了。
參考文檔