日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
淺顯易懂講解如何用JWT來加固API

您一定聽說過JSON Web Token(JWT)吧? 它是當(dāng)前用來保護(hù)API的先進(jìn)技術(shù)之一。與大多數(shù)安全概念與技術(shù)一樣，我們在準(zhǔn)備使用它之前，了解其工作原理是非常必要且重要的。當(dāng)然，過于專業(yè)和技術(shù)性的JWT解釋可能會讓您覺得費解，甚至感到頭痛。那么讓我試著用一種比較淺顯易懂的方式，向您闡述JWT是如何加固API的吧。 

API身份驗證

不言而喻，在復(fù)雜的網(wǎng)絡(luò)環(huán)境中，我們需要對各種API資源實施訪問限制。例如，我們不希望某個用戶能夠更改另一個用戶的密碼。那么，我們就需要該用戶以提交其ID和密碼的方式，來保護(hù)和加固目標(biāo)資源。換句話說：我們需要對他們進(jìn)行身份驗證。

而在實際應(yīng)用中，我們保護(hù)HTTP類API的難點在于：各種請求是無狀態(tài)的。也就是說：API無法知道任意兩個請求是否來自同一個用戶。有人可能會追問：我們?yōu)槭裁床荒芤笥脩粼诿看握{(diào)用API時，都提供他們的ID和密碼呢?答案是：因為這樣會給用戶帶來極差的訪問體驗。

JSON Web Token

因此，我們需要的是：用戶只用一次性提供信任憑據(jù)，而在后續(xù)的請求中，服務(wù)器會以另一種方式進(jìn)行用戶身份的識別。基于這種思想，JSON Web Token應(yīng)運而生。

當(dāng)然，如果您是一位愛好鉆研的學(xué)霸，那么您可以通過鏈接：https://robmclarty.com/blog/what-is-a-json-web-token，來對JSON Web Token的工作原理進(jìn)行全面深入的參悟。

在此讓我們想象一下：如果您打算入住一家酒店，那么“令牌”就是允許您進(jìn)入自己房間、以及酒店內(nèi)其他設(shè)施的安全門卡，顯然您不能進(jìn)入其他人的房間。而且在退房的時候，您需要退還門卡，即：注銷。

令牌的結(jié)構(gòu)

通常情況下， JSON Web Token是通過各種HTTP請求的頭部(header)被發(fā)送的。如下所示：

 
 
 
    
  
  
  
  1. Authorization：Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U 
    2.

可見，令牌就是“Authorization：Bearer”的后面部分，隸屬于HTTP的頭部信息。

上述信息雖然顯得比較凌亂，不過它包含了如下部分：

首先，令牌由三個不同的字符串所組成，它們分別以點號隔開。這三個字符串使用了base 64編碼，分別對應(yīng)頭部(header)、有效載荷(payload)和簽名(signature)，如下所示：

 
 
 
    
  
  
  
  1. // Header  
    2. 
  
  
  
  2. eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 
    3. 
  
  
  
  3. // Payload 
    4. 
  
  
  
  4. eyJzdWIiOiIxMjM0NTY3ODkwIn0 
    5. 
  
  
  
  5. // Signature 
    6. 
  
  
  
  6. dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U 
    7.

注：base 64是一種轉(zhuǎn)換字符串的方法，能夠確保字符串在跨Web傳輸?shù)倪^程中不會出現(xiàn)問題。由于它不是一種加密方法，因此任何人都可以很容易地對它進(jìn)行解碼，以查看原始數(shù)據(jù)。

下面，我們對上述字符串進(jìn)行解碼，以便更好地了解JWT的結(jié)構(gòu)。

頭部

通過解碼令牌的頭部，我們可以得到如下的元信息(meta information)。由于它對于我們理解整體的工作原理幫助不大，所以我們在此并不做詳細(xì)解讀。

 
 
 
    
  
  
  
  1. { 
    2. 
  
  
  
  2.   "alg"："HS256"， 
    3. 
  
  
  
  3.   "typ"："JWT" 
    4. 
  
  
  
  4. } 
    5.

有效載荷

有效載荷里的內(nèi)容要豐富得多。您可以用它來包含任何自己需要傳遞的數(shù)據(jù)。在此，由于該令牌的目的是對API的訪問進(jìn)行身份驗證，因此僅包含了用戶的ID。

 
 
 
    
  
  
  
  1. { 
    2. 
  
  
  
  2.   "userId"："1234567890" 
    3. 
  
  
  
  3. } 
    4.

值得注意的是：有效負(fù)載并不安全。任何人都可以通過解碼令牌，來查看有效負(fù)載中的確切內(nèi)容。因此，我們通常只包含ID，而不會包含諸如用戶郵件內(nèi)容等敏感的標(biāo)識信息。

盡管該有效負(fù)載為API提供了識別用戶所需的全部信息，但是它并不提供具體的身份驗證方法。畢竟憑借這些信息，黑客足以能夠輕松地找到用戶的ID，并可偽造出令牌。因此，我們還需要有簽名，而它才是令牌認(rèn)證環(huán)節(jié)中的關(guān)鍵部分。

哈希算法

在開始解釋簽名的工作原理之前，我們需要先來了解一下什么是哈希算法。

