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

這是恰童鞋騷年的第269篇原創內容

---

前面一篇我們了解了微服務安全認證架構是如何演進而來的，但是發現v2.5架構仍然較重，有沒有輕量級一點的方法呢？其實業界早已有了實踐，它就是基于JWT的安全認證架構。JWT到底是個什么鬼呢？本篇為你解答！

1v2.5版本存在的問題

在v2.5版本Token+Gateway模式下，適合于大部分微服務場景，但是當網站流量很大的時候，對AuthService的訪問壓力也會比較大，它很可能會成為性能和擴展性的瓶頸！

MyShop v2.5版本：Token+Gateway

此外，對于很多對于安全不是很敏感的微服務來說，集中狀態校驗就會顯得很笨重。

2v2.6版本：JWT+Gateway

在業界實踐上，很多企業都在采用基于JWT令牌的無狀態安全認證架構，MyShop技術團隊也探索出了v2.6版本，即基于JWT+Gateway的模式：

MyShop v2.6：JWT+Gateway

v2.6在v2.5的基礎之上發展而來，主要區別如下：

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

（2）第四步和第五步，v2.5需要網關每次請求都去AuthService進行校驗，而v2.6網關處則不用；此處，網關就可以自行進行令牌的解析和合法性校驗；解析完成后，網關就可以得到用戶標識信息并向后端微服務傳遞了；

畫外音：這里的JWT令牌有點類似于單塊架構階段v1.x版本下的無狀態Session，并且針對于微服務場景進行了擴展應用。

JWT+Gateway的這種做法簡化了安全認證架構，降低了AuthService的壓力，總體上來說是一種高性能和可擴展的架構，適用于大部分對安全要求不太敏感的微服務應用場景。為什么說是大部分對安全要求不敏感的場景呢，這就需要我們了解一下JWT的原理了。

3JWT的原理

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

JWT最主要的特點就是它定義了一種緊湊和自包含的JSON對象格式，通過它可以在多個系統或服務之間安全的傳遞信息，信息經過數字簽名可以校驗且是可信任的。

JWT主要用于?認證授權 和 信息交換 的場景，其令牌結構主要有如下圖所示的3個部分組成，且不同部分之間用了一個 . 分隔：

JWT的三個組成部分

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

畫外音：JWT將消息體分為了Header和Payload，其實有點類似于HTTP協議，它也將請求體分為了Header和Body，Header里面一般放元數據，類似于信封上的寄件人和地址等，而Body里面則存放的是實際數據，類似于信封里面的主體內容。

下面我們來看一個JWT令牌的示例：

JWT令牌示例

我們先關注上圖中的左半部分，可以看到，三個部分分別使用了不同的顏色標注了出來，并且通過 .?分隔開。

畫外音：如果你沒看到，那就仔細看一下！如果還沒看到，那就打開放大看一下！

一般來說，我們都會通過一些工具例如jwt.io網站來查看JWT解碼后的內容，也就是上圖中的右半部分就是在jwt.io上進行解碼后的內容。

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

然后，Payload部分解碼后的內容說明了這個令牌的頒發者是誰（iss），頒發的時間（iat），令牌過期時間（exp）、這個令牌要頒發給誰（aud）以及目標用戶是誰（sub）。這些信息也稱為Claims，他們是官方定義的Public Claims。我們在實際使用中，也會定義一些Custom Claims，比如用戶的角色信息（Role）等。

針對ASP.NET Core開發童鞋，推薦閱讀曉晨的這篇文章實踐IdentityServer：《IdentityServer4實戰-基于角色的權限控制及Claim詳解》，傳送門：https://www.cnblogs.com/stulzq/p/8726002.html

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

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

在jwt.io上，我們可以通過輸入secret進行一個令牌的合法性的校驗，如果不通過則會顯示Invalid?Signature，通過則顯示Signature Verified.

JWT令牌校驗

看完了JWT的三個組成部分，及其組裝公式，我們可能會發現：

