一、預(yù)備知識

本文討論基于微服務(wù)架構(gòu)下的身份認(rèn)證和用戶授權(quán)的技術(shù)方案，在閱讀之前，最好先熟悉并理解以下幾個知識點：

• 微服務(wù)架構(gòu)相關(guān)概念：服務(wù)注冊、服務(wù)發(fā)現(xiàn)、API 網(wǎng)關(guān)
• 身份認(rèn)證和用戶授權(quán)：SSO、CAS、OAuth2、JWT

文章在涉及到上述知識內(nèi)容時，會附上參考鏈接。

二、背景

當(dāng)企業(yè)的應(yīng)用系統(tǒng)逐漸增多后，每個系統(tǒng)單獨(dú)管理各自的用戶數(shù)據(jù)容易行成信息孤島，分散的用戶管理模式阻礙了企業(yè)應(yīng)用向平臺化演進(jìn)。當(dāng)企業(yè)的互聯(lián)網(wǎng)業(yè)務(wù)發(fā)展到一定規(guī)模，構(gòu)建統(tǒng)一的標(biāo)準(zhǔn)化賬戶管理體系將是必不可少的，因為它是企業(yè)互聯(lián)網(wǎng)云平臺的重要基礎(chǔ)設(shè)施，能夠為平臺帶來統(tǒng)一的賬號管理、身份認(rèn)證、用戶授權(quán)等基礎(chǔ)能力，為企業(yè)帶來諸如跨系統(tǒng)單點登錄、第三方授權(quán)登錄等基礎(chǔ)能力，為構(gòu)建開放平臺和業(yè)務(wù)生態(tài)提供了必要條件。

三、需求分析

在微服務(wù)架構(gòu)下，必須對企業(yè)的平臺生態(tài)進(jìn)行合理的業(yè)務(wù)劃分，每個業(yè)務(wù)板塊將自成系統(tǒng)，例如負(fù)責(zé)宣發(fā)的企業(yè)官網(wǎng)、主打文體的 B2B2C 商城、面向社區(qū)的物業(yè)服務(wù)系統(tǒng)等，這些系統(tǒng)業(yè)務(wù)比較獨(dú)立，應(yīng)當(dāng)獨(dú)立拆分。每個系統(tǒng)又可根據(jù)各自的業(yè)務(wù)模型進(jìn)行切分，將業(yè)務(wù)模型和用戶需求統(tǒng)籌分析后建立恰當(dāng)?shù)念I(lǐng)域模型，形成獨(dú)立的服務(wù)。

另外，企業(yè)平臺的客戶范圍比較復(fù)雜，有 2B 的業(yè)務(wù)，也有 2C 的，還有 2G（goverment）的，因此平臺級的統(tǒng)一身份管理必須涉及組織實體和個人實體兩類，其中組織實體包括政府機(jī)關(guān)（G）、企業(yè)單位（B）、團(tuán)體組織（B）等，這類似于多租戶架構(gòu)的概念，但又比傳統(tǒng)多租戶架構(gòu)復(fù)雜。

一）統(tǒng)一身份管理（Unified Identity Manager）

統(tǒng)一身份管理（UIM）是整個平臺賬號和權(quán)限管控的基礎(chǔ)，由此構(gòu)建的系統(tǒng)稱為UIMS（Unified Identity Management System），平臺下所有系統(tǒng)的賬戶管理、身份認(rèn)證、用戶授權(quán)、權(quán)限控制等行為都經(jīng)由 UIMS 處理，提供賬號密碼管理、基本資料管理、角色權(quán)限管理等功能。UIMS 基于『統(tǒng)一身份治理』的概念，可劃分為兩級賬戶體系、基礎(chǔ)權(quán)限模塊和基礎(chǔ)信息模塊三大模塊。其中兩級賬戶體系將賬戶分為組織實體賬號和個人實體賬戶兩大類，個人實體從屬于組織實體，也可以不從屬任何組織實體，且個人實體可同時從屬于多個組織實體；基礎(chǔ)權(quán)限模塊將各業(yè)務(wù)系統(tǒng)的資源權(quán)限進(jìn)行統(tǒng)一管理和授權(quán)；基礎(chǔ)信息模塊用于描述組織實體和個人實體的基本信息，如組織實體名稱、地址、法人，個人實體姓名、電話號碼、性別等基礎(chǔ)信息。UIMS 提供統(tǒng)一的 API 與各子系統(tǒng)連接。

