在微服務(wù)架構(gòu)中，有一個(gè)核心的問題是處理好“集權(quán)”(中心化)和“放權(quán)”(去中心化)的關(guān)系。雖然微服務(wù)的主旋律是把數(shù)據(jù)和業(yè)務(wù)拆成小而獨(dú)立的模塊，但我們?nèi)匀恍枰粋€(gè)強(qiáng)力的中央安保體系來確保“數(shù)據(jù)分散，權(quán)限集中”。這一篇就談?wù)勎⒎?wù)架構(gòu)中的鑒權(quán)體系。

身份認(rèn)證

身份認(rèn)證(Authentication)的目的是證明“你是你(所號(hào)稱的那個(gè)人)”。

要證明這一點(diǎn)，你必須掌握一個(gè)只有你自己和認(rèn)證機(jī)構(gòu)才知道的機(jī)密信息。在現(xiàn)實(shí)中，這個(gè)信息可能是 DNA、指紋、虹膜這樣的生物識(shí)別特征，但由于這種特征跟人身直接綁定且又不可修改，一旦泄露，可能被持續(xù)冒用，造成不可挽回的嚴(yán)重后果，所以現(xiàn)實(shí)中較少采用這些生物識(shí)別特征作為識(shí)別之用。

如果不采用機(jī)密信息作為判斷標(biāo)準(zhǔn)，就需要一個(gè)持續(xù)的、不易偽造的“證明材料”。在中國(guó)，這個(gè)證明材料就是戶口或身份證。中國(guó)對(duì)公民信息的登記相對(duì)嚴(yán)格，所以會(huì)在小孩出生的時(shí)候要求把身份信息登記到戶口之中，形成身份證明，跟隨一生。在需要證明“你是你”的時(shí)候，拿出身份證就行了。

[[216641]]

(生物特征不可廢棄，所以我們必須把它包一層，形成證明材料和對(duì)應(yīng)的 Persona)

與生物識(shí)別特征不同的是，身份證如果丟失，從理論上說，應(yīng)該可以掛失并且讓其失效，然后辦理一張新的身份證。不過，設(shè)計(jì)我國(guó)身份證的機(jī)構(gòu)和供應(yīng)商也許沒有考慮到這個(gè)問題，或者考慮到現(xiàn)實(shí)情況太復(fù)雜，導(dǎo)致身份證無法掛失，丟失的身份證仍然具備證明效力，但這個(gè)是后話了。

為了避免身份證被冒用，在對(duì)身份認(rèn)證要求比較嚴(yán)格的場(chǎng)合(比如銀行)，會(huì)附加一些別的檢查，比如對(duì)比照片等等。

那么，現(xiàn)在我們來對(duì)身份認(rèn)證進(jìn)行規(guī)劃。

• 身份認(rèn)證機(jī)構(gòu)可以頒發(fā)兩個(gè)東西給用戶，作為身份認(rèn)證的輸入：機(jī)密信息或證明材料。
• 身份認(rèn)證機(jī)構(gòu)可以通過對(duì)比用戶提交和機(jī)構(gòu)保存的機(jī)密信息來判斷用戶身份。
• 身份認(rèn)證機(jī)構(gòu)可以通過檢查和對(duì)比用戶提交的證明材料來判斷用戶身份。
• 如果需要，身份認(rèn)證機(jī)構(gòu)可能會(huì)附加別的驗(yàn)證來增加認(rèn)證可信度。
• 用戶可以變更機(jī)密信息，避免冒用。
• 用戶可以掛失證明材料，使證明材料失效，避免冒用。

身份認(rèn)證中的機(jī)密信息在 Web 環(huán)境中通常以用戶名和密碼的形式存在。由于 HTTP 協(xié)議沒有“狀態(tài)”的概念，所以對(duì)于 Web 服務(wù)器來說，每次請(qǐng)求都是全新的體驗(yàn)，都必須驗(yàn)明請(qǐng)求者的正身。要做到這一點(diǎn)，客戶端可以在每次請(qǐng)求的時(shí)候都附上用戶名和密碼(或者別的憑據(jù))，表明身份。

可是，每次都發(fā)送用戶名和密碼增加了泄露風(fēng)險(xiǎn)，所以在第一次驗(yàn)明正身(登錄)之后，服務(wù)器可以發(fā)給調(diào)用者一個(gè)“令牌”(Token)。這樣，后端的后續(xù)身份認(rèn)證，無外乎就是把令牌換成“身份”(Identity)。這個(gè)令牌實(shí)際上就是前面說的證明材料。

