大型網(wǎng)站的用戶登錄系統(tǒng)是如何設(shè)計(jì)的？

時(shí)間：2024-02-13 17:50:01 | 來源：網(wǎng)站運(yùn)營(yíng)

時(shí)間：2024-02-13 17:50:01 來源：網(wǎng)站運(yùn)營(yíng)

大型網(wǎng)站的用戶登錄系統(tǒng)是如何設(shè)計(jì)的？：

原文首發(fā)自我的博客：分布式系統(tǒng)下的認(rèn)證與授權(quán)

在軟件系統(tǒng)設(shè)計(jì)中，如何讓應(yīng)用能夠在各種環(huán)境中安全高效的訪問是個(gè)復(fù)雜的問題，這個(gè)問題的背后是一系列軟件設(shè)計(jì)時(shí)需要考慮的架構(gòu)安全問題：架構(gòu)安全性 | 鳳凰架構(gòu)

• 認(rèn)證：系統(tǒng)如何識(shí)別合法用戶，也就是解決 你是誰 的問題；
• 授權(quán)：系統(tǒng)在識(shí)別合法用戶后，還需要解決 你能做什么 的問題；
• 憑證：系統(tǒng)如何保證它與用戶之間的承諾是雙方真實(shí)意圖的體現(xiàn)，是準(zhǔn)確、完整且不可抵賴的；
• 保密：如何安全的持久化用戶的賬戶信息，確保不會(huì)被任何人竊取與濫用；
• 傳輸：在復(fù)雜的用戶環(huán)境中，如何安全的傳遞用戶信息，保證不被第三方竊聽、篡改和冒充。

在漫長(zhǎng)的架構(gòu)演進(jìn)歷史中，業(yè)界對(duì)這些問題已經(jīng)有很成熟的解決方案。在架構(gòu)安全這塊，最好的是遵循技術(shù)標(biāo)準(zhǔn)與最佳實(shí)踐，盡可能不重復(fù)造輪子或“創(chuàng)新”。下面這個(gè)思維導(dǎo)圖就是針對(duì)這些問題的常見的技術(shù)標(biāo)準(zhǔn)及方案：




在研究分布式系統(tǒng)的認(rèn)證和授權(quán)問題前，讓我們回到單體架構(gòu)的時(shí)代，看看在單體架構(gòu)上這些問題是如何被解決的。

單體系統(tǒng)

認(rèn)證

認(rèn)證主要解決 你是誰 的問題，從方式上來看有以下三種：認(rèn)證 | 鳳凰架構(gòu)

• 基于通信信道：建立通信信道之前需要證明 你是誰。在網(wǎng)絡(luò)傳輸（Network）場(chǎng)景中的典型是基于 SSL/TLS 傳輸安全層的認(rèn)證。
• 基于通信協(xié)議：在獲取資源之前需要證明 你是誰。在互聯(lián)網(wǎng)（Internet）場(chǎng)景中的典型是基于 HTTP 協(xié)議的認(rèn)證。
• 基于通信內(nèi)容：在提供服務(wù)之前需要證明 你是誰。在萬維網(wǎng)（World Wide Web）場(chǎng)景中的典型是基于 Web 內(nèi)容的認(rèn)證。

在單體系統(tǒng)時(shí)代，認(rèn)證方式一般是在通信信道上開啟 HTTPS，在通信協(xié)議上利用 HTTP Basic/Digest/Bearer/HOBA/OCRA 等方式并在通信內(nèi)容上結(jié)合表單或 TOTP 等的認(rèn)證組合方式。這樣可以從通信的不同階段獲得相應(yīng)的安全保證。

如果想對(duì)基于 HTTP 協(xié)議的認(rèn)證方式做進(jìn)一步的了解，可以參考這兩篇文章：

1. 認(rèn)證 | 鳳凰架構(gòu)
2. 細(xì)說API - 認(rèn)證、授權(quán)和憑證 - Thoughtworks洞見

單點(diǎn)登錄（SSO）

認(rèn)證的一個(gè)常見應(yīng)用場(chǎng)景是單點(diǎn)登錄。單點(diǎn)登錄主要解決了一個(gè)一次登錄訪問多個(gè)獨(dú)立應(yīng)用的問題。在單點(diǎn)登錄方案出現(xiàn)之前，每個(gè)應(yīng)用都需要獨(dú)立登錄維持各自的會(huì)話。相關(guān)的技術(shù)方案已經(jīng)很成熟，主要有以下：