可以看到，眾多系統(tǒng)和眾多服務(wù)都將依賴于 UIMS 。本文僅涉及 UIMS 下的身份認(rèn)證和用戶授權(quán)這兩塊，即兩級賬戶體系和基礎(chǔ)權(quán)限模塊，據(jù)此可以獨(dú)立出賬戶服務(wù)和鑒權(quán)服務(wù)，也可以合并成一個賬戶鑒權(quán)服務(wù)。

關(guān)于統(tǒng)一身份管理系統(tǒng)的介紹，請參考 https:///平臺級SAAS架構(gòu)的基礎(chǔ)-統(tǒng)一身份管理系統(tǒng).html

二）軟件即服務(wù)（SAAS）

企業(yè)提供對外的 IT 服務(wù)，有兩種部署模式：一是私有云部署，二是公有化服務(wù)。公有云服務(wù)即 SAAS，提供系統(tǒng)級的應(yīng)用服務(wù)，包括企業(yè)服務(wù)如企業(yè)郵箱、辦公 OA、人力資源系統(tǒng)等，個人服務(wù)如個人郵箱、云筆記、云網(wǎng)盤等。平臺級的 SAAS 應(yīng)用架構(gòu)，實際上是一種多租戶架構(gòu)的升級版，加大了統(tǒng)一身份治理的難度。而基于 UIMS 系統(tǒng)的兩級賬戶體系，可以很容易做到這一點。值得注意的是，有些系統(tǒng)僅提供個人賬戶服務(wù)，有些系統(tǒng)僅提供組織賬戶服務(wù)，有的則兩者都提供，必須處理好個人實體和組織實體之間的關(guān)系。

關(guān)于 SAAS 的介紹，請參考 http://www./blog/2017/07/iaas-paas-saas.html

三）組織實體（Orginization Entity）

在 UIMS 中，組織機(jī)構(gòu)應(yīng)當(dāng)是一種實體，與之對應(yīng)的另一種實體是個人實體。注意實體（Entity）不是賬戶（Account），因此要設(shè)計一種用于組織實體登入受控系統(tǒng)的方法，這里有兩種可選方案：一是增加組織實體賬戶，組織實體自身擁有賬戶，可直接進(jìn)行認(rèn)證登錄；二是將從屬于組織實體的個人賬戶作為組織實體的登入憑證。無論何種方法，在認(rèn)證和授權(quán)時，都應(yīng)當(dāng)向 UIMS 提供統(tǒng)一的標(biāo)準(zhǔn)的賬戶憑證，憑證的規(guī)格由 UIMS 定義，因此，組織實體的認(rèn)證授權(quán)與個人實體的認(rèn)證授權(quán)并無二致。

四）單點登錄（SSO）

企業(yè)平臺涉及眾多子系統(tǒng)，為簡化各子系統(tǒng)的用戶管理，提升用戶體驗，因此實現(xiàn) SSO 是統(tǒng)一身份認(rèn)證的重要目標(biāo)：一次登錄，全部訪問。對于企業(yè)內(nèi)部應(yīng)用來說，SSO 是必須的選項，例如企業(yè) OA、HR、CRM 等內(nèi)部系統(tǒng)；對于外部應(yīng)用來說，SSO 是可選項，具體哪個應(yīng)用應(yīng)當(dāng)加入 SSO 系統(tǒng)，由該業(yè)務(wù)系統(tǒng)決定，例如外部商城、物業(yè)系統(tǒng)等對外服務(wù)系統(tǒng)。無論何種應(yīng)用是否采用 SSO，UIMS 在技術(shù)上應(yīng)當(dāng)具備 SSO 的能力。

