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