一、前言
在與第三方系統做介面對接時，往往需要考慮介面的安全性問題，本文主要分享幾個常見的系統之間做介面對接時的認證方案。
二、認證方案
例如訂單下單後通過 延時任務 對接 物流系統 這種 非同步 的場景，都是屬於系統與系統之間的相互互動，不存在使用者操作；所以認證時需要的不是使用者憑證而是系統憑證，通常包括 app_id 與 app_secrect。
app_id與app_secrect由介面提供方提供
2.1. Baic認證
這是一種較為簡單的認證方式，客戶端通過明文（Base64編碼格式）傳輸使用者名稱和密碼到服務端進行認證。
通過在 Header 中新增key為 Authorization，值為 Basic 使用者名稱:密碼的base64編碼，例如app_id為和app_secrect都為 zlt，然後對 zlt:zlt 字元進行base64編碼，最終傳值為：
Authorization: Basic emx0OnpsdA==
2.1.1. 優點
簡單，被廣泛支援。
2.1.2. 缺點
安全性較低，需要配合HTTPS來保證資訊傳輸的安全
- 雖然使用者名稱和密碼使用了Base64編碼，但是很容易就可以解碼。
- 無法防止 重放攻擊 與 中間人攻擊。
2.2. Token認證
使用 Oauth2.0 中的 客戶端模式 進行Token認證，流程如下圖所示：
使用Basic認證的方式獲取access_token之後，再通過token來請求業務介面
2.2.1. 優點
安全性相對 Baic認證 有所提升，每次介面呼叫時都使用臨時頒發的 access_token 來代替 使用者名稱和密碼 減少憑證洩漏的機率。
2.2.2. 缺點
依然存在 Baic認證 的安全問題。
2.3. 動態簽名
在每次介面呼叫時都需要傳輸以下引數：
- app_id 應用id
- time 當前時間戳
- nonce 隨機數
- sign 簽名
其中sign簽名的生成方式為：使用引數中的
app_id + time + nonce 並在最後追加 app_secrect 的字串進行md5加密，並全部轉換成大寫。
如果需要實現引數的防篡改，只需把介面所有的請求引數都作為簽名的生成引數即可
2.3.1. 優點
安全性最高
- 服務端使用相同的方式生成簽名進行對比認證，無需在網路上傳輸
app_secrect。 - 可以防止 中間人攻擊。
- 通過
time引數判斷請求的時間差是否在合理範圍內，可防止 重放攻擊。 - 通過
nonce引數進行冪等性判斷。
2.3.2. 缺點
不適用於前端應用使用，js原始碼會暴露簽名的方式與app_secrect
掃碼關注有驚喜！