關(guān)于SSO的介紹，請參考 https://www.cnblogs.com/EzrealLiu/p/5559255.html

五）授權(quán)登錄

隨著平臺業(yè)務(wù)的逐漸增長，依托于平臺的，和平臺依托的廠商和客戶等資源將極大的豐富平臺，因此必須構(gòu)筑開放的生態(tài)系統(tǒng)，以支撐業(yè)務(wù)的進(jìn)一步發(fā)展。必須開放平臺級的授權(quán)登錄功能，以允許第三方應(yīng)用接入。通過三方授權(quán)登錄，將平臺的服務(wù)各能力開發(fā)給第三方，并將第三方的服務(wù)和能力接入平臺，繁榮共生，共同發(fā)展。

六）服務(wù)間鑒權(quán)

業(yè)務(wù)系統(tǒng)切分出不同的服務(wù)，根據(jù)粒度粗細(xì)和業(yè)務(wù)需求不同，服務(wù)的數(shù)量和權(quán)限要求都不同。微服務(wù)架構(gòu)下的身份認(rèn)證和授權(quán)，可分為兩種：

• 內(nèi)部服務(wù)的認(rèn)證和授權(quán)；
• 外部服務(wù)的認(rèn)證和授權(quán)。

通常，內(nèi)部服務(wù)處于安全的內(nèi)網(wǎng)環(huán)境之下，例如鑒權(quán)服務(wù)、商品服務(wù)、訂單服務(wù)等，在對安全需求不高的情況下，可不執(zhí)行認(rèn)證過程，服務(wù)與服務(wù)之間是相互信任的。

而外部服務(wù)的認(rèn)證和授權(quán)，通常由外部應(yīng)用發(fā)起，通過反向代理或網(wǎng)關(guān)向安全邊界內(nèi)的服務(wù)發(fā)起請求，因此必須執(zhí)行嚴(yán)格的認(rèn)證過程。無線端APP、Web端、桌面客戶端等外部應(yīng)用下的各類服務(wù)，都屬于外部服務(wù)。

服務(wù)間鑒權(quán)示意圖

七）賬號登出和銷毀

與 SSO 相對應(yīng)，UIMS 應(yīng)該支持一次登出，全部登出，即 SSOff（Single Sign-Off，非標(biāo)準(zhǔn)術(shù)語）；或者一次登出，部分登出，而是否全部登出或部分登出取決于用戶的選擇，例如用戶在 Web 端登出后，是否無線端 APP 也登出，這取決于用戶偏好，但系統(tǒng)應(yīng)當(dāng)提供這種能力。

此外，必須提供統(tǒng)一的銷毀功能，以支持用戶刪除其賬戶，一次銷毀，全部銷毀。

八）付費(fèi)授權(quán)

云平臺應(yīng)具備付費(fèi)授權(quán)機(jī)制，針對用戶賬戶和組織賬戶進(jìn)行獨(dú)立授權(quán)。根據(jù)產(chǎn)品的商業(yè)策略，可執(zhí)行靈活的付費(fèi)模式:

• 時效限制:年付、季付、月付，不同時效費(fèi)用不同；
• 功能限制:授權(quán)不同的功能，費(fèi)用不同；
• 數(shù)量限制:最大組織數(shù)量限制、最大用戶數(shù)量限制，不同的數(shù)量費(fèi)用不同。

四、技術(shù)方案

一）備選方案

上文基于『統(tǒng)一身份治理』的理念，提出了統(tǒng)一身份管理系統(tǒng)（UIMS）下關(guān)于身份認(rèn)證和授權(quán)部分的主要需求。目前實現(xiàn)統(tǒng)一身份認(rèn)證和授權(quán)的技術(shù)手段較多，總體可以歸納為以下兩類：

1. 傳統(tǒng)的 Cookie + Session 解決方案，有狀態(tài)會話模式；
2. 基于令牌/票據(jù)的解決方案，無狀態(tài)交互模式。

具體有：

• 分布式 Session
• OAuth2.0
• JWT
• CAS

上述方案各有利弊：

