在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加密，但這樣無法確保公鑰丟失，所以簽名只是很大程度上保證安全）。

希望採納！

去看看淘寶開放平臺的介面吧。簡單來說，就是對請求引數進行簽名，伺服器和客戶端約好秘鑰，秘鑰是不會在網路傳輸的過程中傳遞的，然後發起請求的時候對引數進行簽名。別人即使拿到了token，想偽造一個請求，那還得知道秘鑰才行。

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混合加密的方式來對資料進行加密，另外為了防止重放攻擊、中間人攻擊，還需要在資料加密的基礎上加入時間戳、隨機字串以及數字簽名等校驗手段進一步提高通訊的安全性。

“日防夜防，家賊難防。”“打鐵還需自身硬！”養成鐵的紀律，有助於鑄造堅固的城池。本文從八個方面全面排查你的令牌系統。

1 - 注意OAuth憑據的洩漏

你把應用程式程式碼推到GitHub了？

如果那些憑證被竊取了，任何人都可以冒充你。如果你察覺憑據可能已被破壞，請立即重新生成。

2 - 不要在應用程式中硬編碼令牌

為了長時間使令牌有效，並直接寫在應用程式中，用於簡化程式碼可能很有誘惑力。

但，千萬不要這麼做！

3 - 對待令牌就像對待密碼一樣

token就是門鑰匙！令牌和API金鑰允許任何擁有它們的人訪問資源。

因此，令牌和密碼一樣重要。以同樣的方式重視它們！

4 - OAuth不是一個身份驗證協議

OAuth是用於指派對資源的訪問許可權的，它不是一個身份驗證協議。

把token看作是門禁卡。你需要驗證自己以獲得金鑰，它無法區分使用者身份，別人盜用了你的token，就擁有了你的訪問許可權。API提供者堅決不能依賴於令牌作為唯一的身份證明。

您確實應該考慮OpenID Connect (OIDC)，這是一種補充規範，而不是嘗試自己在OAuth上實現身份驗證。OIDC允許使用者與應用程式共享其一部分個人資料，而無需共享其憑證。

5 - 注意在JWTs中儲存的內容，並控制訪問許可權

JWTs可以用宣告的形式儲存大量資訊，如果捕獲了這些資訊，就可以輕鬆地進行解析(除非額外進行了加密)。

如果你使用JWTs來攜帶一些精簡必要的資訊，則可以採用不同的方法：

在客戶端和後端之間，使用不透明字串或基本的JWT。

在後端，驗證請求，並使用請求引數注入新的JWT。許多API閘道器也提供了開箱即用的功能。

如果你希望在整個流中使用相同的令牌，同時可能攜帶敏感資訊，那就對令牌資訊進行加密。也就是說，永遠不要使用JWT來攜帶使用者的憑證。

6 - 從頭至尾徹底驗證JWTs

在伺服器端接收JWT時，必須徹底驗證其內容。

特別是，你應該拒絕任何不符合期望的簽名演算法，或者使用弱演算法，或弱的非對稱/對稱金鑰進行簽名的JWT。

此外，你必須驗證所有payload、過期日期、發行者和使用者。

7 - 不要在本地儲存中儲存令牌！要用就要使用安全的cookies

瀏覽器本地儲存和會話儲存可以從JavaScript讀取，因此儲存敏感資訊(如token)是不安全的。

使用安全cookie、httpOnly標誌和CSRF措施來防止令牌被竊取。

8 - 始終透過HTTPS在請求體中傳輸令牌

這樣做可以限制令牌在執行中被捕獲，避免被寫入代理日誌或伺服器日誌的風險。

你還應該確保在所有涉及釋出和驗證令牌的參與者之間，只使用TLS 1.2/1.3和最安全的密碼套件。

寫在最後

令牌訪問是現代應用程式實現的基礎，但是必須小心處理。

作為後端開發人員，你必須確保提供適當的授權型別，來獲取令牌，並徹底驗證JWTs。

作為前端開發人員，也應該謹慎處理JWTs的儲存，並確保應用程式憑據的安全。

Happy coding :)

https://m.toutiaocdn.com/group/6821415566083883524/?app=news_article&timestamp=1588954238&use_new_style=1&req_id=202005090010380101290491012A2BD040&group_id=6821415566083883524 這個是關於設計 API 的總結，裡面有一部分是安全方面的解決方案，希望有點幫助

Token自帶簽名信息，不可能偽造的。不過，有被竊取的風險，可以將有效期設定短點，加上https的保護就萬無一失了。