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

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間：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ù)一樣，我們?cè)跍?zhǔn)備使用它之前，了解其工作原理是非常必要且重要的。當(dāng)然，過于專業(yè)和技術(shù)性的JWT解釋可能會(huì)讓您覺得費(fèi)解，甚至感到頭痛。那么讓我試著用一種比較淺顯易懂的方式，向您闡述JWT是如何加固API的吧。 

API身份驗(yàn)證

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

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

JSON Web Token

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

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

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

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

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

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

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

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

首先，令牌由三個(gè)不同的字符串所組成，它們分別以點(diǎn)號(hào)隔開。這三個(gè)字符串使用了base 64編碼，分別對(duì)應(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ù)倪^程中不會(huì)出現(xiàn)問題。由于它不是一種加密方法，因此任何人都可以很容易地對(duì)它進(jìn)行解碼，以查看原始數(shù)據(jù)。

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

頭部

通過解碼令牌的頭部，我們可以得到如下的元信息(meta information)。由于它對(duì)于我們理解整體的工作原理幫助不大，所以我們?cè)诖瞬⒉蛔鲈敿?xì)解讀。

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

有效載荷

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

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

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

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

哈希算法

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

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

 
 
 
    
  
  
  
  1. 4ae7c3b6ac0beff671efa8cf57386151c06e58ca53a78d83f36107316cec125f 
    2.

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

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

JWT簽名

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

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

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

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

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

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

問：什么是密鑰?

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

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

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

身份驗(yàn)證過程

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

登錄

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

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

然后作為對(duì)于登錄請(qǐng)求的響應(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.

驗(yàn)證請(qǐng)求

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

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

  • 對(duì)令牌進(jìn)行解碼，并從有效載荷中提取ID。
  • 使用此ID，在數(shù)據(jù)庫中查找該用戶的信息。
  • 將請(qǐng)求令牌與帶有用戶模型的存儲(chǔ)令牌進(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)前已添加到用戶模型的令牌便可。由于用戶手上的令牌及時(shí)失效了，因此如果他需要再次登錄的話，應(yīng)重新產(chǎn)生新的令牌。

logoutcontrol.js：

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

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