• 分布式 Session 是老牌的成熟解決方案，但因其狀態(tài)化通信的特性與微服務(wù)提倡的API導(dǎo)向無狀態(tài)通信相互違背，且共享式存儲存在安全隱患，因此微服務(wù)一般不太采用。

• OAuth2.0 是業(yè)內(nèi)成熟的授權(quán)登錄解決方案，然而 OA2.0 提供了4種授權(quán)模式，能夠適應(yīng)多種場景，作為基于令牌的安全系統(tǒng)，可以廣泛用于需要統(tǒng)一身份認(rèn)證和授權(quán)的場景。

關(guān)于 OAuth2.0 的介紹，請參考 http://www./blog/2014/05/oauth_2_0.html

• JWT（JSON Web Token）是一種簡潔的自包含的 JSON 聲明規(guī)范，因其分散存儲的特點而歸屬于客戶端授權(quán)模式，廣泛用于短期授權(quán)和單點登錄。由于 JWT 信息是經(jīng)過簽名的，可以確保發(fā)送方的真實性，確保信息未經(jīng)篡改和偽造。但由于其自包含的客戶端驗簽特性，令牌一經(jīng)簽發(fā)，即無法撤銷，因此單純采用 JWT 作為統(tǒng)一身份認(rèn)證和授權(quán)方案無法滿足賬號統(tǒng)一登出和銷毀、賬號封禁和解除這幾種類型的需求。

關(guān)于 JWT 的介紹，請參考 http://blog./2015/09/06/understanding-jwt/

• CAS 是時下最成熟的開源單點登錄方案，包含 CAS Server 和 CAS Client 兩部分。CAS Server 是一個 war 包需要獨(dú)立部署，負(fù)責(zé)用戶認(rèn)證；CAS Client 負(fù)責(zé)處理對客戶端受保護(hù)資源的訪問請求，需要認(rèn)證時，重定向到 CAS Server。值得注意的是，CAS 是一個認(rèn)證框架，其本身定義了一套靈活完整的認(rèn)證流程，但其兼容主流的認(rèn)證和授權(quán)協(xié)議如 OAuth2、SAML、OpenID 等，因此一般采用 CAS + OAuth2 的方案實現(xiàn) SSO 和授權(quán)登錄。

關(guān)于 CAS 的介紹，請參考 https://apereo./cas/

在微服務(wù)架構(gòu)下，身份認(rèn)證和用戶授權(quán)通常分離出來成為獨(dú)立的鑒權(quán)服務(wù)。在做技術(shù)選型時，應(yīng)從以下幾點考慮：

1. 滿足 SSO 的技術(shù)需求；
2. 滿足簡便性和安全性的需求；
3. 滿足開放性和擴(kuò)展性的需求。

綜合考慮，推薦采用無狀態(tài) API 模式，其中 OAuth2.0 能夠完全滿足。此外 JWT 除了不能滿足 SSOff 外，其他都能滿足，且是所有方案里最為簡便輕巧的一個，可通過搭配 API 網(wǎng)關(guān)來滿足 SSOff 特性的要求，因此 JWT + API 網(wǎng)關(guān)也是一個推薦的方案。

場景假設(shè)：構(gòu)建基于圖像的物品識別系統(tǒng)（Image-Based Classification System）

為便于理解統(tǒng)一認(rèn)證和授權(quán)方案的細(xì)節(jié)，假定一種場景：團(tuán)隊準(zhǔn)備構(gòu)建一套基于圖像的物品識別系統(tǒng)，允許用戶通過 H5 應(yīng)用或 APP 上傳圖像，系統(tǒng)分析后返回識別結(jié)果；同時期望將此系統(tǒng)開放給社區(qū)和行業(yè)用戶以便商用；最后允許第三方應(yīng)用將自身的功能接入 IBCS 以增強(qiáng)后者的能力。

下圖是該系統(tǒng)的微服務(wù)架構(gòu)圖：

IBCS 微服務(wù)架構(gòu)圖