Header和Payload的內容是公開可見的，只要拿到Token就可以去類似jwt.io這種工具網站上進行Debug解析，那JWT真的安全嗎？

畫外音：JWT保證的安全可能是相對的，它不會保證傳輸信息的保密性，但它會保證信息的可依賴和不可篡改性（通過Signature實現）。因為Secret是保密的，所以即使一般用戶拿到了你的token和算法，也無法篡改里面的數據（一旦篡改校驗就會不通過）。換句話說，JWT令牌有點類似于現實世界中的簽名支票，如下圖所示。

簽名支票

4JWT的實現方式

上面我們了解了JWT的原理，現在來看看JWT都是如何來實現的。目前，JWT主要有兩種算法實現，一種是HMAC，另一種是RSA。

HMAC流程

首先，來看看HMAC的實現流程：

HAMC流程

Step1.客戶端向AuthServer發出登錄請求；

Step2.AuthServer校驗用戶身份，通過后生成JWT數據結構且采用某種HMAC算法+Secret對JWT進行簽名，最后將這個簽名后的JWT令牌返回給客戶端；

Step3.客戶端收到JWT后一般都會做本地存儲，然后在調用微服務的時候都會帶上JWT令牌；

Step4.微服務接收到客戶端請求和JWT令牌時，會采用同樣的Secret對JWT令牌進行解析和校驗，通過后則返回處理后的數據，不通過則一般返回401。

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

RSA流程

然后，來看看RSA的實現流程：

RSA流程

RSA流程總體上來說和HMAC類似，不同的是AuthServer在頒發JWT令牌的時候采用私鑰Private Key進行簽名，而微服務端ResourceServer在解析和校驗JWT令牌的時候采用公鑰Public Key進行簽名。

可以看出，RSA流程比HMAC流程總體來說要安全一點，因為只有AuthServer一個地方需要保存私鑰，私鑰的泄露概率就小很多。其他的微服務端都使用公鑰進行解簽校驗，但是不能夠篡改加簽。

畫外音：其實就類似于對稱加密 和 非對稱加密的方式。

5JWT學習小結

本文通過MyShop v2.5存在的問題引出了使用JWT令牌的v2.6架構，并介紹了JWT的概念、原理 和?實現方式。最后，我們來總結一下JWT的優勢及不足：

重點關注一下JWT的不足：

（1）無狀態和吊銷無法兩全，如果某個用戶令牌異常（比如有黑客在干壞事），我們想要吊銷這個用戶的令牌，但是卻沒有辦法在AuthService上進行統一吊銷，一般需要等到這個JWT令牌自然過期才能吊銷。又假設我們在AuthService上對某個用戶的信息進行了更新，那么相關的Claims信息也必須要等到這個老的JWT過期后重新登錄或刷新后產生了新的JWT后才能更新。

（2）JWT的大小會隨著Claims的數量增多，也會導致JWT的大小會變大，從而也會導致傳輸的開銷增大。

最后，我們可以對有狀態的透明令牌和無狀態的JWT令牌做一個小結：

兩者各有適用場景，JWT令牌更適合于安全不敏感場景，透明令牌更適合于安全敏感場景。這里的敏感主要是指和錢、交易、支付相關的場景，以及金融、銀行等業務之類的場景，這些場景可以采用集中式的有狀態的透明令牌認證，其他的一般性的微服務應用場景則可以使用JWT。

畫外音：對中小技術團隊來說，特別是技術儲備和實力都沒那么強的團隊，和錢相關的業務場景，寧慢三秒，不搶一秒，因為有時候想快那么一秒，可能就翻車了。

往期騷年快答

技術中臺與業務中臺有啥聯系？

微服務架構中的BFF到底是個啥？

為何微服務項目都愛用單體倉庫？

微服務安全認證架構如何演進而來的？

專注于開發技術與個人成長分享，

做對你有用的公眾號！

????點個贊和在看如何？

總結

以上是生活随笔為你收集整理的JWT是个什么鬼？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。