我們應(yīng)該盡量讓令牌不容易仿造，但是技術(shù)上無法做到完全杜絕。所以，在敏感操作的時(shí)候可能會(huì)附加一些別的驗(yàn)證，比如再次輸入密碼或者用短信驗(yàn)證碼做二次校驗(yàn)，這也就是前面所說的附加驗(yàn)證。

權(quán)限驗(yàn)證

和身份認(rèn)證相比，權(quán)限驗(yàn)證(Authorization)要復(fù)雜一些。

身份認(rèn)證的輸入，要么是用戶名和密碼(或別的身份憑據(jù))，要么是令牌，只需要通過一個(gè)檢查，就能輸出身份信息。而權(quán)限的驗(yàn)證要檢查的是“某用戶能不能做某事情”，所以，至少需要有兩個(gè)輸入：“用戶身份”和“想要執(zhí)行的動(dòng)作”。除了這兩個(gè)輸入之外，還需要有一個(gè)具體的“判斷規(guī)則”，驗(yàn)證者才能根據(jù)規(guī)則，輸出“同意”或者“拒絕”。

在現(xiàn)實(shí)中，這個(gè)判斷規(guī)則有很多種可能。

• 在等級(jí)森嚴(yán)的軍隊(duì)里面，所有的動(dòng)作和文檔都有明確的“查閱級(jí)別”，而每個(gè)人也有自己的“查閱級(jí)別”。只有用戶的級(jí)別高于動(dòng)作的級(jí)別，才能執(zhí)行這個(gè)動(dòng)作。
• 在分工明確的工廠里面，每個(gè)人都只負(fù)責(zé)自己的工作，那么，所有的動(dòng)作和資源都按照不同的工種來進(jìn)行分配。各工種只能執(zhí)行屬于自己負(fù)責(zé)范圍的動(dòng)作，獲取屬于自己負(fù)責(zé)范圍的資源。
• 在架構(gòu)明確的公司里面，每個(gè)人都屬于公司行政架構(gòu)中的一個(gè)節(jié)點(diǎn)，可以執(zhí)行屬于這個(gè)節(jié)點(diǎn)的動(dòng)作，并且訪問這個(gè)節(jié)點(diǎn)及其下屬節(jié)點(diǎn)的信息。

在專家主導(dǎo)的醫(yī)院里面，所有人都圍繞專家的需要服務(wù)，而專家則為病人服務(wù)(執(zhí)業(yè))。根據(jù)專家的需要，同時(shí)保護(hù)敏感信息，我們可能會(huì)設(shè)置更加復(fù)雜的判斷規(guī)則，比如根據(jù)時(shí)間段、服務(wù)流程階段等來判斷，或者提供一個(gè)特定的委托授權(quán)的流程用于臨時(shí)開放權(quán)限。

不管怎么變，只要有了身份、動(dòng)作和規(guī)則，我們就能做判斷。當(dāng)然，如果規(guī)則要求我們核實(shí)部分?jǐn)?shù)據(jù)，我們還需要這部分的數(shù)據(jù)作輸入。不過，由誰(shuí)來執(zhí)行這個(gè)判斷比較合適，值得我們探討一下。

舉一個(gè)生活中的例子。

有這么一家公司，在 A 市有個(gè)辦公室，辦公室有個(gè)戴經(jīng)理。戴經(jīng)理有一天興之所至，想起來要查一下員工老王的工資。他來到了 HR 部門，找到了 HR 主管，想要調(diào)老王的工資出來看看。

HR 看了看公司規(guī)定，經(jīng)理只能看自己所轄辦公室的員工工資，然后又看了看戴經(jīng)理，是負(fù)責(zé)成都的，再看看老王，是成都員工，然后，就把老王的工資調(diào)出來給了戴經(jīng)理。戴經(jīng)理看了，然后說，再給我看看老陳的工資啊。然后 HR 調(diào)出檔案一看，老陳是北京辦公室的，就拒絕了。

又有一天，員工老王也興之所至，想要查一下戴經(jīng)理的工資。他也來到 HR 部門，找到 HR 主管，問戴經(jīng)理的工資。HR 一看，你這不是經(jīng)理啊，怎么能查別人工資呢，就直接拒絕了。

如果看這個(gè)例子，我們就會(huì)發(fā)現(xiàn)，這個(gè)規(guī)則的檢查是 HR 做的。實(shí)際上，絕大部分非 IT 的業(yè)務(wù)流程中，權(quán)限的檢查都由信息的保管方來執(zhí)行。

