壹般有五種方式：
1、Token授權認證，防止未授權用戶獲取數據；
2、時間戳超時機制；
3、URL簽名，防止請求參數被篡改；
4、防重放，防止接口被第二次請求，防采集；
5、采用HTTPS通信協議，防止數據明文傳輸；
所有的安全措施都用上的話有時候難免太過復雜，在實際項目中需要根據自身情況作出取舍，比如可以只使用簽名機制就可以保證信息不會被篡改，或者定向提供服務的時候只用Token機制就可以了，如何取舍，全看項目實際情況和對接口安全性的要求。
HTTP協議是無狀態的，壹次請求結束，連接斷開，下次服務器再收到請求，它就不知道這個請求是哪個用戶發過來的，但是對我們有權限訪問限制的模塊而言，它是需要有狀態管理的，以便服務端能夠準確的知道HTTP請求是哪個用戶發起的，從而判斷他是否有權限繼續這個請求。
Token的設計方案是用戶在客戶端使用用戶名和密碼登錄後，服務器會給客戶端返回壹個Token，並將Token以鍵值對的形式存放在緩存（壹般是Redis）中，後續客戶端對需要授權模塊的所有操作都要帶上這個Token，服務器端接收到請求後進行Token驗證，如果Token存在，說明是授權的請求。
Token生成的設計要求：
1、應用內壹定要唯壹，否則會出現授權混亂，A用戶看到了B用戶的數據；
2、每次生成的Token壹定要不壹樣，防止被記錄，授權永久有效；
3、壹般Token對應的是Redis的key，value存放的是這個用戶相關緩存信息，比如：用戶的id；
4、要設置Token的過期時間，過期後需要客戶端重新登錄，獲取新的Token，如果Token有效期設置較短，會反復需要用戶登錄，體驗比較差，我們壹般采用Token過期後，客戶端靜默登錄的方式，當客戶端收到Token過期後，客戶端用本地保存的用戶名和密碼在後臺靜默登錄來獲取新的Token，還有壹種是單獨出壹個刷新Token的接口，但是壹定要註意刷新機制和安全問題；
根據上面的設計方案要求，我們很容易得到Token=md5(用戶ID+登錄的時間戳+服務器端秘鑰)這種方式來獲得Token，因為用戶ID是應用內唯壹的，登錄的時間戳保證每次登錄的時候都不壹樣，服務器端秘鑰是配置在服務器端參與加密的字符串（即：鹽），目的是提高Token加密的破解難度，註意壹定不要泄漏；
客戶端每次請求接口都帶上當前時間的時間戳timestamp，服務端接收到timestamp後跟當前時間進行比對，如果時間差大於壹定時間（比如：1分鐘），則認為該請求失效。時間戳超時機制是防禦DOS攻擊的有效手段。
寫過支付寶或微信支付對接的同學肯定對URL簽名不陌生，我們只需要將原本發送給server端的明文參數做壹下簽名，然後在server端用相同的算法再做壹次簽名，對比兩次簽名就可以確保對應明文的參數有沒有被中間人篡改過。
簽名算法：
1、首先對通信的參數按key進行字母排序放入數組中（壹般請求的接口地址也要參與排序和簽名，那麽需要額外添加url=