在微服務(wù)架構(gòu)下，IBCS 分為內(nèi)外兩層，內(nèi)層處于物理內(nèi)網(wǎng)環(huán)境下，也稱為內(nèi)部服務(wù)，外層處于物理外網(wǎng)環(huán)境下，也稱為外部服務(wù)，內(nèi)外通過 API 網(wǎng)關(guān)連接。

• 內(nèi)部服務(wù)：鑒權(quán)服務(wù)、配置服務(wù)、圖像識別服務(wù)屬于內(nèi)部服務(wù)，通常內(nèi)部服務(wù)之間是相互信任的，但在安全要求較高的場景下，內(nèi)部服務(wù)也不能互信。
• 外部服務(wù)：桌面 APP、無線 APP、H5、第三方應(yīng)用屬于外部服務(wù)，外部服務(wù)分為兩種類型：一種是 IBCS 的一部分，如 APP、H5 這些前端應(yīng)用；另一種是 IBCS 之外的第三方應(yīng)用。兩種類型的授權(quán)方式是不一樣的，前者一般采用 OAuth2.0 的密碼模式，后者則采用客戶端模式。

下文將以物品識別系統(tǒng)為例子，介紹這兩種推薦方案：

二）最佳方案： OAuth2.0

1. OAuth2.0 的四種授權(quán)模式

• 授權(quán)碼模式（authorization code）
• 簡化模式（implicit）
• 密碼模式（resource owner password credentials）
• 客戶端模式（client credentials）

其中密碼模式常用于外部服務(wù)的鑒權(quán)，客戶端模式常用于內(nèi)部服務(wù)鑒權(quán)和開放平臺應(yīng)用的授權(quán)，授權(quán)碼模式常用于社會化登錄和 SSO，因此 OAuth2.0 可作為完整的統(tǒng)一身份認(rèn)證和授權(quán)方案。

2. OAuth2.0 的幾種重要角色

必須注意的是，這些角色是相對的概念。

• 客戶端 Client：一般指第三方應(yīng)用程序，例如用 QQ 登錄豆瓣網(wǎng)站，這里的豆瓣網(wǎng)就是 Client；但在微服務(wù)體系里，Client 通常是服務(wù)本身，如 APP 端的注冊登錄服務(wù)；
• 資源所有者 Resource Owner：一般指用戶，例如用 QQ 登錄豆瓣網(wǎng)站，這里的所有者便是用戶；但在微服務(wù)體系里，資源所有者是服務(wù)提供者本身；
• 資源服務(wù)器 Resource Server：一般指資源所有者授權(quán)存放用戶資源的服務(wù)器，例如用 QQ 登錄豆瓣網(wǎng)站，這里的 QQ 就是資源服務(wù)器；但在微服務(wù)體系里，服務(wù)提供者本身便是資源服務(wù)器；
• 授權(quán)服務(wù)器 Authorization Server：一般是指服務(wù)提供商的授權(quán)服務(wù)，例如用 QQ 登錄豆瓣網(wǎng)站，這里的 QQ 便是授權(quán)服務(wù)器；類似地，在微服務(wù)體系里，鑒權(quán)服務(wù)便是授權(quán)服務(wù)器。

3. IBCS 提供哪些功能

1）核心功能，以 API 形式暴露：

2）由 UIMS 提供的功能：

其中，注冊接口、SignUp-Page 和 Login-Page 頁面是非受控接口/頁面，意味著無須鑒權(quán)即可訪問。

SignUp-Page 和 Login-Page 頁面是由 UIMS 提供的統(tǒng)一的注冊和登錄頁面，當(dāng)外部服務(wù)發(fā)起注冊或登錄請求時，有兩種作法：一是統(tǒng)一跳轉(zhuǎn)到 UIMS 的注冊或登錄頁面，用戶完成操作后調(diào)用 UIMS 的注冊和登錄 API 完成請求；二是在自己的注冊和登錄頁面完成操作，然后以用戶名和密碼作為參數(shù)調(diào)用 UIMS 的注冊和登錄 API 完成請求。推薦采用第一種方法，類似于全網(wǎng)通行證，用戶體驗統(tǒng)一，不用重復(fù)開發(fā)注冊登錄頁面。

