淺顯易懂講解如何用JWT來加固API
譯文【51CTO.com快譯】您一定聽說過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ā)送的。如下所示：
- Authorization：Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U
可見，令牌就是“Authorization：Bearer”的后面部分，隸屬于HTTP的頭部信息。
上述信息雖然顯得比較凌亂，不過它包含了如下部分：
首先，令牌由三個(gè)不同的字符串所組成，它們分別以點(diǎn)號(hào)隔開。這三個(gè)字符串使用了base 64編碼，分別對(duì)應(yīng)頭部(header)、有效載荷(payload)和簽名(signature)，如下所示：
- // Header
- eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
- // Payload
- eyJzdWIiOiIxMjM0NTY3ODkwIn0
- // Signature
- dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U
注：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ì)解讀。
- {
- "alg"："HS256"，
- "typ"："JWT"
- }
有效載荷
有效載荷里的內(nèi)容要豐富得多。您可以用它來包含任何自己需要傳遞的數(shù)據(jù)。在此，由于該令牌的目的是對(duì)API的訪問進(jìn)行身份驗(yàn)證，因此僅包含了用戶的ID。
- {
- "userId"："1234567890"
- }
值得注意的是：有效負(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哈希算法的輸出:
- 4ae7c3b6ac0beff671efa8cf57386151c06e58ca53a78d83f36107316cec125f
注：哈希算法有許多種不同的類型，JWT常用的是SHA256。
而哈希的重要屬性在于：我們無法使用哈希算法，通過哈希值來識(shí)別出原始的字符串。換句話說，我們無法憑借上述哈希值，直接計(jì)算或得出原始的字符串“Hello, world.”。從理論上說，根據(jù)哈希的復(fù)雜性，猜測(cè)出原始字符串是完全不可行的。
JWT簽名
現(xiàn)在，讓我們來看JWT令牌結(jié)構(gòu)的第三個(gè)部分：簽名。實(shí)際上，該部分是需要進(jìn)行計(jì)算的。
- HMACSHA256(
- base64UrlEncode(header) + "." + base64UrlEncode(payload)，
- "secret string"
- );
我們下面來具體分析一下上述代碼:
- 首先，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ù)庫(kù)中。
- logincontrol.js:
- if (passwordCorrect) {
- user.token = generateToken(user.id);
- user.save();
- }
然后作為對(duì)于登錄請(qǐng)求的響應(yīng)，該令牌被添加到authorization的頭部。
logincontrol.js：
- if (passwordCorrect) {
- user.token = generateToken(user.id);
- user.save();
- res.headers("authorization"，`Bearer ${token}`).send();
- }
驗(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ù)庫(kù)中查找該用戶的信息。
- 將請(qǐng)求令牌與帶有用戶模型的存儲(chǔ)令牌進(jìn)行比較。如果匹配，則認(rèn)定該用戶的“合法”身份。
authMiddleware.js：
- const token = req.header.token;
- const payload = decodeToken(token);
- const user = User.findById(payload.id);
- if (user.token = token) {
- // Authorized
- } else {
- // Unauthorized
- }
注銷
如果該用戶要求注銷，那么系統(tǒng)只需刪除掉當(dāng)前已添加到用戶模型的令牌便可。由于用戶手上的令牌及時(shí)失效了，因此如果他需要再次登錄的話，應(yīng)重新產(chǎn)生新的令牌。
logoutcontrol.js：
- user.token = null;
- user.save();
總結(jié)
通過上面的逐步分析，希望您能夠?qū)τ谌绾问褂肑SON Web Token來加固API，已經(jīng)建立起了基本的概念。當(dāng)然，該話題涵括的內(nèi)容遠(yuǎn)不止這些，如果您有興趣的話，可以通過如下鏈接進(jìn)行擴(kuò)展閱讀：
- Jwt.io - https://jwt.io/
- 什么是JSON Web Token?- https://robmclarty.com/blog/what-is-a-json-web-token
【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】
