企業(yè)級(jí)微服務(wù)架構(gòu)統(tǒng)一安全認(rèn)證設(shè)計(jì)與實(shí)踐！

來(lái)源：mars | https://juejin.cn/post/6906149001520037902

名詞定義

• Third-party application：第三方應(yīng)用程序，本文中又稱(chēng)"客戶(hù)端"（client）。

• HTTP service：HTTP服務(wù)提供商，本文中簡(jiǎn)稱(chēng)"服務(wù)提供商"。

• Resource Owner：資源所有者，本文中又稱(chēng)"用戶(hù)"（user）,即登錄用戶(hù)。

• User Agent：用戶(hù)代理，本文中就是指瀏覽器。

• Authorization server：認(rèn)證服務(wù)器，即服務(wù)提供商專(zhuān)門(mén)用來(lái)處理認(rèn)證的服務(wù)器。

• Resource server：資源服務(wù)器，即服務(wù)提供商存放用戶(hù)生成的資源的服務(wù)器。它與認(rèn)證服務(wù)器，可以是同一臺(tái)服務(wù)器，也可以是不同的服務(wù)器。

研發(fā)背景

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

單體應(yīng)用體系下，應(yīng)用是一個(gè)整體，一般針對(duì)所有的請(qǐng)求都會(huì)進(jìn)行權(quán)限校驗(yàn)。請(qǐng)求一般會(huì)通過(guò)一個(gè)權(quán)限的攔截器進(jìn)行權(quán)限的校驗(yàn)，在登錄時(shí)將用戶(hù)信息緩存到 session
中，后續(xù)訪(fǎng)問(wèn)則從緩存中獲取用戶(hù)信息。

隨著 Restful API、微服務(wù)的興起，基于 Token 的認(rèn)證現(xiàn)在已經(jīng)越來(lái)越普遍。Token 和 Session ID 不同，并非只是一個(gè)
key。Token 一般會(huì)包含用戶(hù)的相關(guān)信息，通過(guò)驗(yàn)證 Token 就可以完成身份校驗(yàn)。

基于 Token 認(rèn)證的優(yōu)勢(shì)如下：

1. 服務(wù)端無(wú)狀態(tài)：Token 機(jī)制在服務(wù)端不需要存儲(chǔ) session 信息，因?yàn)?Token 自身包含了所有用戶(hù)的相關(guān)信息。

2. 性能較好，因?yàn)樵隍?yàn)證 Token 時(shí)不用再去訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)或者遠(yuǎn)程服務(wù)進(jìn)行權(quán)限校驗(yàn)，自然可以提升不少性能。

3. 支持移動(dòng)設(shè)備,支持跨程序調(diào)用，Cookie 是不允許垮域訪(fǎng)問(wèn)的，而 Token 則不存在這個(gè)問(wèn)題。

研發(fā)目標(biāo)

通過(guò)標(biāo)準(zhǔn)安全認(rèn)證流程，異構(gòu)系統(tǒng)或跨服務(wù)間能夠靈活地實(shí)現(xiàn)指定功能部件或服務(wù)的集成、統(tǒng)一的安全認(rèn)證。

• 基于 Token 認(rèn)證的一個(gè)典型流程如下：

1. 用戶(hù)輸入登錄信息（或者調(diào)用 Token 接口，傳入用戶(hù)信息），發(fā)送到身份認(rèn)證服務(wù)進(jìn)行認(rèn)證（身份認(rèn)證服務(wù)可以和服務(wù)端在一起，也可以分離，看微服務(wù)拆分情況了）。

2. 身份驗(yàn)證服務(wù)驗(yàn)證登錄信息是否正確，返回接口（一般接口中會(huì)包含用戶(hù)基礎(chǔ)信息、權(quán)限范圍、有效時(shí)間等信息），客戶(hù)端存儲(chǔ)接口，可以存儲(chǔ)在 Session 或者數(shù)據(jù)庫(kù)中。

3. 客戶(hù)端將 Token 放在 HTTP 請(qǐng)求頭中，發(fā)起相關(guān) API 調(diào)用。

4. 被調(diào)用的微服務(wù)，驗(yàn)證 Token 權(quán)限。

5. 服務(wù)端返回相關(guān)資源和數(shù)據(jù)。

安全認(rèn)證功能點(diǎn)

1. 獲取憑證, 第三方應(yīng)用客戶(hù)端使用客戶(hù)端編碼/安全碼、資源所有者用戶(hù)名/密碼等證件信息從授權(quán)服務(wù)器上獲取Access Token資源訪(fǎng)問(wèn)憑證。

2. 登錄授權(quán)，客戶(hù)端攜帶Access Token憑證訪(fǎng)問(wèn)服務(wù)器資源，資源服務(wù)器驗(yàn)證Token、第三方應(yīng)用憑證信息、資源所有者User合法性，通過(guò)Token讀取資源所有者身份信息(user) 加載資源所有者的權(quán)限項(xiàng)執(zhí)行登錄。

3. 訪(fǎng)問(wèn)鑒權(quán)，第三方應(yīng)用客戶(hù)端訪(fǎng)問(wèn)服務(wù)端資源，系統(tǒng)驗(yàn)證訪(fǎng)問(wèn)者Access Token合法性、權(quán)限信息，驗(yàn)證憑證（Access Token）正確，此時(shí)資源服務(wù)器就會(huì)返回資源信息。