首先，它是一個函數(shù)，可用來將目標(biāo)字符串轉(zhuǎn)換為另一種被稱為哈希值(hash)的新字符串。例如，我們對字符串“Hello, world.”進(jìn)行哈希操作，那么就能夠得到如下經(jīng)過了SHA256哈希算法的輸出:

 
 
 
    
  
  
  
  1. 4ae7c3b6ac0beff671efa8cf57386151c06e58ca53a78d83f36107316cec125f 
    2.

注：哈希算法有許多種不同的類型，JWT常用的是SHA256。

而哈希的重要屬性在于：我們無法使用哈希算法，通過哈希值來識別出原始的字符串。換句話說，我們無法憑借上述哈希值，直接計算或得出原始的字符串“Hello, world.”。從理論上說，根據(jù)哈希的復(fù)雜性，猜測出原始字符串是完全不可行的。

JWT簽名

現(xiàn)在，讓我們來看JWT令牌結(jié)構(gòu)的第三個部分：簽名。實際上，該部分是需要進(jìn)行計算的。

 
 
 
    
  
  
  
  1. HMACSHA256( 
    2. 
  
  
  
  2.   base64UrlEncode(header) + "." + base64UrlEncode(payload)， 
    3. 
  
  
  
  3.   "secret string" 
    4. 
  
  
  
  4. ); 
    5.

我們下面來具體分析一下上述代碼:

  • 首先，HMACSHA256是哈希函數(shù)的名稱，它用到了兩個參數(shù)：需要進(jìn)行哈希的字符串和密鑰(secret)。
  • 其次，這個需要進(jìn)行哈希的字符串，是經(jīng)過base 64編碼過的頭部和有效載荷。
  • 第三，密鑰是一串任意數(shù)據(jù)，而且只有服務(wù)器知曉。

問：為什么要將頭部和有效載荷添加到簽名的哈希值中呢?

答：這樣可以確保簽名對于該特定令牌來說是僅有的。

問：什么是密鑰?

答：讓我們從如何偽造一個令牌的角度來回答該問題。我們之前說過，黑客無法從輸出值來推導(dǎo)出經(jīng)過哈希的輸入信息。但是，由于簽名中包括了頭部和有效載荷，而這些都是公共的信息，因此如果黑客知道了哈希算法(這通常是在頭部被指定的)，那么就能夠生成相同的哈希值。

可見，如果服務(wù)器掌握了某個非公開的密鑰，并且將其包含在哈希處理的過程中，那么就能夠防止黑客自行偽造并生成帶有哈希值的令牌。同時，由于哈希值“掩蓋”了各種原始信息，因此也就保證了密鑰不會被黑客所發(fā)現(xiàn)。

注：將私有數(shù)據(jù)添加到哈希之中的過程，被稱為加鹽(salting)，這使得破解令牌幾乎是不可能的。

身份驗證過程

至此，想必您已經(jīng)理解了令牌的創(chuàng)建過程。那么，我們又該如何用它來驗證用戶的API呢?

登錄

在用戶登錄時，系統(tǒng)會生成一個令牌，并將其與用戶模型(model)一起存儲在數(shù)據(jù)庫中。

 
 
 
    
  
  
  
  1. logincontrol.js: 
    2. 
  
  
  
  2. if (passwordCorrect) { 
    3. 
  
  
  
  3.   user.token = generateToken(user.id); 
    4. 
  
  
  
  4.   user.save(); 
    5. 
  
  
  
  5. } 
    6.

然后作為對于登錄請求的響應(yīng)，該令牌被添加到authorization的頭部。

logincontrol.js：

 
 
 
    
  
  
  
  1. if (passwordCorrect) { 
    2. 
  
  
  
  2.   user.token = generateToken(user.id); 
    3. 
  
  
  
  3.   user.save(); 
    4. 
  
  
  
  4.   res.headers("authorization"，`Bearer ${token}`).send(); 
    5. 
  
  
  
  5. } 
    6.

驗證請求

有了令牌，用戶現(xiàn)在就可以將其添加到各種后續(xù)的請求中，以驗明正身了。

而當(dāng)服務(wù)器收到添加了身份信息的令牌請求后，會進(jìn)行如下操作:

  • 對令牌進(jìn)行解碼，并從有效載荷中提取ID。
  • 使用此ID，在數(shù)據(jù)庫中查找該用戶的信息。
  • 將請求令牌與帶有用戶模型的存儲令牌進(jìn)行比較。如果匹配，則認(rèn)定該用戶的“合法”身份。

authMiddleware.js：

 
 
 
    
  
  
  
  1. const token = req.header.token; 
    2. 
  
  
  
  2. const payload = decodeToken(token); 
    3. 
  
  
  
  3. const user = User.findById(payload.id); 
    4. 
  
  
  
  4. if (user.token = token) { 
    5. 
  
  
  
  5.   // Authorized 
    6. 
  
  
  
  6. } else { 
    7. 
  
  
  
  7.   // Unauthorized 
    8. 
  
  
  
  8. } 
    9.

注銷

如果該用戶要求注銷，那么系統(tǒng)只需刪除掉當(dāng)前已添加到用戶模型的令牌便可。由于用戶手上的令牌及時失效了，因此如果他需要再次登錄的話，應(yīng)重新產(chǎn)生新的令牌。

logoutcontrol.js：

 
 
 
    
  
  
  
  1. user.token = null; 
    2. 
  
  
  
  2. user.save(); 
    3.

網(wǎng)頁題目：淺顯易懂講解如何用JWT來加固API
網(wǎng)頁鏈接：http://m.5511xx.com/article/ccecdio.html