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

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

---

之前有同事問為何要用基于JWT令牌的認(rèn)證架構(gòu)，然后近期又有童鞋在后臺(tái)留言問微服務(wù)安全認(rèn)證架構(gòu)的實(shí)踐，因此我決定花兩篇推文來解答一下。為了答好這個(gè)話題，我們先來看看微服務(wù)的安全認(rèn)證架構(gòu)是如何演進(jìn)而來的，從而更好地理解。

1單塊階段（上）

首先，我們有必要再次了解下認(rèn)證和授權(quán)這兩個(gè)基本概念：

認(rèn)證，Authentication，識(shí)別你是誰。即在網(wǎng)站上用來識(shí)別某個(gè)用戶是否是注冊(cè)過的合法用戶。

授權(quán)，Authorization，識(shí)別你能做什么。即在網(wǎng)站上用來識(shí)別某個(gè)用戶是否有某方面的權(quán)限。

然后，這里還是引用我在波波老師的《Spring Boot與K8s云原生應(yīng)用開發(fā)》課程中學(xué)到的一個(gè)案例，來學(xué)習(xí)網(wǎng)站安全架構(gòu)的演進(jìn)。

假設(shè)我們把時(shí)間倒退回2006年，我們有一個(gè)叫做MyShop的網(wǎng)站，它的安全架構(gòu)大概是下面這個(gè)樣子，我們暫且稱之為v1版本：

MyShop v1版本的認(rèn)證操作

可以看到，這個(gè)v1版本的傳統(tǒng)安全認(rèn)證架構(gòu)，使用到了我們十分熟悉的Session + Cookie的模式來實(shí)現(xiàn)用戶的認(rèn)證。即當(dāng)一個(gè)注冊(cè)用戶通過登錄操作請(qǐng)求后，Web服務(wù)器通過向數(shù)據(jù)庫(kù)進(jìn)行校驗(yàn)用戶名和密碼，通過后就會(huì)向Session中添加一條記錄，然后返回給瀏覽器。在返回給瀏覽器的報(bào)文中，會(huì)將sessionId放在Cookie里頭。

MyShop v1版本的訪問操作

這樣一來，用戶在登錄之后再訪問網(wǎng)站的時(shí)候，就會(huì)將帶有sessionId的Cookie傳給Web服務(wù)器，而Web服務(wù)器就可以通過Cookie中的sessionId去Session記錄中檢查，如果沒有過時(shí)就認(rèn)為其是認(rèn)證的活躍用戶。

在ASP.NET Core中，提供了一個(gè)管理Session的中間件，我們可以在StartUp中注冊(cè)和使用這個(gè)中間件即可用來管理會(huì)話狀態(tài)。

參考資料：ASP.NET Core中的會(huì)話和狀態(tài)管理，傳送門：https://docs.microsoft.com/zh-cn/aspnet/core/fundamentals/app-state?view=aspnetcore-3.1

2單塊階段（下）

v1版本上線測(cè)試之后，測(cè)試人員發(fā)現(xiàn)存在一個(gè)問題：登錄用戶會(huì)間歇性地退出登錄，而且會(huì)話還沒有超時(shí)。經(jīng)過分析后發(fā)現(xiàn)，原來的Session記錄只會(huì)在登錄過的那臺(tái)Web服務(wù)器上存在，而MyShop是以集群方式來部署的，由前置的Nginx代理服務(wù)器進(jìn)行負(fù)載均衡地請(qǐng)求轉(zhuǎn)發(fā)。

針對(duì)這個(gè)問題，MyShop設(shè)計(jì)了下圖所示的v1.1版本的認(rèn)證架構(gòu)，又稱為黏性Session架構(gòu)。也就是說，不過哪一次請(qǐng)求，Nginx都會(huì)將對(duì)應(yīng)的sessionId發(fā)給對(duì)應(yīng)的Web服務(wù)器進(jìn)行處理，而不是均衡地輪流轉(zhuǎn)發(fā)。換句話說，Nginx服務(wù)器將會(huì)維護(hù)sessionId與各個(gè)Web服務(wù)器的Session之間的關(guān)聯(lián)，以保證在會(huì)話期間的Session綁定。

