用戶65223819029
在app開放接口API的設計中，避免不了的就是安全性問題。
一、https協議
對於一些敏感的API接口，需要使用https協議。
https是在http超文本傳輸協議加入SSL層，它在網絡間通信是加密的，所以需要加密證書。
二、簽名設計
原理：用戶登錄後向服務器提供用戶認證信息（如賬戶和密碼），服務器認證完後給客戶端返回一個Token令牌，用戶再次獲取信息時，帶上此令牌，如果令牌正確，則返回數據。對於獲取Token信息後，訪問用戶相關接口，客戶端請求的url需要帶上如下參數：
時間戳：timestamp
Token令牌：token
然後將所有用戶請求的參數按照字母排序（包括timestamp，token），然後更具MD5加密（可以加點鹽），全部大寫，生成sign簽名，這就是所說的url簽名算法。然後登陸後每次調用用戶信息時，帶上sign，timestamp，token參數。
其最終的原理是減小明文的暴露次數；保證數據安全的訪問。
具體實現如下：
1. 客戶端向服務器端發送用戶認證信息（用戶名和密碼），服務器端接收到請求後，驗證用戶信息是否正確。
如果正確：則返回一個唯一不重複的字符串（一般為UUID），然後在Redis（任意緩存服務器）中維護Token----Uid的用戶信息關係，以便其他API對token的校驗。
如果錯誤：則返回錯誤碼。
2.服務器設計一個url請求攔截規則
（1）判斷是否包含timestamp，token，sign參數，如果不含有返回錯誤碼。
（2）判斷服務器接到請求的時間和參數中的時間戳是否相差很長一段時間（時間自定義如半個小時），如果超過則說明該 url已經過期（如果url被盜，他改變了時間戳，但是會導致sign簽名不相等）。
（3）判斷token是否有效，根據請求過來的token，查詢redis緩存中的uid，如果獲取不到這說明該token已過期。
（4）根據用戶請求的url參數，服務器端按照同樣的規則生成sign簽名，對比簽名看是否相等，相等則放行。（自然url簽名 也無法100%保證其安全，也可以通過公鑰AES對數據和url加密，但這樣無法確保公鑰丟失，所以簽名只是很大程度上保證安全）。
希望採納！
i網絡心連心
按照我之前的經驗通常是用通信密鑰隨機數時間戳進行隨機加密，服務端通過通信密鑰獲得約定的私鑰，然後根據傳入的時間戳和隨機數使用相同的加密方法獲得認證值，然後比對客戶端和服務端的認證，只是否一致，如果一致的話，則放行如果不一致的話就攔截。由於時間出和隨機數是隨機變更的，因此每次加密出來的token是不一樣的，因此可以在一定程度上防止T O K E N冒用。
看影天下
TOKEN作為用戶身份憑證並不能保證數據安全，別人通過抓包等方式很容易拿到TOKEN，帶上TOKEN請求我們的API接口就能獲取數據；其實換一個角度想：我們只需保證即使TOKEN被別人冒用，也不能調用我們API接口就行。
分享一個前後端使用AES和RSA混合加密通信的方案。
AES對稱加密
首先看一下AES加密的示意圖：
加密過程為：發送方（APP）使用密鑰對參數明文進行AES加密獲得密文，然後將密文和密鑰一起發給接收方（服務端），接收方使用密鑰對密文進行AES解密，得到參數明文。
AES由於是對稱加密算法，特點就是加解密運算速度快；由於加解密使用的是同一個密鑰，所以缺點就是在傳輸過程中會存在密鑰洩露的風險。
RSA非對稱加密
同樣的，先來看一下RSA加密的示意圖：
首先接收方（服務端）生成一對RSA密鑰（公鑰、私鑰），私鑰自己保存同時公鑰公佈給發送方（APP）。
加密過程：發送方使用接收方公鑰將參數明文進行RSA加密得到密文，並將密文發送給接收方，接收方使用自己的私鑰對密文進行RSA解密得到參數明文。
同樣的，服務端返回數據給APP時也可以使用私鑰對數據進行簽名，APP可以使用服務端的公鑰來驗證簽名，從而判斷數據是否來自合法的服務端。
RSA是非對稱加密算法，加解密大量數據速度較慢，但由於加解密使用不同的密鑰，所以安全度較高。
介於這兩種加密方式各有優缺點，所以前後端加密通信方案通常採用AES對稱加密算法對參數進行加密，RSA非對稱加密算法則只用來對AES密鑰進行加密，兩種加密方式混合使用既不會太影響通信速度，又保證了通信安全。
為了防止重放攻擊，我們還需要在AES+RSA混合加密的基礎上再加入時間戳、隨機字符串以及數字簽名等校驗邏輯。
為了防止中間人攻擊，首先HTTPS是必須的，除此之外前後端還需要互相進行身份認證，確保通信沒有被劫持。
前後端加密通信完整流程
準備工作：服務端生成RSA密鑰對（公鑰、私鑰），公鑰下發給APP，自己持有私鑰；APP也需要生成RSA密鑰對（公鑰、私鑰），公鑰上傳到服務端保存、私鑰自己保留。
首先展示一下我用代碼實現的前後端完整的加解密通信流程：
首先講一下APP調用接口時的加密流程：
- 隨機生成一個AES加密算法的密鑰，用於後續加密；
- 使用服務端的RSA公鑰對步驟1中生成的AES密鑰明文進行RSA加密生成密鑰密文；
- 使用AES密鑰明文對參數明文進行AES加密生成參數密文；
- 生成當前時間的時間戳；
- 生成一串隨機字符串；
- 將參數密文、AES密鑰密文、時間戳、隨機字符串進行MD5計算，得到md5值；
- 使用APP自己的RSA私鑰對md5值簽名，得到簽名值；
- 最後將參數密文、AES密鑰密文、時間戳、隨機字符串、簽名值一起發送到服務端；
再來講一下服務端收到請求後的解密流程：
- 對比請求參數中時間戳與服務器端獲取的當前時間戳，判斷兩者差值是否在一定的時間之內，超過則認為請求過期；
- 從系統緩存中查找參數中隨機字符串是否已存在，如果已存在則認為是一次重複請求，不存在則將該隨機字符串放入緩存；
- 將參數密文、AES密鑰密文、時間戳、隨機字符串進行MD5計算，得到md5值
- 使用客戶端上傳的RSA公鑰驗證參數中的簽名是否來自合法授權的客戶端，防止非法客戶端篡改數據；
- 使用自己的RSA私鑰解密AES密鑰密文，得到AES明文密鑰；
- 使用AES明文密鑰解密參數密文得到參數明文；
- 進行正常的業務處理流程；
- 返回數據加密流程與客戶端加密流程一致；
總結
要保證APP與API通信安全，首先要使用HTTPS協議，同時前後端還需要使用AES+RSA混合加密的方式來對數據進行加密，另外為了防止重放攻擊、中間人攻擊，還需要在數據加密的基礎上加入時間戳、隨機字符串以及數字簽名等校驗手段進一步提高通信的安全性。
萌新程序員成長日記
大部分回答的不是提問者問的吧？token冒用有可能導致你的服務端完全暴露給攻擊者。相當於小偷夜間撬開了被盜者的家門，隨後自己想想吧。
防範措施目前我能想到可能有以下幾種:
https
token設置生效時間
token註銷/強T
客戶端和服務端動態同步更新
鳳姬
去看看淘寶開放平臺的接口吧。簡單來說，就是對請求參數進行簽名，服務器和客戶端約好秘鑰，秘鑰是不會在網絡傳輸的過程中傳遞的，然後發起請求的時候對參數進行簽名。別人即使拿到了token，想偽造一個請求，那還得知道秘鑰才行。
Jersey49441642
關於這一點
我是採用的雙token來實現的
一個長時效token例如一個星期過期
一個短時效的token 大概一個小時或者兩個小時或者更短
短時效token過期並且長時效token沒有過期就重新下發短時效token
如果兩個token都過期就需要用戶重新登錄
這樣就解決了用戶登錄次數和token安全風險矛盾問題
MINKSE
當下網絡上，“token”技術的推廣（力度），應該引起相關部門“警覺”了吧？“token”的固有問題那麼危險，那麼多的“推廣人”真的不懂、不不知道嗎？搞公共安全的公司，不應該站出來嗎？
井151276607
一次一密，多因子，加密
