【答疑解惑】|?作者?/ Edison Zhou

這是恰童鞋騷年的第269篇原創(chuàng)內(nèi)容

---

前面一篇我們了解了微服務(wù)安全認(rèn)證架構(gòu)是如何演進(jìn)而來(lái)的，但是發(fā)現(xiàn)v2.5架構(gòu)仍然較重，有沒(méi)有輕量級(jí)一點(diǎn)的方法呢？其實(shí)業(yè)界早已有了實(shí)踐，它就是基于JWT的安全認(rèn)證架構(gòu)。JWT到底是個(gè)什么鬼呢？本篇為你解答！

1v2.5版本存在的問(wèn)題

在v2.5版本Token+Gateway模式下，適合于大部分微服務(wù)場(chǎng)景，但是當(dāng)網(wǎng)站流量很大的時(shí)候，對(duì)AuthService的訪問(wèn)壓力也會(huì)比較大，它很可能會(huì)成為性能和擴(kuò)展性的瓶頸！

MyShop v2.5版本：Token+Gateway

此外，對(duì)于很多對(duì)于安全不是很敏感的微服務(wù)來(lái)說(shuō)，集中狀態(tài)校驗(yàn)就會(huì)顯得很笨重。

2v2.6版本：JWT+Gateway

在業(yè)界實(shí)踐上，很多企業(yè)都在采用基于JWT令牌的無(wú)狀態(tài)安全認(rèn)證架構(gòu)，MyShop技術(shù)團(tuán)隊(duì)也探索出了v2.6版本，即基于JWT+Gateway的模式：

MyShop v2.6：JWT+Gateway

v2.6在v2.5的基礎(chǔ)之上發(fā)展而來(lái)，主要區(qū)別如下：

（1）第二步中，v2.5使用的是透明應(yīng)用令牌，而v2.6使用的是JWT令牌，JWT令牌是自包含數(shù)據(jù)和簽名的；

（2）第四步和第五步，v2.5需要網(wǎng)關(guān)每次請(qǐng)求都去AuthService進(jìn)行校驗(yàn)，而v2.6網(wǎng)關(guān)處則不用；此處，網(wǎng)關(guān)就可以自行進(jìn)行令牌的解析和合法性校驗(yàn)；解析完成后，網(wǎng)關(guān)就可以得到用戶標(biāo)識(shí)信息并向后端微服務(wù)傳遞了；

畫(huà)外音：這里的JWT令牌有點(diǎn)類(lèi)似于單塊架構(gòu)階段v1.x版本下的無(wú)狀態(tài)Session，并且針對(duì)于微服務(wù)場(chǎng)景進(jìn)行了擴(kuò)展應(yīng)用。

JWT+Gateway的這種做法簡(jiǎn)化了安全認(rèn)證架構(gòu)，降低了AuthService的壓力，總體上來(lái)說(shuō)是一種高性能和可擴(kuò)展的架構(gòu)，適用于大部分對(duì)安全要求不太敏感的微服務(wù)應(yīng)用場(chǎng)景。為什么說(shuō)是大部分對(duì)安全要求不敏感的場(chǎng)景呢，這就需要我們了解一下JWT的原理了。

3JWT的原理

JWT全程JSON Web Token，是一種用于通信雙方之間傳遞安全信息的簡(jiǎn)潔的、URL安全的表述性聲明規(guī)范，經(jīng)常用在跨域身份驗(yàn)證。

JWT最主要的特點(diǎn)就是它定義了一種緊湊和自包含的JSON對(duì)象格式，通過(guò)它可以在多個(gè)系統(tǒng)或服務(wù)之間安全的傳遞信息，信息經(jīng)過(guò)數(shù)字簽名可以校驗(yàn)且是可信任的。

JWT主要用于?認(rèn)證授權(quán) 和 信息交換 的場(chǎng)景，其令牌結(jié)構(gòu)主要有如下圖所示的3個(gè)部分組成，且不同部分之間用了一個(gè) . 分隔：

JWT的三個(gè)組成部分

這三個(gè)組成部分分別是：Header頭部、Payload消息體 以及?Signature簽名。

畫(huà)外音：JWT將消息體分為了Header和Payload，其實(shí)有點(diǎn)類(lèi)似于HTTP協(xié)議，它也將請(qǐng)求體分為了Header和Body，Header里面一般放元數(shù)據(jù)，類(lèi)似于信封上的寄件人和地址等，而B(niǎo)ody里面則存放的是實(shí)際數(shù)據(jù)，類(lèi)似于信封里面的主體內(nèi)容。