MyShop v1.1版本-黏性會(huì)話

就這樣，一晃兩三年又過了，MyShop v1.1的認(rèn)證架構(gòu)支持了它早期的快速發(fā)展。但是，隨著業(yè)務(wù)和用戶量的不斷擴(kuò)展，它也逐漸暴露出穩(wěn)定性和擴(kuò)展性方面的問題。這些問題，歸根結(jié)底還是由黏性會(huì)話所造成的。

（1）穩(wěn)定性：黏性會(huì)話會(huì)將用戶會(huì)話綁定到某個(gè)服務(wù)器上，如果我們要對(duì)這個(gè)服務(wù)器進(jìn)行一些升級(jí)或改造又或服務(wù)器延遲或宕機(jī)，那么此服務(wù)器上的一波認(rèn)證用戶信息就會(huì)瞬間消失，用戶必須重新登錄。

（2）擴(kuò)展性：黏性會(huì)話使得Web服務(wù)器和Nginx負(fù)載均衡服務(wù)器上都保存了狀態(tài)，整體上屬于一個(gè)有狀態(tài)架構(gòu)。隨著流量的增長(zhǎng)，這些狀態(tài)同時(shí)給Web服務(wù)器和負(fù)載均衡器都會(huì)帶來較大的壓力。和無狀態(tài)的應(yīng)用架構(gòu)比起來，這種有狀態(tài)的應(yīng)用架構(gòu)比較難以擴(kuò)展。

一般來說，常見的解決黏性會(huì)話的解決方案有以下幾種：

（1）會(huì)話同步復(fù)制：即各個(gè)Web服務(wù)器之間同步Session，但是會(huì)引入復(fù)雜性，整體的性能較低。

（2）無狀態(tài)會(huì)話：即Session數(shù)據(jù)不存在服務(wù)器端，而是存在瀏覽器端，但是存在數(shù)據(jù)泄露風(fēng)險(xiǎn)，且瀏覽器端對(duì)于Cookie的大小有限制（4KB）。

（3）集中狀態(tài)會(huì)話：即將Session集中存儲(chǔ)在某個(gè)存儲(chǔ)中，比如Memcached或Redis這種高性能緩存中。

因此，MyShop選擇了集中狀態(tài)會(huì)話的方式演進(jìn)出了v1.5安全認(rèn)證架構(gòu)，如下圖所示：

MyShop v1.5版本-集中狀態(tài)會(huì)話

在v1.5版本中，Web服務(wù)器和Nginx服務(wù)器不再存儲(chǔ)會(huì)話狀態(tài)，轉(zhuǎn)而交由Redis進(jìn)行統(tǒng)一存儲(chǔ)，從而提高了穩(wěn)定性和擴(kuò)展性。對(duì)于Redis來說，也可以采用高可用集群方案，業(yè)界也有很多可擴(kuò)展的實(shí)踐案例。

畫外音：雖然是單塊時(shí)代發(fā)展出來的技術(shù)，但是無狀態(tài)會(huì)話和集中狀態(tài)會(huì)話卻是微服務(wù)安全認(rèn)證架構(gòu)的基礎(chǔ)。

3微服務(wù)架構(gòu)階段（上）

時(shí)光飛逝，時(shí)間來到了2015年，這期間MyShop的業(yè)務(wù)量也迅速的飛漲，期間互聯(lián)網(wǎng)的技術(shù)也發(fā)生了大變化。微服務(wù)架構(gòu)、無線應(yīng)用、SPA應(yīng)用雨后春筍般的出現(xiàn)，MyShop的技術(shù)團(tuán)隊(duì)也準(zhǔn)備陸續(xù)應(yīng)用實(shí)踐，進(jìn)一步豐富和擴(kuò)展業(yè)務(wù)渠道，賦能業(yè)務(wù)端。但是，微服務(wù)架構(gòu)的安全認(rèn)證授權(quán)也存在著一些挑戰(zhàn)：