3）成為開發(fā)者，獲取 IBCS 的能力集：

1. 第一步：申請成為開發(fā)者。開發(fā)者分為個人開發(fā)者和組織開發(fā)者兩類，實名認(rèn)證也分兩種類型進(jìn)行。成為開發(fā)者的前提是成為平臺的注冊用戶；
2. 第二步：創(chuàng)建應(yīng)用，平臺審核通過后，生成 AppId 和 AppSecret 給到開發(fā)者，每個應(yīng)用對應(yīng)一對 AppId 和 AppSecret。值得注意的是，每個 AppID 與用戶賬號是綁定的，因此每個 AppId 獲取資源和能力的權(quán)限受到該用戶賬戶權(quán)限的限制，典型的例子是對象存儲服務(wù)（OSS/OBS）；
3. 第三步：獲取 Access Token，開發(fā)者按照 OAuth2.0 的規(guī)范，采用客戶端（client_credentials）模式，利用申請到的 AppId 和 AppSecret 向 IBCS 申請 token；
4. 第三步：使用 Access Token 與平臺進(jìn)行交互，每次調(diào)用受控 API 時都攜帶此 token。

4）成為開發(fā)者，創(chuàng)建第三方應(yīng)用：

一般來說，應(yīng)當(dāng)獨(dú)立建設(shè)一個開放平臺，開發(fā)平臺作為整個云平臺的一個子系統(tǒng)，同樣依賴于 UIMS。在開放平臺上，應(yīng)當(dāng)提供一套完善的界面和流程，以引導(dǎo)用戶完成開發(fā)者認(rèn)證和第三方應(yīng)用接入的所有工作。此外，在前期階段，也可以采用線下申請的方式，由管理員人工審核，在后臺手動錄入。

在開放平臺上，創(chuàng)建第三方應(yīng)用的流程和步驟，與上一步驟『成為開發(fā)者，獲取 IBCS 的能力集』一致。所不同的是，上個步驟是獲取 IBCS 的能力，而本步驟『創(chuàng)建第三方應(yīng)用』，是基于開放平臺開發(fā)應(yīng)用，類似于微信小程序。

5）成為開發(fā)者，將異構(gòu)系統(tǒng)（第三方應(yīng)用）接入 IBCS：

應(yīng)該允許開發(fā)者將異構(gòu)系統(tǒng)（第三方應(yīng)用）接入 IBCS，以增強(qiáng) IBCS 的能力。例如，假設(shè) IBCS 本身不具備識別特種汽車的能力，但允許接入其他開發(fā)者開發(fā)的基于圖像的特種汽車識別應(yīng)用。

第三方應(yīng)用接入，歸屬于開放平臺的范疇。接入的流程和步驟，與第三步驟『成為開發(fā)者，獲取 IBCS 的能力集』一致，由開放平臺提供標(biāo)準(zhǔn)的 API，第三方按照接入規(guī)范執(zhí)行。

4. OAuth2.0 四種授權(quán)模式的應(yīng)用場景

5. 客戶端鑒權(quán)和用戶鑒權(quán)

服務(wù)鑒權(quán)，從形式上分為：

1. 非受控服務(wù)/接口，無須鑒權(quán)；
2. 客戶端鑒權(quán)（服務(wù)自身鑒權(quán)）：客戶端（服務(wù)）在訪問另一個服務(wù)時，必須先表明客戶端自己的身份；
3. 業(yè)務(wù)鑒權(quán)（用戶鑒權(quán)）：用戶通過客戶端（服務(wù)）訪問某個資源時，必須驗證用戶自己的身份。

例如，用戶通過 APP 登錄 IBCS 后，訪問圖像識別服務(wù)的過程：用戶登錄后獲得 token，由 APP 攜帶此 token 向圖像識別服務(wù)發(fā)起請求，圖像識別服務(wù)首先調(diào)用鑒權(quán)服務(wù)驗證 APP 的身份（通過 ClientId 和 ClientSecret），然后再驗證用戶的身份（通過 token），如果 APP 和用戶都獲得授權(quán)，則請求通過，返回識別結(jié)果。