4. 憑證續(xù)約，Access token訪(fǎng)問(wèn)憑證過(guò)期需要進(jìn)行憑證續(xù)約，刷新Token憑證有效期。

技術(shù)選型分析

1. 系統(tǒng)授權(quán)采用OAuth2開(kāi)放式授權(quán)標(biāo)準(zhǔn)密碼模式。

2. Token采用JWT標(biāo)準(zhǔn)。

1. OAuth開(kāi)放授權(quán)

OAuth（Open Authorization，開(kāi)放授權(quán)）是為用戶(hù)資源的授權(quán)定義了一個(gè)安全、開(kāi)放及簡(jiǎn)單的標(biāo)準(zhǔn)，第三方無(wú)需知道用戶(hù)的賬號(hào)及密碼，就可獲取到用戶(hù)的授權(quán)信息。

主要的四種授權(quán)方式：

• 授權(quán)碼模式（authorization code）用在客戶(hù)端與服務(wù)端應(yīng)用之間授權(quán)碼。

• 簡(jiǎn)化模式（implicit）用在移動(dòng)app或者web app(這些app是在用戶(hù)的設(shè)備上的，如在手機(jī)上調(diào)起微信來(lái)進(jìn)行認(rèn)證授權(quán))。不通過(guò)第三方應(yīng)用程序的服務(wù)器，直接在瀏覽器中向認(rèn)證服務(wù)器申請(qǐng)令牌，跳過(guò)了"授權(quán)碼"這個(gè)步驟，因此得名。所有步驟在瀏覽器中完成，令牌對(duì)訪(fǎng)問(wèn)者是可見(jiàn)的，且客戶(hù)端不需要認(rèn)證。

• 密碼模式（resource owner password credentials）應(yīng)用直接都是受信任的(都是由一家公司開(kāi)發(fā)的)密碼模式中，用戶(hù)向客戶(hù)端提供自己的用戶(hù)名和密碼。客戶(hù)端使用這些信息，向"服務(wù)商提供商"索要授權(quán)。在這種模式中，用戶(hù)必須把自己的密碼給客戶(hù)端，但是客戶(hù)端不得儲(chǔ)存密碼。

• 客戶(hù)端模式（client credentials）用在應(yīng)用API訪(fǎng)問(wèn)客戶(hù)端模式（Client Credentials Grant）指客戶(hù)端以自己的名義，而不是以用戶(hù)的名義，向"服務(wù)提供商"進(jìn)行認(rèn)證。嚴(yán)格地說(shuō)，客戶(hù)端模式并不屬于OAuth框架所要解決的問(wèn)題。在這種模式中，用戶(hù)直接向客戶(hù)端注冊(cè)，客戶(hù)端以自己的名義要求"服務(wù)提供商"提供服務(wù)，其實(shí)不存在授權(quán)問(wèn)題。

2. Json web token (JWT)

Json web token (JWT), 是為了在網(wǎng)絡(luò)應(yīng)用環(huán)境間傳遞聲明而執(zhí)行的一種基于JSON的開(kāi)放標(biāo)準(zhǔn)（(RFC
7519).該token被設(shè)計(jì)為緊湊且安全的，特別適用于分布式站點(diǎn)的單點(diǎn)登錄（SSO）場(chǎng)景。JWT的聲明一般被用來(lái)在身份提供者和服務(wù)提供者間傳遞被認(rèn)證的用戶(hù)身份信息，以便于從資源服務(wù)器獲取資源，也可以增加一些額外的其它業(yè)務(wù)邏輯所必須的聲明信息，該token也可直接被用于認(rèn)證，也可被加密。

認(rèn)證流程邏輯

1. 系統(tǒng)授權(quán)

第三方應(yīng)用客戶(hù)端使用客戶(hù)端編碼/安全碼、資源所有者用戶(hù)名/密碼等證件信息從授權(quán)服務(wù)器上獲取Access Token資源訪(fǎng)問(wèn)憑證。

系統(tǒng)授權(quán)頒發(fā)給客戶(hù)應(yīng)用Access Token

2. 系統(tǒng)鑒權(quán)

客戶(hù)端攜帶Access
Token憑證訪(fǎng)問(wèn)服務(wù)器資源，資源服務(wù)器驗(yàn)證Token、第三方應(yīng)用、資源所有者User合法性，通過(guò)Token讀取資源所有者身份信息(user)
加載資源所有者的權(quán)限執(zhí)行登錄。

系統(tǒng)驗(yàn)證訪(fǎng)問(wèn)者Access Token合法性、權(quán)限信息，驗(yàn)證憑證（Access Token）正確，此時(shí)資源服務(wù)器就會(huì)返回資源信息。

3. 憑證續(xù)約

Access token訪(fǎng)問(wèn)憑證過(guò)期需要進(jìn)行憑證續(xù)約，刷新Token憑證有效期。

接口設(shè)計(jì)

1. 授權(quán)憑證

獲取授權(quán)憑證，校驗(yàn)客戶(hù)端身份信息、校驗(yàn)資源所有者身份信息，下發(fā)Token憑證。

客戶(hù)端編碼/安全碼需要第三方應(yīng)用到系統(tǒng)注冊(cè)審核通過(guò)后生成。

2. 授權(quán)憑證續(xù)約

獲取續(xù)約授權(quán)憑證，校驗(yàn)客戶(hù)端身份信息、校驗(yàn)RefreshToken憑證，下發(fā)Token憑證。