前后端分離式開發(fā)需要進行數(shù)據(jù)交互，傳輸?shù)臄?shù)據(jù)被偷窺、被抓包、被偽造時有發(fā)生，那么如何設計一套比較安全的API接口方案呢？

　　并不是所有的接口都需要考慮安全的，有些接口是公開的，任何人只要知道地址都可以調用，對于一些項目中需要用戶登錄才能訪問的接口才需要考慮安全問題。

　　一般解決的方案有以下幾類：

　　token令牌認證(jwt)

　　AK(app key)&SK(secret key)【用戶名&密碼】

　　時間戳超時驗證+簽名算法字符串

　　URL簽名(算法，非對稱算法)

　　數(shù)據(jù)脫敏(防范數(shù)據(jù)庫數(shù)據(jù)泄露)

　　HTTPS

　　IP黑/白名單(服務器層面的限制，apache、nginx)

　　oAuth2.0

　　關于JWT：

　　Json web token(JWT)，是基于token的鑒權機制，類似于http協(xié)議也是無狀態(tài)的，它不需要在服務端去保留用戶的認證信息或者會話信息，為應用的擴展提供了便利。JWT具備以下幾個優(yōu)點：

　　因json的通用性，所以JWT是可以進行跨語言

　　JWT可以在自身存儲一些其他業(yè)務邏輯所必要的非敏感信息

　　便于傳輸，jwt的構成非常簡單，字節(jié)占用很小，所以它是非常便于傳輸?shù)?/p>

　　它不需要在服務端保存會話信息，所以它非常適合應用在前后端分離的項目上

　　使用JWT進行鑒權的工作流程如下(重點)：

　　用戶使用用戶名密碼來請求服務器

　　服務器進行驗證用戶的信息(查數(shù)據(jù)庫)

　　服務器通過驗證發(fā)送給用戶一個token(令牌)

　　客戶端存儲token(Vuex+localStorage)，并在每次請求時附送上這個token值

　　服務端驗證token值，并返回數(shù)據(jù)

　　JWT是由三段信息構成的(頭部、載荷、簽名)，將這三部分使用.連接在一起就組成了JWT字符串，形如：

　　其中：

　　· 頭部(header)，包含了兩(可以更多)部分信息，分別是類型的聲明和所使用的加密算法。

　　一個完整的頭部就像下面的JSON：

{

  'typ': 'JWT',

  'alg': 'HS256'

}

　　然后將頭部進行base64加密/編碼(該加密是可以對稱解密的)，這就得到了jwt的第一部分。

　　· 載荷(payload)(body)，載荷就是存放有效信息的地方。這些有效信息包含三個部分

　　o 標準中約定聲明(建議但不強制)

　　§ 簽發(fā)人

　　§ 使用者

　　§ 簽發(fā)時間

　　§ 有效期

　　§ ....

　　o 公共的聲明

　　o 私有的聲明

　　定義一個payload：

{

  "sub": "1234567890",

  "name": "John Doe",

  "admin": true

}

　　依舊進行base64加密，這就得到了jwt的第二部分。

　　· 簽名(signature)，這個簽證信息由三部分組成：

o 經(jīng)過base64編碼后的

§ header

§ payload

o secret

　　例如：

var encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload);

var signature = HMACSHA256(encodedString, 'secret');

　　這樣就得到了jwt的第三部分。

var jwt = encodedString + '.' + base64UrlEncode(signature);

　　最終將三部分信息通過.進行連接就得到了最終的jwt字符串。后續(xù)不需要自己去寫jwt怎么生成的。因此，此流程理解即可。

　　需要注意的是

　　· secret是保存在服務器端的

　　· jwt的簽發(fā)生成也是在服務器端的

　　· secret是用來進行jwt的簽發(fā)和jwt的驗證

　　所以，secret它就是服務端的私鑰，在任何場景都不應該泄露出去。一旦其他人(包括客戶端的用戶)得知這個secret，那就意味著他們可以自我簽發(fā)jwt，接口就沒有安全性可言了。

　　更多關于“前端培訓”的問題，歡迎咨詢千鋒教育在線名師。千鋒教育多年辦學，課程大綱緊跟企業(yè)需求，更科學更嚴謹，每年培養(yǎng)泛IT人才近2萬人。不論你是零基礎還是想提升，都可以找到適合的班型，千鋒教育隨時歡迎你來試聽。