6. 跨域問題

瀏覽器的同源策略給 Web 應(yīng)用劃定了安全邊界，是 Web 應(yīng)用安全模型的重要基礎(chǔ)。基于令牌的安全系統(tǒng)，在同源策略的約束下面臨兩個問題：

1. 跨域請求；
2. SSO 登錄狀態(tài)的跨域保持。

1）CORS 方案

第一個問題，一般采用 CORS 方案，在服務(wù)端的響應(yīng)頭聲明 Access-Control-Allow-Origin 參數(shù)即可解決跨域請求的問題。

2）同域 SSO 方案

第二個問題，在同域環(huán)境下，傳統(tǒng)方法是采用 Cookie 的方案?？缬颦h(huán)境下，也有幾種方案，從安全性和簡便性考慮，推薦采用這種方案：

• 根據(jù)業(yè)務(wù)需求將應(yīng)用切分為同域 SSO 應(yīng)用和跨域 SSO 應(yīng)用兩類；
• 將需要 SSO 狀態(tài)保持的應(yīng)用歸到同域 SSO 應(yīng)用中，將其他應(yīng)用歸到跨域 SSO 應(yīng)用中；
• 對于同域 SSO 應(yīng)用，一般是企業(yè)內(nèi)部應(yīng)用，或相關(guān)性較高的應(yīng)用，這些應(yīng)用的域名采用相同的父級域名，繼續(xù)使用 Cookie 方案；
• 對于跨域 SSO 應(yīng)用，不提供 SSO 狀態(tài)保持。當(dāng)用戶首次打開此類應(yīng)用時，由于 Cookie 無法跨域，因此服務(wù)端無法感知用戶的登錄狀態(tài)，此時用戶是處于未登錄狀態(tài)的；當(dāng)用戶訪問受控頁面或點擊登錄頁面時，須重新執(zhí)行登錄操作。

7. 登出和關(guān)閉賬戶

OAuth2.0 是集中式的令牌安全系統(tǒng)，可以通過撤銷令牌登出系統(tǒng)。關(guān)閉賬戶與此類似。

8. 軟件授權(quán)

可在鑒權(quán)服務(wù)或 API 網(wǎng)關(guān)增加規(guī)則過濾器，將商業(yè)授權(quán)策略應(yīng)用到授權(quán)規(guī)則中。

9. 技術(shù)選型

后續(xù)會寫實踐篇，敬請期待……

三）第二方案：JWT + API 網(wǎng)關(guān)

JWT 是一種自包含的客戶端令牌系統(tǒng)技術(shù)規(guī)范，這是其與 OAuth2.0 最大的不同。除此之外，可以簡單地將 JWT 當(dāng)作 OAuth2.0 密碼模式的半自動版本。在實施 JWT 方案時，大部分情況下與 OAuth2.0 基本一致，本文不重復(fù)闡述，只對幾個要點和不同之處加以說明。

1. 搭配 API 網(wǎng)關(guān)實現(xiàn)令牌撤銷

由于 JWT 屬于自包含的客戶端令牌系統(tǒng)，令牌發(fā)出后無須服務(wù)器驗證，只需在客戶端驗證?？蛻舳蓑炞C并解簽后將得到必要的信息，例如用戶基本信息和權(quán)限標(biāo)識符。這種設(shè)計天然地存在無法撤銷令牌的問題。解決方案是在 API 網(wǎng)關(guān)對 JWT 進(jìn)行攔截，這里有多種方法：

1. 令牌撤銷由 UIMS 發(fā)出，經(jīng)由消息隊列、API 等手段通知到網(wǎng)關(guān)，網(wǎng)關(guān)維護(hù)一個已撤銷令牌的黑名單，對所有經(jīng)過網(wǎng)關(guān)的 JWT 進(jìn)行比對，TRUE 則拒絕轉(zhuǎn)發(fā)，并返回 401；
2. 令牌撤銷由 UIMS 執(zhí)行后，網(wǎng)關(guān)每次收到 JWT 請求時，查詢令牌數(shù)據(jù)庫（如 Redis），比對該令牌是否已經(jīng)撤銷，如已撤銷則返回 401。