下面我們來(lái)看一個(gè)JWT令牌的示例：

JWT令牌示例

我們先關(guān)注上圖中的左半部分，可以看到，三個(gè)部分分別使用了不同的顏色標(biāo)注了出來(lái)，并且通過(guò) .?分隔開(kāi)。

畫(huà)外音：如果你沒(méi)看到，那就仔細(xì)看一下！如果還沒(méi)看到，那就打開(kāi)放大看一下！

一般來(lái)說(shuō)，我們都會(huì)通過(guò)一些工具例如jwt.io網(wǎng)站來(lái)查看JWT解碼后的內(nèi)容，也就是上圖中的右半部分就是在jwt.io上進(jìn)行解碼后的內(nèi)容。

可以看到，Header部分解碼后的內(nèi)容說(shuō)明了這個(gè)令牌的類(lèi)型是JWT，即JSON Web Token，它使用的算法是HS256算法。

然后，Payload部分解碼后的內(nèi)容說(shuō)明了這個(gè)令牌的頒發(fā)者是誰(shuí)（iss），頒發(fā)的時(shí)間（iat），令牌過(guò)期時(shí)間（exp）、這個(gè)令牌要頒發(fā)給誰(shuí)（aud）以及目標(biāo)用戶是誰(shuí)（sub）。這些信息也稱(chēng)為Claims，他們是官方定義的Public Claims。我們?cè)趯?shí)際使用中，也會(huì)定義一些Custom Claims，比如用戶的角色信息（Role）等。

針對(duì)ASP.NET Core開(kāi)發(fā)童鞋，推薦閱讀曉晨的這篇文章實(shí)踐IdentityServer：《IdentityServer4實(shí)戰(zhàn)-基于角色的權(quán)限控制及Claim詳解》，傳送門(mén)：https://www.cnblogs.com/stulzq/p/8726002.html

最后，Signature部分則表明了整個(gè)JWT的驗(yàn)證方式是什么樣子的，即一個(gè)簽名公式。如果是采用HS256算法的話，就是下面這個(gè)公式：

base64Url(Header)+"."+base64Url(Payload)+"."+base64Url(Signature)

在jwt.io上，我們可以通過(guò)輸入secret進(jìn)行一個(gè)令牌的合法性的校驗(yàn)，如果不通過(guò)則會(huì)顯示Invalid?Signature，通過(guò)則顯示Signature Verified.

JWT令牌校驗(yàn)

看完了JWT的三個(gè)組成部分，及其組裝公式，我們可能會(huì)發(fā)現(xiàn)：

Header和Payload的內(nèi)容是公開(kāi)可見(jiàn)的，只要拿到Token就可以去類(lèi)似jwt.io這種工具網(wǎng)站上進(jìn)行Debug解析，那JWT真的安全嗎？

畫(huà)外音：JWT保證的安全可能是相對(duì)的，它不會(huì)保證傳輸信息的保密性，但它會(huì)保證信息的可依賴(lài)和不可篡改性（通過(guò)Signature實(shí)現(xiàn)）。因?yàn)镾ecret是保密的，所以即使一般用戶拿到了你的token和算法，也無(wú)法篡改里面的數(shù)據(jù)（一旦篡改校驗(yàn)就會(huì)不通過(guò)）。換句話說(shuō)，JWT令牌有點(diǎn)類(lèi)似于現(xiàn)實(shí)世界中的簽名支票，如下圖所示。

簽名支票

4JWT的實(shí)現(xiàn)方式

上面我們了解了JWT的原理，現(xiàn)在來(lái)看看JWT都是如何來(lái)實(shí)現(xiàn)的。目前，JWT主要有兩種算法實(shí)現(xiàn)，一種是HMAC，另一種是RSA。

HMAC流程

首先，來(lái)看看HMAC的實(shí)現(xiàn)流程：

HAMC流程

Step1.客戶端向AuthServer發(fā)出登錄請(qǐng)求；

Step2.AuthServer校驗(yàn)用戶身份，通過(guò)后生成JWT數(shù)據(jù)結(jié)構(gòu)且采用某種HMAC算法+Secret對(duì)JWT進(jìn)行簽名，最后將這個(gè)簽名后的JWT令牌返回給客戶端；

Step3.客戶端收到JWT后一般都會(huì)做本地存儲(chǔ)，然后在調(diào)用微服務(wù)的時(shí)候都會(huì)帶上JWT令牌；

Step4.微服務(wù)接收到客戶端請(qǐng)求和JWT令牌時(shí)，會(huì)采用同樣的Secret對(duì)JWT令牌進(jìn)行解析和校驗(yàn)，通過(guò)后則返回處理后的數(shù)據(jù)，不通過(guò)則一般返回401。

