?你好，我是悟空。

我的師父是唐玄奘~

西游記的故事想必大家在暑假看過(guò)很多遍了，為了取得真經(jīng)，唐玄奘歷經(jīng)苦難，終于達(dá)成。

在途經(jīng)各國(guó)的時(shí)候，唐玄奘都會(huì)拿出一個(gè)通關(guān)文牒交給當(dāng)?shù)氐膰?guó)王進(jìn)行蓋章，方能通過(guò)。

本篇目錄如下：

通關(guān)文牒

通關(guān)文牒就是唐朝官方發(fā)的一個(gè)憑證，證明持有人來(lái)自東土大唐，一般是使臣持有。

有了這個(gè)憑證后，到其他國(guó)家，比如女兒國(guó)國(guó)王看到這個(gè)憑證后，就會(huì)放行。

下面來(lái)一張西游記中通關(guān)文牒的生命周期圖。

長(zhǎng)安是一個(gè)頒發(fā)憑證（通關(guān)文牒）的微服務(wù)節(jié)點(diǎn)，烏雞國(guó)、女兒國(guó)和大雷音寺等都是集群中的一個(gè)微服務(wù)節(jié)點(diǎn)，唐玄奘拿著憑證訪問(wèn)各國(guó)。

那為什么別的國(guó)家認(rèn)可這個(gè)憑證呢？

那是因?yàn)楫?dāng)時(shí)的唐朝非常強(qiáng)大，有很多國(guó)家都要向唐朝朝貢，與唐朝交好有很多好處的~

朝貢也有篇故事哦~唐太宗把微服務(wù)的“心跳機(jī)制”玩到了極致！

唐太宗在通關(guān)文牒上寫道：“倘到西邦諸國(guó)，不滅善緣，照牒放行，須至牒者?！?/p>

意思就是說(shuō)唐玄奘法師是我們唐朝的使臣，如果途經(jīng)諸侯國(guó)，希望大家放行。

貞觀之治時(shí)期的唐朝是在經(jīng)濟(jì)文化上都無(wú)比繁盛，國(guó)力強(qiáng)盛，周邊國(guó)家都希望和唐朝建立友好關(guān)系，看到是唐朝使臣來(lái)了，好生招待下，然后蓋章放行，給唐朝留個(gè)好印象。

在安全架構(gòu)中，憑證 出現(xiàn)得太頻繁了，比如我們?cè)诰W(wǎng)關(guān)這一層加的校驗(yàn)令牌，其實(shí)就是校驗(yàn)憑證。

憑證是什么

憑證（Credentials）的出現(xiàn)就是系統(tǒng)保證它與用戶之間的承諾是雙方當(dāng)時(shí)真實(shí)意圖的體現(xiàn)，是準(zhǔn)確、完整且不可抵賴的。

那唐太宗給唐玄奘的通關(guān)文牒就是一個(gè)憑證，上面蓋著唐朝的官印、唐太宗的親筆，這充分體現(xiàn)了持有者是擁有一個(gè)可信的令牌的，而且這個(gè)通關(guān)文牒上的官印是不可篡改的，如果改了，其他國(guó)家就不認(rèn)了。

上面這種模式其實(shí)對(duì)應(yīng)的是一種普通的認(rèn)證授權(quán)模式，而大名鼎鼎的 OAuth 2.0 認(rèn)證授權(quán)模式雖然有五種模式，但他們殊途同歸，最后的目的都是生成一個(gè)憑證給到客戶端，讓客戶端持有這個(gè)憑證來(lái)訪問(wèn)資源。關(guān)于 OAuth2.0 本篇不做展開(kāi)。

關(guān)于憑證的存儲(chǔ)方案，業(yè)界的安全架構(gòu)中有兩種方案：

• Cookie-Session 模式
• JWT 方案

Cookie-Session 模式

流程圖如下：

用戶登錄認(rèn)證通過(guò)后，后端會(huì)存放該客戶端的身份信息，也就是存放到 session 中，session 可以用來(lái)區(qū)分不同，然后返回一個(gè) sessionId 給到客戶端。

