一、前言
在與第三方系統做介面對接時，往往需要考慮介面的安全性問題，本文主要分享幾個常見的系統之間做介面對接時的認證方案，
二、認證方案
例如訂單下單后通過 延時任務 對接 物流系統 這種 異步 的場景，都是屬于系統與系統之間的相互互動，不存在用戶操作；所以認證時需要的不是用戶憑證而是系統憑證，通常包括 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
掃碼關注有驚喜！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/288825.html
標籤：Java
上一篇：整理一波Go工程化目錄結構~