第三方API對接如何設計介面認證？

一、前言

在與第三方系統做介面對接時，往往需要考慮介面的安全性問題，本文主要分享幾個常見的系統之間做介面對接時的認證方案。

 

二、認證方案

例如訂單下單後通過 延時任務 對接 物流系統 這種 非同步 的場景，都是屬於系統與系統之間的相互互動，不存在使用者操作；所以認證時需要的不是使用者憑證而是系統憑證，通常包括 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來保證資訊傳輸的安全

1. 雖然使用者名稱和密碼使用了Base64編碼，但是很容易就可以解碼。
2. 無法防止 重放攻擊 與 中間人攻擊。

 

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. 優點

安全性最高

1. 服務端使用相同的方式生成簽名進行對比認證，無需在網路上傳輸 app_secrect。
2. 可以防止 中間人攻擊。
3. 通過 time 引數判斷請求的時間差是否在合理範圍內，可防止 重放攻擊。
4. 通過 nonce 引數進行冪等性判斷。

2.3.2. 缺點

不適用於前端應用使用，js原始碼會暴露簽名的方式與app_secrect

 

掃碼關注有驚喜！