客戶端將 sessionId 緩存在客戶端。當(dāng)客戶端下次發(fā)送 HTTP 請(qǐng)求時(shí)，在 header 的 cookie 字段附帶著 sessionId 發(fā)送給后端服務(wù)器。

后端服務(wù)器拿到 header 中的 sessionId，然后根據(jù) sessionId 找到 session，如果 session 存在，則從 session 中解析出用戶的身份信息，然后執(zhí)行業(yè)務(wù)邏輯。

我們都知道 HTTP 協(xié)議是一種無(wú)狀態(tài)的傳輸協(xié)議，無(wú)狀態(tài)表示對(duì)一個(gè)事務(wù)的處理沒(méi)有上下文的記憶能力，每一個(gè) HTTP 請(qǐng)求都是完全獨(dú)立的。但是 Cookie-Seesion 模式卻和 HTTP 無(wú)狀態(tài)特性相悖，因?yàn)榭蛻舳嗽L問(wèn)資源時(shí)，是攜帶第一次拿到的 sessionId 的，讓服務(wù)端能夠順利區(qū)分出發(fā)送請(qǐng)求的用戶是誰(shuí)。

服務(wù)端對(duì) session 的管理，就是一種狀態(tài)管理機(jī)制，該機(jī)制存儲(chǔ)了每個(gè)在線用戶的上下文狀態(tài)，再加上一些超時(shí)自動(dòng)清理的管理措施。Cookie-Session 也是最傳統(tǒng)但今天依舊應(yīng)用到大量系統(tǒng)中，由服務(wù)端與客戶端聯(lián)動(dòng)來(lái)完成的狀態(tài)管理機(jī)制。

放到西游記中，如果用這種 Cookie-Session 模式是怎么樣的呢？

我們把唐朝和周邊國(guó)家想想成一個(gè)分布式集群?，所有國(guó)家都需要將唐玄奘這個(gè)使者信息都保存一份（分布式存儲(chǔ)），當(dāng)唐玄奘路過(guò)某個(gè)國(guó)家時(shí)，需要查詢本地存儲(chǔ)中是否有唐玄奘，如果有，則認(rèn)為唐玄奘是合法的使者，可以放行。

但是這種方式就會(huì)需要每個(gè)國(guó)家都同步保存，同步的成本是非常高昂的，而且會(huì)有同步延遲的存在。

Cookie-Session 模式的優(yōu)勢(shì)

狀態(tài)信息都存儲(chǔ)于服務(wù)器，只要依靠客戶端的同源策略和 HTTPS 的傳輸層安全，保證 Cookie 中的鍵值不被竊取而出現(xiàn)被冒認(rèn)身份的情況，就能完全規(guī)避掉上下文信息在傳輸過(guò)程中被泄漏和篡改的風(fēng)險(xiǎn)。Cookie-Session 方案的另一大優(yōu)點(diǎn)是服務(wù)端有主動(dòng)的狀態(tài)管理能力，可根據(jù)自己的意愿隨時(shí)修改、清除任意上下文信息，譬如很輕易就能實(shí)現(xiàn)強(qiáng)制某用戶下線的這樣功能。（來(lái)自鳳凰架構(gòu)）

Cookie-Session 模式的劣勢(shì)

在單節(jié)點(diǎn)的單體服務(wù)中再適合不過(guò)，但是如果需要水平擴(kuò)展要部署集群就很麻煩。

如果讓 session 分配到不同的的節(jié)點(diǎn)上，不重復(fù)地保存著一部分用戶的狀態(tài)，用戶的請(qǐng)求固定分配到對(duì)應(yīng)的節(jié)點(diǎn)上，如果某個(gè)節(jié)點(diǎn)崩潰了，則里面的用戶狀態(tài)就會(huì)完全丟失。如果讓 session 復(fù)制到所有節(jié)點(diǎn)上，那么同步的成本又會(huì)很高。

而為了解決分布式下的認(rèn)證授權(quán)問(wèn)題，并順帶解決少量狀態(tài)的問(wèn)題，就有了 JWT 令牌方案，但是 JWT 令牌和 Cookie-Session 并不是完全對(duì)等的解決方案，JWT 只能處理認(rèn)證授權(quán)問(wèn)題，且不能說(shuō) JWT 比 Cookie-Session 更加先進(jìn)，也不可能全面取代 Cookie-Seesion 機(jī)制。

