第三方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

 

掃碼關注有驚喜！