由此看來(lái)，HMAC流程中，最重要的就是secret的保密，如果泄露，則整個(gè)流程不再安全。

RSA流程

然后，來(lái)看看RSA的實(shí)現(xiàn)流程：

RSA流程

RSA流程總體上來(lái)說(shuō)和HMAC類(lèi)似，不同的是AuthServer在頒發(fā)JWT令牌的時(shí)候采用私鑰Private Key進(jìn)行簽名，而微服務(wù)端ResourceServer在解析和校驗(yàn)JWT令牌的時(shí)候采用公鑰Public Key進(jìn)行簽名。

可以看出，RSA流程比HMAC流程總體來(lái)說(shuō)要安全一點(diǎn)，因?yàn)橹挥蠥uthServer一個(gè)地方需要保存私鑰，私鑰的泄露概率就小很多。其他的微服務(wù)端都使用公鑰進(jìn)行解簽校驗(yàn)，但是不能夠篡改加簽。

畫(huà)外音：其實(shí)就類(lèi)似于對(duì)稱(chēng)加密 和 非對(duì)稱(chēng)加密的方式。

5JWT學(xué)習(xí)小結(jié)

本文通過(guò)MyShop v2.5存在的問(wèn)題引出了使用JWT令牌的v2.6架構(gòu)，并介紹了JWT的概念、原理 和?實(shí)現(xiàn)方式。最后，我們來(lái)總結(jié)一下JWT的優(yōu)勢(shì)及不足：

重點(diǎn)關(guān)注一下JWT的不足：

（1）無(wú)狀態(tài)和吊銷(xiāo)無(wú)法兩全，如果某個(gè)用戶令牌異常（比如有黑客在干壞事），我們想要吊銷(xiāo)這個(gè)用戶的令牌，但是卻沒(méi)有辦法在AuthService上進(jìn)行統(tǒng)一吊銷(xiāo)，一般需要等到這個(gè)JWT令牌自然過(guò)期才能吊銷(xiāo)。又假設(shè)我們?cè)贏uthService上對(duì)某個(gè)用戶的信息進(jìn)行了更新，那么相關(guān)的Claims信息也必須要等到這個(gè)老的JWT過(guò)期后重新登錄或刷新后產(chǎn)生了新的JWT后才能更新。

（2）JWT的大小會(huì)隨著Claims的數(shù)量增多，也會(huì)導(dǎo)致JWT的大小會(huì)變大，從而也會(huì)導(dǎo)致傳輸?shù)拈_(kāi)銷(xiāo)增大。

最后，我們可以對(duì)有狀態(tài)的透明令牌和無(wú)狀態(tài)的JWT令牌做一個(gè)小結(jié)：

兩者各有適用場(chǎng)景，JWT令牌更適合于安全不敏感場(chǎng)景，透明令牌更適合于安全敏感場(chǎng)景。這里的敏感主要是指和錢(qián)、交易、支付相關(guān)的場(chǎng)景，以及金融、銀行等業(yè)務(wù)之類(lèi)的場(chǎng)景，這些場(chǎng)景可以采用集中式的有狀態(tài)的透明令牌認(rèn)證，其他的一般性的微服務(wù)應(yīng)用場(chǎng)景則可以使用JWT。

畫(huà)外音：對(duì)中小技術(shù)團(tuán)隊(duì)來(lái)說(shuō)，特別是技術(shù)儲(chǔ)備和實(shí)力都沒(méi)那么強(qiáng)的團(tuán)隊(duì)，和錢(qián)相關(guān)的業(yè)務(wù)場(chǎng)景，寧慢三秒，不搶一秒，因?yàn)橛袝r(shí)候想快那么一秒，可能就翻車(chē)了。

往期騷年快答

技術(shù)中臺(tái)與業(yè)務(wù)中臺(tái)有啥聯(lián)系？

微服務(wù)架構(gòu)中的BFF到底是個(gè)啥？

為何微服務(wù)項(xiàng)目都愛(ài)用單體倉(cāng)庫(kù)？

微服務(wù)安全認(rèn)證架構(gòu)如何演進(jìn)而來(lái)的？

專(zhuān)注于開(kāi)發(fā)技術(shù)與個(gè)人成長(zhǎng)分享，

做對(duì)你有用的公眾號(hào)！

????點(diǎn)個(gè)贊和在看如何？

總結(jié)

以上是生活随笔為你收集整理的JWT是个什么鬼？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。