JWT 方案

我們上面說(shuō)到 Cookie-Session 機(jī)制在分布式環(huán)境下會(huì)遇到一致性和同步成本的問(wèn)題，而且如果在多方系統(tǒng)中，則更不能將 Session 共享存放在多方系統(tǒng)的服務(wù)端中，即使服務(wù)端之間能共享數(shù)據(jù)，Cookie 也沒(méi)有辦法跨域。

轉(zhuǎn)換思路，服務(wù)端不保存任何狀態(tài)信息，由客戶端來(lái)存儲(chǔ)，每次發(fā)送請(qǐng)求時(shí)攜帶這個(gè)狀態(tài)信息發(fā)給后端服務(wù)。原理圖如下所示：

但是這種方式無(wú)法攜帶大量信息，而且有泄漏和篡改的安全風(fēng)險(xiǎn)。信息量大小受限沒(méi)有比較好的解決方案，但是確保信息不被中間人篡改則可以借助 JWT 方案。

JWT（JSON WEB TOKEN）是一種令牌格式，經(jīng)常與 OAuth2.0 配合應(yīng)用于分布式、多方系統(tǒng)的應(yīng)用系統(tǒng)中。

我們先來(lái)看下 JWT 的格式長(zhǎng)什么樣：

以上截圖來(lái)自 JWT 官網(wǎng)（https://jwt.io），數(shù)據(jù)則是悟空隨意編的。

左邊的字符串就是 JWT 令牌，JWT 令牌是服務(wù)端生成的，客戶端會(huì)拿著這個(gè) JWT 令牌在每次發(fā)送請(qǐng)求時(shí)放到 HTTP header 中。

而右邊是 JWT 經(jīng)過(guò) Base64 解碼后展示的明文內(nèi)容，而這段明文內(nèi)容的最下方，又有一個(gè)簽名內(nèi)容，可以防止內(nèi)容篡改?，但是不能解決泄漏的問(wèn)題。

JWT 格式

JWT 令牌是以 JSON 結(jié)構(gòu)存儲(chǔ)，用點(diǎn)號(hào)分割為三個(gè)部分。

第一部分是令牌頭（Header），內(nèi)容如下所示：

{
  "alg": "HS256",
  "typ": "JWT"
}

它描述了令牌的類型（統(tǒng)一為 typ:JWT）以及令牌簽名的算法，示例中 HS256 為 HMAC SHA256 算法的縮寫，其他各種系統(tǒng)支持的簽名算法可以參考https://jwt.io/網(wǎng)站所列。

令牌的第二部分是負(fù)載（Payload），這是令牌真正需要向服務(wù)端傳遞的信息。但是服務(wù)端不會(huì)直接用這個(gè)負(fù)載，而是通過(guò)加密傳過(guò)來(lái)的 Header 和 Payload 后再比對(duì)簽名是否一致來(lái)判斷負(fù)載是否被篡改，如果沒(méi)有被篡改，才能用 Payload 中的內(nèi)容。因?yàn)樨?fù)載只是做了 base64 編碼，并不是加密，所以是不安全的，千萬(wàn)別把敏感信息比如密碼放到負(fù)載里面。

{
  "sub": "passjava",
  "name": "悟空聊架構(gòu)",
  "iat": 1516239022
}

令牌的第三部分是簽名（Signature），使用在對(duì)象頭中公開(kāi)的特定簽名算法，通過(guò)特定的密鑰（Secret，由服務(wù)器進(jìn)行保密，不能公開(kāi)）對(duì)前面兩部分內(nèi)容進(jìn)行加密計(jì)算，以例子里使用的 JWT 默認(rèn)的 HMAC SHA256 算法為例，將通過(guò)以下公式產(chǎn)生簽名值：

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload) , secret)