• Kerberos-based：MIT 設(shè)計(jì)的 SSO 協(xié)議，基于對(duì)稱密碼學(xué)，并需要一個(gè)值得信賴的第三方。其廣泛用于操作系統(tǒng)認(rèn)證，如被 Windows 2000 和后續(xù)的操作系統(tǒng)作為默認(rèn)的認(rèn)證方法。
• CAS：Yale 設(shè)計(jì)的 SSO 協(xié)議，基于瀏覽器的 SSO 方案，部署簡(jiǎn)單，適用于簡(jiǎn)單的應(yīng)用場(chǎng)景。
• SAML：基于 XML 標(biāo)記語言的認(rèn)證斷言方案，適用的場(chǎng)景眾多，但技術(shù)較復(fù)雜。
• OIDC：在 OAuth2 的基礎(chǔ)上額外加一個(gè) JWT 來傳遞用戶信息。功能全面強(qiáng)大，是目前很流行的 SSO 方案。

授權(quán)

授權(quán)主要解決 你能做什么 的問題，從方案上來說有以下幾種：

• ACL：訪問控制列表（Access-control list）廣泛用于操作系統(tǒng)內(nèi)部的文件系統(tǒng)、網(wǎng)絡(luò)及進(jìn)程權(quán)限控制方面。如在 Linux 中，可通過 getfacl 獲取目錄的默認(rèn) ACL 設(shè)置。
• RBAC：RBAC 通過將權(quán)限屬性從 ACL 方案中的單個(gè)用戶抽取成更為抽象的角色（Role），通過給角色一組權(quán)限屬性，再將多個(gè)角色賦予某個(gè)用戶，實(shí)現(xiàn)了比 ACL 更為靈活強(qiáng)大的權(quán)限控制方案。實(shí)際上大部分系統(tǒng)的授權(quán)方案采用 RBAC 就足夠了。但 RBAC 在面臨復(fù)雜的權(quán)限控制需求時(shí)可能面臨角色爆炸的問題，這時(shí)可以考慮采用更細(xì)粒度的 ABAC 方案。
• ABAC：ABAC 是比 RBAC 更細(xì)粒度的權(quán)限控制方案。通過引入一組稱為“屬性“的特征，包括用戶屬性、環(huán)境屬性和資源屬性。例如，ABAC 可以對(duì)用戶的訪問做進(jìn)一步的控制，如只允許在特定的時(shí)間或與相關(guān)員工相關(guān)的某些分支機(jī)構(gòu)進(jìn)行訪問員工信息的操作，而不是讓某部門的人員總是能夠訪問員工信息。但 ABAC 的問題在于初始設(shè)置需要定義大量的屬性，工作量比 RBAC 要大。
• OAuth2：OAuth2 是為了解決應(yīng)用系統(tǒng)給第三方系統(tǒng)授權(quán)的問題而設(shè)計(jì)的授權(quán)框架。傳統(tǒng)的客戶端服務(wù)器交互模式中，客戶端持有資源訪問憑證（如用戶名密碼），服務(wù)端驗(yàn)證成功后放行。而在給第三方系統(tǒng)提供資源時(shí)，如果給第三方系統(tǒng)資源憑證，可能會(huì)帶來未知的安全問題，比如憑證泄漏，憑證回收等問題。如果應(yīng)用系統(tǒng)需面向第三方系統(tǒng)提供服務(wù)，那需要使用此方案。同時(shí)因?yàn)?OAuth2 做授權(quán)的時(shí)候一般需要用戶登錄，也能實(shí)現(xiàn)單點(diǎn)登錄的功能。

如果想對(duì)授權(quán)做進(jìn)一步的了解，可以參考這篇文章：

1. 授權(quán) | 鳳凰架構(gòu)

憑證

憑證是為了解決在認(rèn)證授權(quán)后如何承載認(rèn)證授權(quán)信息的問題。在單體應(yīng)用時(shí)代，主流的解決方案是基于 HTTP 協(xié)議的 Cookie-Session 機(jī)制為代表的服務(wù)端狀態(tài)存儲(chǔ)技術(shù)。

由于 HTTP 協(xié)議本身是無狀態(tài)的，要維持一個(gè)會(huì)話（Session），而不是每次訪問都重新認(rèn)證授權(quán)，需要客戶端也就是瀏覽器通過 Cookie 來存儲(chǔ)服務(wù)器端返回的一個(gè)憑證信息，這個(gè)憑證信息一般是一串隨機(jī)的字符串，用來代表用戶此次的會(huì)話標(biāo)識(shí)。每次請(qǐng)求瀏覽器都會(huì)在 HTTP Header 中攜帶這個(gè) Cookie 信息，應(yīng)用拿到這個(gè)會(huì)話標(biāo)識(shí)后從內(nèi)存或緩存（Cache）中查詢出用戶的信息，這樣就定位到了具體的用戶，實(shí)現(xiàn)了會(huì)話的維持。

