分為三個方面：（參考鏈接https://blog.csdn.net/qq_35524157/article/details/116494536）

一、 確保調用者的合法性

二、確保數據傳輸過程的安全性

三、防篡改

一、 針對--調用者身份安全的校驗方式：

1. 高德地圖方案：（apiKey + apiSecret）

1. 提供簽發服務，給api使用者提供 apiKey / apiSecret
2. url攜帶apiKey, apiSecret 存儲在nginx 上，通過nginx添加額外參數
3. 每次請求接口攜帶 apiKey， apiSecret通過nginx追加參數
4. 后端拿到 apiKey apiSecret,校驗兩者的匹配性

弊端： 以上只能確保訪問 api的是合法用戶，不能保證數據傳輸安全性

2. apiKey + apiSecret 方式二：

1. 服務端生成 apiKey / apiSecret 提供給客戶端
2. 客戶端通過請求服務端時，生成簽名 sign， 攜帶到請求參數中傳遞給服務端
3. 服務端拿到簽名后，通過約定好的算法規則生成簽名，和客戶端發送的簽名對比

簽名生成規則： 優勢：簽名驗證第一可以驗證 apiKey和apiSecret 的匹配性。二可以確保請求參數沒有被篡改

弊端：apiSecret 保存在客戶端代碼里，不安全。

解決方案：使用代碼混淆，使密鑰難以獲取。

二、 針對--數據傳輸安全性：

1. RSA雙向加密: （前端JS庫-jsencrypt.js）

RSA 加密規則：公鑰（publicKey）加密、私鑰（privateKey）解密。不能逆向，私鑰（privateKey） 加密、公鑰（publicKey）解密。說白了就是前后端都需要用公鑰（publicKey）進行加密，用私鑰（privateKey）進行解密。

• 首先定義兩對秘鑰：秘鑰對A、秘鑰對B
• 前端保存 pubKeyA priKeyB, 后端保存 pubKeyB priKeyA
• 前端使用公鑰A（publicA）對數據進行加密，后端通過公鑰A（publicKeyA）對應的私鑰A（privateKeyA）進行解密
• 后端使用公鑰B（publicKeyB）進行加密，前端通過公鑰B（publicKeyB）對應的私鑰A(privateKeyA)進行解密。
• 雖然私鑰（privateKeyB）和公鑰（publicKeyA）都在前端代碼中，但是這兩個并不是一對，就算是全部拿到，也無法成功解密

•  

   

2. AES 對稱加密 + 非對稱加密 （參考https://www.zhiu.cn/148178.html）（前端js庫：crypto-js, javascript-MD5.js）

為防止請求被阻攔后篡改 body，可在發請求時，將 body 字符串進行一個 md5 加密后在懇求頭傳輸，服務器收到懇求后，解密 body 后再 md5 與懇求頭的進行校驗，可驗證是否請求被篡改

三、 防篡改（url 防篡改---微信支付，支付寶支付）

1. 數據簽名，防止請求參數被篡改（參考https://blog.csdn.net/Weixiaohuai/article/details/106420234）

總結：

開放API安全性 方案一： 【ak/as（合法用戶） + https（傳輸加密） + 數據簽名防篡改（防篡改）】

方案二：【ak/as + RSA雙向加密 + 數據簽名】

方案三：【ak/as + AES 對稱加密 / RSA非對稱加密】