微服務(wù)認(rèn)證授權(quán)挑戰(zhàn)

（1）后臺(tái)應(yīng)用和服務(wù)眾多，如何對(duì)每一個(gè)服務(wù)進(jìn)行認(rèn)證和鑒權(quán)？傳統(tǒng)的用戶名&密碼以及Session/Cookie的方式還能夠適用嗎？

（2）前端的用戶入口眾多，如果每個(gè)入口都搞一套登錄認(rèn)證，顯然成本高且難以擴(kuò)展。有沒有一種SSO單點(diǎn)登錄的方案？

經(jīng)過MyShop技術(shù)團(tuán)隊(duì)的分析，傳統(tǒng)的用戶名&密碼+Session/Cookie的方式無法直接套用在微服務(wù)架構(gòu)上，但是可以借鑒之前的思路，他們提出了面向微服務(wù)架構(gòu)的v2.0安全認(rèn)證體系，如下圖所示：

MyShop v2.0版本-基于Token的認(rèn)證

v2.0安全認(rèn)證體系最大的變化就在于，將登陸認(rèn)證抽取為一個(gè)獨(dú)立的API微服務(wù)AuthService，擁有一個(gè)獨(dú)立的UserDB。這個(gè)服務(wù)統(tǒng)一承擔(dān)登陸認(rèn)證、用戶校驗(yàn)、令牌頒發(fā)等職責(zé)。此外，v2.0版本還引入了Token作為服務(wù)調(diào)用認(rèn)證鑒權(quán)的主要憑證。這里的話，v2.0采用的是一個(gè)透明令牌（也稱為引用令牌），即它是一個(gè)無意義的隨機(jī)字符串。這個(gè)令牌跟Auth Service上的一次登陸會(huì)話相關(guān)聯(lián)，后續(xù)也可以通過API去校驗(yàn)這個(gè)令牌的合法性。

畫外音：其實(shí)這個(gè)Token令牌，就相當(dāng)于一個(gè)SessionId。每個(gè)微服務(wù)拿到令牌，都可以去AuthService進(jìn)行認(rèn)證鑒權(quán)。

總結(jié)下來，v2.0的安全認(rèn)證體系的步驟如下：

Step1.用戶通過某種客戶端（Web/SPA/H5/App等）進(jìn)行登陸，AuthService通過比對(duì)用戶數(shù)據(jù)庫(kù)進(jìn)行校驗(yàn)；

Step2.AuthService校驗(yàn)通過后會(huì)建立一個(gè)用戶會(huì)話Session（此Session和之前版本的類似，存在一個(gè)過期時(shí)間，可以存儲(chǔ)在AuthService所在的服務(wù)器上也可以存在Redis中），然后頒發(fā)一個(gè)Token給客戶端；

Step3.客戶端向后臺(tái)微服務(wù)發(fā)請(qǐng)求，會(huì)帶上剛剛得到的Token；

Step4.微服務(wù)接收到用戶請(qǐng)求時(shí)，首先會(huì)向AuthService發(fā)出一個(gè)請(qǐng)求對(duì)這個(gè)Token進(jìn)行合法性校驗(yàn)；

Step5.AuthService校驗(yàn)Token通過后會(huì)返回該用戶的詳情信息（如果微服務(wù)需要的話，可以拿到用戶的一些比如角色之類的信息）；

Step6.微服務(wù)進(jìn)行自己的邏輯處理，最終返回?cái)?shù)據(jù)給客戶端；