這套古老的方案存在以下先天優(yōu)勢(shì)：憑證 | 鳳凰架構(gòu)

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

一切都很美好，直到我們來到了分布式系統(tǒng)時(shí)代。

分布式系統(tǒng)

分布式系統(tǒng)與單體系統(tǒng)的一大區(qū)別就是狀態(tài)管理。分布式系統(tǒng)通過把單體系統(tǒng)中有狀態(tài)的部分轉(zhuǎn)移到中間件中去管理，從而很容易做到水平擴(kuò)容，提高系統(tǒng)峰值處理能力。在架構(gòu)認(rèn)證和授權(quán)部分，分布式和單體并沒有什么不同，唯獨(dú)有變化的在持有狀態(tài)的憑證部分。

我們知道單體應(yīng)用在服務(wù)端管理用戶會(huì)話信息，客戶端只持有會(huì)話標(biāo)識(shí)。如果服務(wù)端要將此用戶會(huì)話狀態(tài)轉(zhuǎn)移出去有兩種處理思路：

• 將用戶會(huì)話信息繼續(xù)托管至服務(wù)端。此時(shí)有幾種服務(wù)端方案可以選擇：
• 中心化存儲(chǔ)：轉(zhuǎn)移到中間件如 Redis 中去。利用 Redis 極高的并發(fā)處理能力，也可以做到彈性橫行擴(kuò)容。不過可能會(huì)帶來中間件高可用性維護(hù)難的問題，通過租賃云服務(wù)商的托管中間件是降低中間件 單點(diǎn)故障（SPOF） 的一種方式；
• 會(huì)話復(fù)制（Session replication）：讓各個(gè)節(jié)點(diǎn)之間采用復(fù)制式的 Session，每一個(gè)節(jié)點(diǎn)中的 Session 變動(dòng)都會(huì)發(fā)送到組播地址的其他服務(wù)器上，這樣某個(gè)節(jié)點(diǎn)崩潰了，不會(huì)中斷該節(jié)點(diǎn)用戶的服務(wù)。但 Session 之間組播復(fù)制的同步代價(jià)高昂，節(jié)點(diǎn)越多時(shí)，同步成本越高。
• 會(huì)話粘滯（Sticky session）：通過負(fù)載均衡算法如 Nginx 的 IP Hash 算法將來自同一 IP 的請(qǐng)求轉(zhuǎn)發(fā)至同一服務(wù)。每個(gè)服務(wù)節(jié)點(diǎn)都不重復(fù)地保存著一部分用戶的狀態(tài)，如果這個(gè)服務(wù)崩潰了，里面的用戶狀態(tài)便完全丟失。

為什么在分布式系統(tǒng)中共享狀態(tài)就這么困難？這是因?yàn)榉植际较到y(tǒng)中有一個(gè)不可能三角的理論：CAP。這個(gè)理論簡(jiǎn)單的理解就是因?yàn)樵诜植际较到y(tǒng)中，因?yàn)榫W(wǎng)絡(luò)無法做到絕對(duì)的可靠（分區(qū)容錯(cuò)性：Partition Tolerance），只能在一致性（Consistency）和可靠性（Availability）間選擇一個(gè)。
比如上述的三種服務(wù)端方案其實(shí)都是犧牲了 CAP 的某個(gè)方面。比如第一種中心化存儲(chǔ)方案我們放棄了中心化存儲(chǔ)的分區(qū)容錯(cuò)性，一旦其網(wǎng)絡(luò)分區(qū)，整個(gè)集群都會(huì)不可用。第二種會(huì)話復(fù)制方案我們犧牲了可用性，當(dāng)節(jié)點(diǎn)在同步會(huì)話數(shù)據(jù)時(shí)，整個(gè)服務(wù)會(huì)短暫的不可用。第三種會(huì)話粘滯方案我們犧牲了一致性，一旦某個(gè)節(jié)點(diǎn)宕機(jī)，整個(gè)集群的數(shù)據(jù)會(huì)因該節(jié)點(diǎn)的數(shù)據(jù)丟失而達(dá)到不一致的狀態(tài)。

