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