畫外音：v2.0版本可以看做是v1.5的一個(gè)升級(jí)改造，專門針對(duì)微服務(wù)架構(gòu)的場(chǎng)景進(jìn)行了擴(kuò)展，可以應(yīng)對(duì)微服務(wù)架構(gòu)存在的挑戰(zhàn)。它把登錄認(rèn)證、令牌頒發(fā)等工作封裝在了AuthService中，其他微服務(wù)統(tǒng)一共用AuthService，經(jīng)過擴(kuò)展還可以實(shí)現(xiàn)SSO單點(diǎn)登錄。

4微服務(wù)架構(gòu)階段（下）

v2.0認(rèn)證架構(gòu)雖然可以解決問題，但是又引發(fā)了另外的問題：

首先，每個(gè)微服務(wù)都需要實(shí)現(xiàn)部分認(rèn)證鑒權(quán)的邏輯，使得微服務(wù)開發(fā)方無法聚焦于業(yè)務(wù)邏輯的開發(fā)。

其次，認(rèn)證鑒權(quán)邏輯分散在每個(gè)微服務(wù)當(dāng)中，一方面會(huì)帶來不規(guī)范容易出錯(cuò)的問題，另一方面也會(huì)有潛在的安全風(fēng)險(xiǎn)（比如某些開發(fā)人員可能會(huì)忘記校驗(yàn)令牌）。

為了解決上面提到的問題，同時(shí)考慮到微服務(wù)拆分后引入微服務(wù)API網(wǎng)關(guān)，MyShop技術(shù)團(tuán)隊(duì)設(shè)計(jì)了下圖所示的v2.5認(rèn)證架構(gòu)：Token+Gateway結(jié)合方式

MyShop v2.5版本-基于Token+Gateway的認(rèn)證

從上圖可以看出，該架構(gòu)將每個(gè)微服務(wù)都要進(jìn)行的部分認(rèn)證鑒權(quán)的邏輯從微服務(wù)轉(zhuǎn)移到了網(wǎng)關(guān)中。即網(wǎng)關(guān)處負(fù)責(zé)拿到令牌向AuthService進(jìn)行鑒權(quán)，通過后再將請(qǐng)求轉(zhuǎn)發(fā)到后端的微服務(wù)，微服務(wù)不再包含任何認(rèn)證鑒權(quán)的邏輯。

總體上，通過引入網(wǎng)關(guān)進(jìn)行令牌的鑒權(quán)之后，大大減少了后端微服務(wù)開發(fā)方的職責(zé)，使得他們更專注于微服務(wù)的業(yè)務(wù)邏輯的開發(fā)。此外，引入網(wǎng)關(guān)之后，網(wǎng)關(guān)可以統(tǒng)一處理登錄客戶端的校驗(yàn)，也便于實(shí)現(xiàn)SSO單點(diǎn)登錄，也為MyShop后續(xù)的微服務(wù)化和業(yè)務(wù)成長(zhǎng)提供了基礎(chǔ)。

畫外音：v2.5版本應(yīng)該是目前大多數(shù)團(tuán)隊(duì)所采用的一種認(rèn)證架構(gòu)了。對(duì)，我司也是，不過Token類型使用的是JWT。

5小結(jié)

本文通過一個(gè)MyShop的案例的演化介紹了微服務(wù)的安全認(rèn)證架構(gòu)是如何演進(jìn)而來的，但是v2.5版本（Token+Gateway方式）總體上還是比較重，每個(gè)請(qǐng)求都還是需要到AuthService上去做認(rèn)證鑒權(quán)的操作，這對(duì)于AuthService來說算是壓力比較大。針對(duì)這個(gè)問題，業(yè)界廣泛采用JWT這種輕量級(jí)的解決方案來重構(gòu)安全認(rèn)證架構(gòu)。

那么問題來了，JWT是什么？原理？實(shí)現(xiàn)方式？下一期騷年快答，為你解答這幾個(gè)問題。

往期騷年快答

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

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

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

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

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

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

總結(jié)

以上是生活随笔為你收集整理的微服务认证架构如何演进来的？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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