• 將狀態(tài)從服務(wù)端轉(zhuǎn)移到客戶端。Cookie-Session 是一種引用令牌（Reference tokens），也就是客戶端持有的是服務(wù)端存儲(chǔ)的會(huì)話引用標(biāo)識(shí)。還有一種自包含令牌（Self-contained tokens），如 JWT 就是這種客戶端保存會(huì)話信息的技術(shù)，服務(wù)端只是去校驗(yàn)會(huì)話信息是否合法。

JWT

如果你對(duì) JWT 不了解，可以先看這兩篇：

1. JWT | 鳳凰架構(gòu)
2. The Hard Parts of JWT Security Nobody Talks About

由于 JWT 的 Payload 并未做過多限制，所以很容易產(chǎn)生濫用的問題，并且?guī)砗芏嗾`解。 比如下面的一些問題：

• 誤把 JWT 當(dāng)作 Cookie-Session 使用（把 JWT 當(dāng)作引用令牌使用），會(huì)帶來未知的隱患。遵循不重復(fù)造輪子和“創(chuàng)新”的指導(dǎo)原則，盡可能不要這么做；
• 認(rèn)為 JWT 更安全。雖然 JWT 采用了一定的加密算法簽名，使其具備了抗篡改的能力。但其 Payload 大部分都只是采用 base64UrlEncode 編碼，數(shù)據(jù)并不是加密的。攻擊者可以通過 會(huì)話劫持（Session hijacking） 技術(shù)拿到 JWT 會(huì)話信息，之后通過 會(huì)話重放攻擊（Session Replay Attack） 獲取用戶資源，所以最佳實(shí)踐是通過啟用 TLS/SSL 來加密通信信道。
• 把 JWT 存儲(chǔ)到瀏覽器的 Local Storage 中。此方式很容易受到 XSS 攻擊導(dǎo)致 JWT 泄漏。可通過服務(wù)端啟用 內(nèi)容安全策略（CSP） 來防御這種攻擊。
• 采用對(duì)稱加密方式簽名（Signature）。對(duì)稱加密密鑰一旦泄漏，會(huì)讓整個(gè)服務(wù)的基礎(chǔ)設(shè)施遭受安全威脅。JWT 支持非對(duì)稱加密算法，只有簽名的服務(wù)需要私鑰，其他驗(yàn)證 JWT 信息的服務(wù)只需要使用公鑰即可。
• 不校驗(yàn) JWT 的簽名算法。這篇 Critical vulnerabilities in JSON Web Token libraries 文章提到 JWT 的一種漏洞，通過 none 算法規(guī)避令牌驗(yàn)證。所以最好每次都驗(yàn)證 JWT header 中的簽名算法是否是期望的。

相信看了上述的一些問題，你對(duì) JWT 的“簡(jiǎn)單、安全”有了新的理解。這還沒完，JWT 還有以下一些 Cookie-Session 沒有的問題：

• 令牌難以主動(dòng)失效：JWT 中雖然有 exp、nbf 與 iat 這些和時(shí)間相關(guān)的屬性，但很難在令牌到期之前讓令牌失效，比如很難在用戶退出登錄時(shí)立刻讓簽發(fā)的令牌全部失效。雖然可能通過一些“黑名單”的技術(shù)解決這個(gè)問題，不過相比 Cookie-Session 來說，引入了一定的復(fù)雜性；
• 令牌數(shù)據(jù)老舊：很難把簽發(fā)的令牌全部更新成最新的數(shù)據(jù)。比如把用戶的權(quán)限信息（Role）放在 JWT Payload 中，當(dāng)用戶的角色發(fā)生變化時(shí)，很難把之前簽發(fā)的令牌信息更新成最新的數(shù)據(jù)；
• 令牌存儲(chǔ)：存儲(chǔ)在客戶端意味著有多種選擇：Cookie？Local Storage？如果放在 Cookie 中，為了安全，一般會(huì)給 Cookie 設(shè)置 http-only 和 secure 的屬性。但這也會(huì)帶來一定的不便性，比如客戶端要讀取 JWT Payload 的內(nèi)容只能借助服務(wù)端 API 接口。如果將 JWT 存儲(chǔ)至瀏覽器 Local Storage，雖然方便了客戶端讀取，但可能會(huì)帶來 XSS 攻擊的威脅，又需要去設(shè)置 CSP 來防御這種威脅；
• 令牌大?。篔WT 相比 Cookie-Session 還是大不少，尤其是要在 Payload 中存儲(chǔ)一些額外的權(quán)限信息。一般服務(wù)端都有對(duì) HTTP Header 的大小限制；
• 網(wǎng)絡(luò)開銷：更大的文本意味著更高的網(wǎng)絡(luò)開銷，進(jìn)一步會(huì)需要更復(fù)雜的基礎(chǔ)設(shè)施，也會(huì)產(chǎn)生復(fù)雜的運(yùn)維問題等；
• 難以統(tǒng)計(jì)：服務(wù)端無狀態(tài)意味著很難做諸如統(tǒng)計(jì)用戶在線數(shù)量的功能；

JWT 解決了 Cookie-Session 方案在分布式系統(tǒng)中因 CAP 的限制而帶來的問題，但同時(shí)也帶來了一些新的問題。所以并不能說 JWT 就是 Cookie-Session 在分布式系統(tǒng)中的完美替代。

那么 JWT 的最佳使用場(chǎng)景到底是什么？這篇 Stop using JWT for sessions 給出了以下的結(jié)論：JWT 更適合作分布式系統(tǒng)中的一次性令牌使用。分布式系統(tǒng)繼續(xù)使用 Cookie-Session 做會(huì)話管理，但可以在認(rèn)證鑒權(quán)后生成 JWT 做分布式系統(tǒng)內(nèi)部服務(wù)調(diào)用間的一次性令牌。

讓我們通過一個(gè)例子來理解下在分布式系統(tǒng)下的認(rèn)證授權(quán)場(chǎng)景。

一個(gè)例子

1. 用戶通過 HTTPS 訪問我們的應(yīng)用。當(dāng)請(qǐng)求發(fā)送至微服務(wù)網(wǎng)關(guān)層（Gateway），網(wǎng)關(guān)檢測(cè) HTTP Header 中的 Cookie 發(fā)現(xiàn)沒有 SESSIONID 這個(gè)鍵值對(duì)，重定向至 SSO 登錄頁面。
2. 用戶通過 SSO 登錄我們的應(yīng)用。
1. 用戶信息存放至 AD/LDAP 等系統(tǒng)中。管理員提前給用戶配置好角色權(quán)限。
2. SSO 集成方案我們選擇 OIDC。OIDC 集成了 AD/LDAP，當(dāng)用戶提供正確的用戶名和密碼后，SSO 重定向至網(wǎng)關(guān)。
3. 網(wǎng)關(guān)生成了 SESSIONID 鍵值對(duì)并通過 HTTP Set-Cookie 響應(yīng)給用戶瀏覽器設(shè)置了此 Cookie。
3. 瀏覽器重新發(fā)起帶 SESSIONID Cookie 的請(qǐng)求。網(wǎng)關(guān)經(jīng)過查詢其緩存或中間件（如將會(huì)話信息存放至 Redis）中的 Session 信息確認(rèn)了用戶的身份信息。之后網(wǎng)關(guān)請(qǐng)求 Auth 服務(wù)利用其私鑰簽名生成 JWT 憑證，JWT Payload 中可以存放一部分用戶信息和角色信息，這些信息可以從中間件中或 AD/LDAP 中查詢出。
4. 網(wǎng)關(guān)之后將此 JWT 憑證通過反向代理轉(zhuǎn)發(fā)至內(nèi)部的 BFF 服務(wù)，之后請(qǐng)求到達(dá)內(nèi)部的領(lǐng)域微服務(wù)。
5. 各領(lǐng)域微服務(wù)接受到請(qǐng)求后，先從 HTTP Header 中拿出 JWT 憑證。
1. 在執(zhí)行真正的業(yè)務(wù)邏輯前，先利用之前定時(shí)從 Auth 服務(wù)中同步獲取的公鑰。
1. Auth 服務(wù)通過一個(gè)類似 https://<your_domain>/.well-known/jwks.json 的 API 提供 JWT 公鑰的分發(fā)。關(guān)于 .well-known 前綴，可閱讀 RFC 5785 做進(jìn)一步了解。在 jwks.json 文件中，我們可以找到 JWK 或 JSON Web Key，這是我們用來驗(yàn)證簽名的公鑰。
2. 校驗(yàn) JWT 這塊邏輯屬于微服務(wù)共有的部分，一般可以開發(fā)一個(gè) SDK 包來做這個(gè)通用的工作。為了提高性能，可使用緩存技術(shù)，定時(shí)從 Auth 中同步公鑰。
2. 獲取到公鑰后驗(yàn)證成功后拿出 JWT Payload 即可獲取到用戶信息和角色權(quán)限。

全部流程就是這樣，我們得到了以下的一些好處：

• 這個(gè)流程里我們并沒有將 JWT 返回給用戶，只是在認(rèn)證授權(quán)過后生成一個(gè)一次性的 JWT 令牌憑證用于微服務(wù)內(nèi)部服務(wù)間的調(diào)用。因?yàn)橛脩舻臋?quán)限信息存放至 JWT Payload 中，內(nèi)部的服務(wù)并不需要從 AD/LDAP 中獲取用戶權(quán)限信息?？赡苡腥擞X得內(nèi)部服務(wù)直接從中間件中獲取用戶會(huì)話信息也可以，但這又讓我們的應(yīng)用進(jìn)一步耦合了中間件，同時(shí)也讓一個(gè)請(qǐng)求鏈路中產(chǎn)生更多的子請(qǐng)求，不如直接在請(qǐng)求頭中存放用戶信息的方式高效。
• 在微服務(wù)內(nèi)部間傳遞的是經(jīng)過非對(duì)稱加密算法簽名的 JWT 憑證，并不是一個(gè) JWT Payload 信息。就算我們的微服務(wù)內(nèi)部被入侵，攻擊者也并不能通過篡改憑證中用戶的權(quán)限信息來搞破壞。這也滿足了分布式系統(tǒng)中 零信任網(wǎng)絡(luò)（Zero Trust） 的部分要求。
• 與外部第三方應(yīng)用的通訊（M2M），可以采用 OAuth2 的方式或 Personal Access Token 這種方式來集成。
• 通過引入 SDK 與定時(shí)同步公鑰的機(jī)制，我們引入了一定的復(fù)雜度。比如 SDK 在異構(gòu)編程語言的項(xiàng)目中開發(fā)復(fù)雜的問題。不過這個(gè)問題在云原生系統(tǒng)時(shí)代有了不同的解法，讓我們之后討論這個(gè)問題。

架構(gòu)總是在演進(jìn)，也許分布式系統(tǒng)中很多問題我們還沒完全解決，就來到了云原生時(shí)代。

云原生系統(tǒng)

如果你對(duì)云原生應(yīng)用開發(fā)還不了解的話，可以先看看我這篇 K8S 云原生應(yīng)用開發(fā)小記。云原生系統(tǒng)其實(shí)并不是什么后分布式系統(tǒng)時(shí)代。它們兩者都是為了解決不同場(chǎng)景的問題而出現(xiàn)的解決方案。

在認(rèn)證授權(quán)這塊，云原生系統(tǒng)的優(yōu)勢(shì)在于可以通過 服務(wù)網(wǎng)格(Service Mesh) 做一些業(yè)務(wù)系統(tǒng)中通用的切面工作，比如我們?cè)诜植际较到y(tǒng)中遇到的校驗(yàn) JWT 的 SDK 其實(shí)就可以放入服務(wù)網(wǎng)格中的邊車（Sidecar）去實(shí)現(xiàn)，讓業(yè)務(wù)應(yīng)用更專注特定領(lǐng)域的業(yè)務(wù)。

由于這篇文章并不主要討論云原生，對(duì)這部分感興趣的可以參考以下兩篇文章做進(jìn)一步了解：

1. Service Mesh架構(gòu)下的認(rèn)證與授權(quán)
2. Authentication sidecar

總結(jié)

由于篇幅及能力限制，這篇文章我只能從高層次梳理在不同架構(gòu)演進(jìn)中認(rèn)證、授權(quán)及憑證這些和架構(gòu)安全相關(guān)的技術(shù)的發(fā)展過程。由于這些技術(shù)涉及了大量的技術(shù)標(biāo)準(zhǔn)及實(shí)踐，很難在一篇文章中對(duì)這些技術(shù)做詳盡的分享，更無法去分享如何實(shí)現(xiàn)。但有了這些理論支持和最佳實(shí)踐，希望能讓你在實(shí)現(xiàn)的過程中多了一個(gè)指引。如果你想進(jìn)一步了解，可參考文章中的參考文章鏈接。

最后，技術(shù)總是在不斷的發(fā)展，但并不是新技術(shù)總比老技術(shù)“先進(jìn)”。正如文章中對(duì) Cookie-Session 與 JWT 的分析對(duì)比，技術(shù)方案總是充滿了各種 Trade-off。而作為一個(gè)工程師，我們能做的就是認(rèn)清這些技術(shù)的歷史背景及局限性，選擇最適合項(xiàng)目需求的技術(shù)方案。