我們當(dāng)然也可以按照這個(gè)來建模，但是稍等，再深入分析一下。

• 首先，“誰(shuí)能看誰(shuí)的工資”這個(gè)規(guī)則，是不是 HR 部門來決定的呢?不是。公司的規(guī)章制度決定了“誰(shuí)能看誰(shuí)的工資”，規(guī)章制度由公司管理者制定。
• 然后，當(dāng)公司制度需要調(diào)整的時(shí)候，是不是由 HR 部門來調(diào)整呢?不是。 還是由管理者來制定，然后由各個(gè)部門來執(zhí)行。各個(gè)部門實(shí)際上是收到了制度調(diào)整的結(jié)果，而不是自己去調(diào)整制度。
• 最后，“誰(shuí)能看誰(shuí)的工資”這個(gè)規(guī)則，是不是 HR 的專業(yè)范圍?不是。只有“調(diào)出工資檔案”這個(gè)動(dòng)作是 HR 的專業(yè)范圍，至于“誰(shuí)能看”，其實(shí)跟 HR 的專業(yè)知識(shí)沒有直接關(guān)系。

[[216642]]

要理解最后這一點(diǎn)，我們可以看兩個(gè)場(chǎng)景。

• 某 HR 換了一家新公司?，F(xiàn)在這個(gè)新的公司很有意思，允許所有人看所有人的工資，層級(jí)也不同，規(guī)章完全不同，但 HR 仍然可以按照自己的專業(yè)來工作不受影響。不只是 HR，對(duì)其他部門的人來說也是如此。規(guī)章制度的變化，對(duì)它們的職責(zé)沒有實(shí)質(zhì)的影響。
• 某 HR 換了一家新公司。這家公司專門搞高精尖的研究，對(duì)于員工的信息和商業(yè)機(jī)密控制極其嚴(yán)格。只要有人來調(diào)取數(shù)據(jù)，都必須經(jīng)過專門的審核人員審核放行。這對(duì) HR 的職責(zé)也沒有實(shí)質(zhì)影響，只要能通過審核，照辦即可。審核人員也不知道 HR 具體的工作是什么，只知道規(guī)則要求檢查什么，就去檢查什么。

總結(jié)就是以下幾點(diǎn)。

• 專業(yè)知識(shí)(領(lǐng)域邏輯、業(yè)務(wù)規(guī)則)和權(quán)限是相對(duì)獨(dú)立的東西。
• 要運(yùn)用專業(yè)知識(shí)，不需要知道權(quán)限。
• 要檢查權(quán)限，不需要用到專業(yè)知識(shí)。

既然如此，為什么在現(xiàn)實(shí)中還是由專業(yè)人士來兼職檢查權(quán)限呢?這也許是因?yàn)閷?duì)于很多公司來說，絕大部分的數(shù)據(jù)都沒有那么敏感，所以為了降低管理成本，絕大部分的數(shù)據(jù)訪問都沒有那么嚴(yán)格地用專職人員去檢查，而是由專業(yè)人士代勞。

了解了這些之后，我們就可以開始規(guī)劃了。

• 權(quán)力機(jī)構(gòu)會(huì)制定一套權(quán)限規(guī)則，并且可能調(diào)整這套規(guī)則。
• 這套規(guī)則可能會(huì)用到一些外部的輸入，比如員工所在的辦公室。
• 有了這套規(guī)則和查驗(yàn)數(shù)據(jù)的權(quán)力，任何人都可以判斷一個(gè)動(dòng)作是否合規(guī)。

這樣做的好處，就是業(yè)務(wù)變得非常純粹，而權(quán)限相關(guān)的東西完全挪出業(yè)務(wù)層面，即便業(yè)務(wù)或者權(quán)限需要頻繁變化，問題也不大。

說到這里，也順便拋一個(gè)待驗(yàn)證的設(shè)想：不同公司的業(yè)務(wù)邏輯總是高度雷同，差別最大(妨礙復(fù)用)的其實(shí)是公司的管理體系。我們把組織結(jié)構(gòu)和與之相關(guān)的安全權(quán)限單獨(dú)拎出來，也許可以更好地促進(jìn)業(yè)務(wù)邏輯的復(fù)用。

鑒權(quán)服務(wù)