不過此方案仍然存在兩個問題：

1. 將一定程度喪失 JWT 客戶端解簽的優(yōu)勢，但相較于傳統(tǒng)的 Cookie + Session 方案，此方案更加輕巧，也更加符合微服務(wù)無狀態(tài) API 的風(fēng)格；
2. 對于已發(fā)出的令牌，客戶端在下一次請求之前，服務(wù)端的令牌系統(tǒng)對此沒有控制能力，例如 SSOff 將無法很好地實現(xiàn)。

2. 客戶端鑒權(quán)和用戶鑒權(quán)

與 OAuth2.0 方案一致，客戶端同樣需要使用 ClientId 和 ClientSecret 鑒權(quán)。

3. 公鑰和密鑰

JWT 規(guī)定采用非對稱加密算法對 Header 和 Payload 進(jìn)行簽名。

1）非對稱算法

非對稱算法的重要特點是，使用密鑰加密時，必須用公鑰解密；用公鑰加密時，必須用密鑰解密。利用此特性，通常在服務(wù)端采用密鑰加密信息，然后客戶端采用公鑰解密信息。由于密鑰存儲在服務(wù)端，因此安全性高；公鑰本身可以公開，因此可以在客戶端存儲。

2）公鑰解密

JWT 經(jīng)由服務(wù)端用密鑰加密后，發(fā)往客戶端，客戶端使用公鑰進(jìn)行解密，便得到了 JWT 的明文。JWT 包含了豐富的信息（通常是用戶基本信息和權(quán)限標(biāo)識符），只要解密成功，客戶端完全可以信任此 JWT，因此不必再依賴于服務(wù)端重復(fù)鑒權(quán)。

4. 服務(wù)間鑒權(quán)

1）內(nèi)部服務(wù)鑒權(quán)

以 IBCS 為例，當(dāng)圖像識別服務(wù)服務(wù)攜帶 JWT 向配置服務(wù)請求資源時，配置服務(wù)使用公鑰解密，只要解密成功，配置服務(wù)完全可以信任圖像識別服務(wù)，因此也不必再依賴于鑒權(quán)服務(wù)的重復(fù)鑒權(quán)。對于安全性要求不高的場景，也可以使用 HTTP Basic 驗證進(jìn)行簡單鑒權(quán)。

2）外部服務(wù)鑒權(quán)

同樣，當(dāng)外部的 APP 攜帶 JWT 向內(nèi)網(wǎng)的圖像識別服務(wù)發(fā)起請求時，圖像識別服務(wù)使用公鑰解密，只要解密成功，圖像識別服務(wù)完全可以信任該 APP，有所不同的是，外部服務(wù)向內(nèi)網(wǎng)服務(wù)發(fā)起請求，必須經(jīng)過 API 網(wǎng)關(guān)，由網(wǎng)關(guān)執(zhí)行規(guī)則過濾，確保 JWT 是仍處于有效狀態(tài)。

5. 跨域問題

與 OAuth2.0 的跨域解決方案一致。

五、總結(jié)

本文給出了微服務(wù)架構(gòu)下的統(tǒng)一身份認(rèn)證和授權(quán)的設(shè)計方案，從平臺級 SAAS 模式下『統(tǒng)一身份治理』的概念出發(fā)，梳理了關(guān)鍵的需求點，提出了對應(yīng)的解決方案。其中 OAuth2.0 是最佳解決方案，不過在實際運(yùn)用中，應(yīng)當(dāng)遵循『合適原則』、『簡單原則』和『演化原則』三個原則，不能盲目照搬。

六、參考鏈接

1. SAAS，http://www./blog/2017/07/iaas-paas-saas.html
2. SSO， https://www.cnblogs.com/EzrealLiu/p/5559255.html
3. CAS， https://apereo./cas/
4. UIMS， https:///平臺級SAAS架構(gòu)的基礎(chǔ)-統(tǒng)一身份管理系統(tǒng).html