簽名的意義：確保負(fù)載中的信息是可信的、沒(méi)有被篡改的，也沒(méi)有在傳輸過(guò)程中丟失任何信息。因?yàn)楸缓灻膬?nèi)容哪怕發(fā)生了一個(gè)字節(jié)的變動(dòng)，也會(huì)導(dǎo)致整個(gè)簽名發(fā)生顯著變化。此外，由于簽名這件事情只能由認(rèn)證授權(quán)服務(wù)器完成（只有它知道 Secret），任何人都無(wú)法在篡改后重新計(jì)算出合法的簽名值，所以服務(wù)端才能夠完全信任客戶端傳上來(lái)的 JWT 中的負(fù)載信息。

JWT 的優(yōu)勢(shì)

• 無(wú)狀態(tài)：不需要服務(wù)端保存 JWT 令牌，也就是說(shuō)不需要服務(wù)節(jié)點(diǎn)保留任何一點(diǎn)狀態(tài)信息，就能在后續(xù)的請(qǐng)求中完成認(rèn)證功能。
• 天然的擴(kuò)容便利：服務(wù)做水平擴(kuò)容不用考慮 JWT 令牌，而 Cookie-Session 是需要考慮擴(kuò)容后服務(wù)節(jié)點(diǎn)如何存儲(chǔ) Session 的。
• 不依賴 Cookie：JWT 可以存放在瀏覽器的 LocalStorage，不一定非要存儲(chǔ)在 Cookie 中。

JWT 的劣勢(shì)

• 令牌難以主動(dòng)失效：JWT 令牌簽發(fā)后，理論上和認(rèn)證的服務(wù)器就沒(méi)有什么關(guān)系了，到期之前始終有效。除非服務(wù)器加些特殊的邏輯處理來(lái)緩存 JWT，并來(lái)管理 JWT 的生命周期，但是這種方式又會(huì)退化成有狀態(tài)服務(wù)。而這種要求有狀態(tài)的需求又很常見(jiàn)：譬如用戶退出后，需要重新輸入用戶名和密碼才能登錄；或者用戶只允許在一臺(tái)設(shè)備登錄，登錄到另外一臺(tái)設(shè)備，要求強(qiáng)行退出。但是這種有狀態(tài)的模式，降低了 JWT 本身的價(jià)值。
• 更容易遭受重放攻擊：Cookie-Session 也有重放攻擊的問(wèn)題，也就是客戶端可以拿著這個(gè) cookie 不斷發(fā)送大量請(qǐng)求，對(duì)系統(tǒng)性能造成影響。但是因?yàn)?Session 在服務(wù)端也有一份，服務(wù)端可以控制 session 的生命周期，應(yīng)對(duì)重放攻擊更加主動(dòng)一些。但是 JWT 的重放攻擊對(duì)于服務(wù)端來(lái)說(shuō)就很被動(dòng)，比如通過(guò)客戶端的驗(yàn)證碼、服務(wù)端限流或者縮短令牌有效期，應(yīng)用起來(lái)都會(huì)麻煩些。
• 存在泄漏的風(fēng)險(xiǎn)：客戶端存儲(chǔ)，很有可能泄漏出去，被其他人重復(fù)利用。
• 信息大小有限：HTTP 協(xié)議并沒(méi)有強(qiáng)制約束 Header 的最大長(zhǎng)度，但是服務(wù)器、瀏覽器會(huì)做限制。而且如果令牌很大還會(huì)消耗傳輸帶寬。

真假美猴王

西游記中還有一個(gè)章節(jié)，假的美猴王帶著通關(guān)文牒和其他行李跑到了花果山，還想自行取經(jīng)，這不就是盜用  JWT 令牌了嗎？

如何使用 JWT

Java 有現(xiàn)成的工具類可以使用，而且校驗(yàn) JWT 的工作可以統(tǒng)一交給網(wǎng)關(guān)來(lái)做，這個(gè)就是下一篇要重點(diǎn)講解的實(shí)戰(zhàn)內(nèi)容了。

總結(jié)

唐玄奘就好比客戶端，通關(guān)文牒就好比 JWT 令牌，經(jīng)過(guò)的每個(gè)國(guó)家就好比集群中的微服務(wù)。

唐玄奘借助 JWT 令牌的認(rèn)證授權(quán)模式，一路通關(guān)，最終取得真經(jīng)，是不是很酷呀~