為了提升服務(wù)的效率，我們一般會(huì)希望盡早地做完身份認(rèn)證和權(quán)限驗(yàn)證。如果用戶執(zhí)行了越權(quán)操作，那我們應(yīng)該及早中止訪問并返回錯(cuò)誤提示。

前面提到，權(quán)限驗(yàn)證的輸入之一是用戶身份，所以身份認(rèn)證和權(quán)限驗(yàn)證通常是前后腳來做。二者組合，形成鑒權(quán)服務(wù)(Auth Service)。鑒權(quán)服務(wù)負(fù)責(zé)維護(hù)令牌身份映射以及權(quán)限規(guī)則，它的輸入是“令牌”和“想執(zhí)行的動(dòng)作”，輸出是“身份”和“是否允許執(zhí)行”。

幾個(gè)例子

現(xiàn)在，我們用這樣一個(gè)場(chǎng)景來實(shí)驗(yàn)一下整個(gè)鑒權(quán)流程。

設(shè)有這么一個(gè)訂單管理系統(tǒng)，其中有一個(gè)訂單查詢功能。其權(quán)限要求如下。

• 買家只能看到自己下的訂單
• 賣家只能看到下給自己的訂單
• 賣家管轄多個(gè)小二，小二可以分組給不同的權(quán)限，有的只能看分配給自己的訂單，有的可以查看分配到自己組的訂單
• 運(yùn)營(yíng)商可以看到所有訂單

要對(duì)這個(gè)權(quán)限體系進(jìn)行建模，我們必須認(rèn)識(shí)到，這些操作，雖然查看的都是訂單，但是因?yàn)槭遣煌臉I(yè)務(wù)上下文，表現(xiàn)到 API 呈現(xiàn)上也會(huì)有不同。

• 買家看自己的訂單：/CustomerViewOrders
• 賣家看自己的訂單：/MerchantViewOrders
• 運(yùn)營(yíng)商看任意訂單：/AdminViewOrders

然后，我們可以制訂如下規(guī)則。

• 所有這些 API 都要求用戶處于已登錄狀態(tài)
• 對(duì)于 /CustomerViewOrders ，訪問者必須有 customer 身份
• 對(duì)于 /MerchantViewOrders ，訪問者必須有 merchant 身份
• 對(duì)于 /AdminViewOrders，要求當(dāng)前用戶必須有 admin 身份

這樣，鑒權(quán)服務(wù)就可以根據(jù)身份、動(dòng)作和規(guī)則三者來判斷訪問權(quán)限了。

[[216643]]

(圖片來自：http://t.cn/RHRujGG)

至于賣家給小二的權(quán)限分配，根據(jù)不同需要，我們可以選擇兩個(gè)方案。第一是讓賣家自己去處理這個(gè)細(xì)粒度的權(quán)限，形成自己的一套小的權(quán)限體系，這也意味著小二訪問的可能是因賣家中轉(zhuǎn)而暴露出來的新 API。第二是把這個(gè)細(xì)粒度的權(quán)限也建模到原來的權(quán)限體系里面，加入如下新的 API 和判斷規(guī)則。

小二查看訂單： /ClerkViewOrders，檢查：

• 用戶必須是 clerk 身份
• 用戶在組織結(jié)構(gòu)上必須屬于某個(gè) merchant
• 如果用戶類別是 1，那么他可以查看所有分配到自己組內(nèi)任意小二的訂單
• 如果用戶類別是 2，那么他可以查看分配給自己的訂單

我們?cè)賮砜戳硪粋€(gè)場(chǎng)景，查看員工信息。API 的和規(guī)則的設(shè)計(jì)如下。

• 所有 API 要求用戶處于登錄狀態(tài)

員工查看自己的信息：/EmployeeViewOwnProfile（所有員工均可訪問）

員工查看其他員工的信息：/EmployeeViewProfile（所有員工均可訪問）

經(jīng)理查看員工信息：/ManagerViewProfile（當(dāng)前用戶必須為 manager 角色、請(qǐng)求中的員工必須屬于該 manager 負(fù)責(zé)的 location）

不同的 API 返回的數(shù)據(jù)可能有差別，比如看自己的信息可以看全，看別人的只能看名字、照片和聯(lián)系方式，經(jīng)理則可以看所有人的完整信息，這由應(yīng)用邏輯決定。

[[216644]]

(圖片來自：http://t.cn/RHRu1e3)

再來看一個(gè)醫(yī)院的。醫(yī)院有一點(diǎn)不同的是，病人和病歷實(shí)際上需要在多個(gè)部門之間周轉(zhuǎn)，而不同的角色處在不同部門的時(shí)候，其職能和權(quán)限會(huì)有變化。比如， 有時(shí)候?qū)嵙?xí)醫(yī)生會(huì)守急診室，住院醫(yī)生不在的時(shí)候護(hù)士也需要代理執(zhí)行醫(yī)囑，職工可能會(huì)輪崗到不同部門，等等。

基于這樣一些假想場(chǎng)景，我們可能會(huì)有如下一些 API 和權(quán)限。

(1) 掛號(hào)處，要求用戶必須有 clerk 身份

• 建檔：/RegistrationsCreateMedicalRecord
• 掛號(hào)：/RegistrationsCreateVisit
• 查看病歷(用于確認(rèn)病人已建檔)：/RegistrationViewMedicalRecord

(2) 門診部，要求用戶必須有 doctor 身份

• 診斷：/OutPatientCreateDiagnosis
• 開藥：/OutPatientCreatePrescription
• 查看病歷：/OutPatientViewMedicalRecord

(3) 急診室，要求用戶必須有 doctor 身份

• 查看病歷：/EmergencyViewMedicalRecord

(4) 住院部，要求用戶必須有 doctor 或者 nurse 身份

a.入院：/InPatientAdmitPatient

• （僅 nurse 可以執(zhí)行入院）

b.日常檢查記錄：/InPatientCreateRoutineRecord

• doctor 只能給自己分管的病人創(chuàng)建檢查記錄
• nurse 只能給自己負(fù)責(zé)區(qū)域的病人創(chuàng)建檢查記錄

c.創(chuàng)建醫(yī)囑：/InPatientCreateOrder

• doctor 只能給自己分管的病人創(chuàng)建醫(yī)囑
• nurse 不能創(chuàng)建醫(yī)囑

d.出院：/InPatientDismissPatient

• 僅 nurse 可以執(zhí)行出院

e.查看病歷：/InPatientViewMedicalRecord

• doctor 只能查看自己分管病人的病歷

(5) 手術(shù)室，要求用戶必須有 doctor-surgeon 身份

• 準(zhǔn)備材料：/OpRoomPrepareMaterial
• 記錄結(jié)果：/OpRoomCreateOpRecord

(6) 檢查部，要求用戶必須有 technician 身份

• 錄入結(jié)果：/LabsCreateExaminationRecord
• 查看病歷：/LabsViewMedicalRecord

(7) 藥房，要求用戶必須有 pharmacist 身份

• 看處方：/PharmacyViewPrescription
• 放藥：/PharmacyDeliverMedicine

上述 API 能訪問到的數(shù)據(jù)和權(quán)限主要根據(jù)部門來進(jìn)行劃分，方便輪崗。比如，醫(yī)生在門診的時(shí)候，可以查看完整的病人病歷，但輪崗到掛號(hào)處的時(shí)候，雖然也查看病歷，但就只能查看最基本的個(gè)人信息了，用于給病人補(bǔ)辦卡片之類。

功能和數(shù)據(jù)權(quán)限

從上面幾個(gè)例子看來，我們通?？梢园褭?quán)限的驗(yàn)證分成兩個(gè)步驟：先確定職能，然后確定職能作用范圍。

比如，先確定你能看訂單，然后確定你能看哪些訂單;先確定你能看工資，然后確定你能看誰(shuí)的工資。再比如，某國(guó)法律規(guī)定，當(dāng)一個(gè)案件發(fā)生在某地，警察來調(diào)查，但只有該轄區(qū)的警察有調(diào)查權(quán)，跨區(qū)域的案件必須交給聯(lián)邦警察。如此等等。

既然這兩步看上去分得很清楚，那么我們不妨給它們分別取名。用戶能不能執(zhí)行某個(gè)動(dòng)作，使用某個(gè)功能，是功能權(quán)限，而能不能在某個(gè)數(shù)據(jù)上執(zhí)行該功能(訪問某部分?jǐn)?shù)據(jù))，是數(shù)據(jù)權(quán)限。

促成這種拆分方式的原因可能有下面幾種。

• 現(xiàn)實(shí)中，很多組織采取了這種“職能 + 組織節(jié)點(diǎn)”的形式來確定權(quán)限，所以這樣的拆分實(shí)際上為建模提供了方便。
• 由于功能權(quán)限通常會(huì)直接對(duì)應(yīng)應(yīng)用的 API 列表，所以權(quán)限驗(yàn)證可以及早失敗，而無需把數(shù)據(jù)取出來做對(duì)比，提升了鑒權(quán)的效率。
• 方便我們把所有的功能 API 提取出來形成一個(gè)列表或者表格，可以更好地查看和管理權(quán)限。

此外，這種形式的權(quán)限管理還可以讓業(yè)務(wù)人員在不寫代碼的情況下對(duì)功能權(quán)限進(jìn)行重新分配。如果涉及數(shù)據(jù)權(quán)限，則必然會(huì)有某種形式的判斷邏輯，寫代碼也就必不可少了。

話說回來，盡管這種拆分很常見，我們?nèi)詰?yīng)該認(rèn)識(shí)到這只是人為的一種拆分。二者都是權(quán)限驗(yàn)證的一部分，都是為了回答“該用戶能不能做某件事”這個(gè)問題，本質(zhì)沒變。

需要注意的是，在制定權(quán)限規(guī)則時(shí)，制訂者需要參考業(yè)務(wù)規(guī)則，但是反之則不然。業(yè)務(wù)規(guī)則可以在完全不了解權(quán)限驗(yàn)證規(guī)則的情況下執(zhí)行。甚至，從理論上說，所有的業(yè)務(wù)單元都應(yīng)該可以在完全沒有權(quán)限驗(yàn)證的情況下“正常裸奔”，即假設(shè)所有人可以做所有事情，但業(yè)務(wù)應(yīng)該被正常執(zhí)行，業(yè)務(wù)規(guī)則應(yīng)該被正常遵守。用語(yǔ)言學(xué)的詞匯來說，就是在沒有權(quán)限驗(yàn)證的情況下，業(yè)務(wù)數(shù)據(jù)中也許會(huì)有語(yǔ)義問題(semantic problem)，但是不會(huì)有句法錯(cuò)誤(syntax error)。

[[216645]]

鑒權(quán)體系回顧

我們來回顧一下這篇文章中提到的鑒權(quán)體系。

• 身份認(rèn)證。確認(rèn)“你是你”，獲取你的身份信息。
• 權(quán)限驗(yàn)證。確認(rèn)“你能做某件事”。

二者合稱為“鑒權(quán)”。身份認(rèn)證輸入令牌，輸出身份。權(quán)限驗(yàn)證輸入身份、動(dòng)作(包括動(dòng)作范圍)，輸出“同意”或“拒絕”。我們希望身份和權(quán)限在一個(gè)體系內(nèi)高度一致，所以，鑒權(quán)是一個(gè)半中心化的行為，權(quán)限規(guī)則在一個(gè)體系(比如組織、應(yīng)用)內(nèi)是中心化管理的。

權(quán)限的形成需要對(duì)業(yè)務(wù)知識(shí)的了解，但規(guī)則抽象出來之后，要使用它就不需要業(yè)務(wù)知識(shí)了。權(quán)限驗(yàn)證的獨(dú)立，意味著我們把“權(quán)限規(guī)則”和“業(yè)務(wù)規(guī)則”拆成了兩個(gè)部分。前者擁抱變化，而后者追求穩(wěn)定;前者在意的是業(yè)務(wù)的意義，后者在意的是業(yè)務(wù)的邏輯。

為了適應(yīng)現(xiàn)有組織形態(tài)和更清晰地展示權(quán)限信息，在給權(quán)限建模的時(shí)候我們常常會(huì)把它拆分成功能和數(shù)據(jù)權(quán)限兩種。我們應(yīng)該認(rèn)識(shí)到二者都是權(quán)限驗(yàn)證的一部分，都是為了回答同一個(gè)問題：這個(gè)用戶能不能做某事。

從整個(gè)分析脈絡(luò)我們可以看到，這個(gè)鑒權(quán)體系是通用的。在設(shè)計(jì)任意一個(gè)系統(tǒng)的過程中，我們都應(yīng)該注意盡量把安全相關(guān)的判斷和業(yè)務(wù)規(guī)則拆開對(duì)待，方便集中管理權(quán)限，把業(yè)務(wù)規(guī)則提純。

對(duì)于微服務(wù)架構(gòu)來說，鑒權(quán)是一個(gè)重要的節(jié)點(diǎn)，它和應(yīng)用場(chǎng)景密切結(jié)合，是安保的最后一道關(guān)口。在對(duì)權(quán)限進(jìn)行建模的時(shí)候，我們應(yīng)該尤其謹(jǐn)慎。希望這篇文章能給大家一些啟示。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文