不知不覺.Net Core已經推出到3.1了,大多數以.Net為技術棧的公司也開始逐步的切換到了Core,從業也快3年多了,一直堅持著.不管環境怎麼變,堅持自己的當初的選擇,堅持信仰 .Net Core是個非常優秀的框架,如果各位是從WebForm開始,一步步走到今天,自然而然就會發現.微軟慢慢的開始將整個框架元件化,不在像以前那樣,所以的東西都傻瓜化,比如WebForm,拖拖控制元件往往能搞定大部分的事情.Core的擴充套件性很好,將很多選擇權交給我們自己,而不是強行的讓我們去接受他那一套,對第三方元件的相容性很好.換句話說,很多核心元件微軟提供了高層抽象,如果你想換,可以,不想換,也可以,用他預設的實現.其他的優缺點也不一一細說了,也不是本文的重點。如果時間允許,建議大家可以深入的研究.Net Core的底層.

1、簡介

省去前面的建立Core Web專案的一系列操作.VS幫你自動化初始化好所有的基礎元件、環境.第一步就是認證.就是登陸.當然微軟提供了一套登陸元件.很全,很完善。專案在Core原始碼 

 Security資料夾下,原始碼自行去github下載.裡面提供了若干個認證方法,常見的Cookie認證、JwtBear認證等等.還包括FaceBook、Google等遠端認證方式.

本文暫時不講解具體的認證方式,主要闡述核心認證流程.

(1)、認證系統的執行過程

Core啟動認證系統的方式很簡單

 很簡單的一段程式碼,看看它幹了什麼

 很簡單,注入認證中介軟體,關於中介軟體這裡就不說多,不是文字的重點,自行百度.看看中間價幹了什麼.

 核心程式碼,首先拿到DI中注入的處理認證請求處理器集合,接著去DI中獲取認證處理方案集合中的處理認證請求上下文的方案類.接著去處理器集合中拿到處理認證請求上下文的方案類對應的認證請求處理器,接著執行處理器的HandleRequestAsync方法,完成認證請求上下文的處理.這意味著我們的認證請求引數是可以被我們做特殊處理的.

接著

 處理完認證請求引數之後,接著去認證方案中拿到預設的認證方案,不為空,執行上下文的擴充套件方法context.AuthenticateAsync,這個方法幹了什麼如下:

 執行DI中注入的認證服務方法,並傳入上下文和預設的認證方案名稱.

 先判斷存不存在預設認證方案,不存在拋異常,接著去所有的認證處理器集合中拿到預設認證方案的處理器.接著呼叫處理的認證方法,認證成功,判斷當前使用者身份集合中在臨時快取中存不存在,不存在,可以執行Claim的轉換.這很好,說明使用者認證成功之後的Cliam也是可以被轉換的.

 只要注入IClaimsTransformation服務即可,你就可以執行你需要的業務的Claim轉換，最後返回結果

 到這裡整個認證流程結束.非常的簡單.且關鍵點的擴充套件微軟都預留了.可以自定義實現

(2)、流轉服務的介紹.

上面介紹了整個認證元件的流轉過程,因為我對流程很清楚,所以大家可能還是不理解.所以接下去開始介紹流轉必須服務的注入.

 認證處理器的Provider類,那麼Core實在哪裡注入認證處理器的呢?

 這裡,核心也是紅框裡的,下面的只是一些依賴元件。

 微軟注入預設的認證處理器.看下獲取處理器的實現,對應中介軟體.

 閱讀原始碼發現,Provider類並不具體實現提供認證處理器的方法.而是通過SchemeProvider來提供.

原來是IAuthenticationSchemeProvider類提供認證處理器.而且是通過反射實現(這點開銷,就沒必要考慮效能問題,當然你可以考慮重構),那麼問題來了,在哪裡出入IAuthenticationSchemeProvider服務內,回到上面那張圖

 微軟也提供了預設實現,去看看GetSchemeAsync方法的實現

 ok,到這裡就說明認證處理器通過向這個字典寫入值,來實現的.也就是微軟認證方案提供了認證處理器.

 上面是認證方案的核心欄位,HandlerType就是認證處理器.

AuthenticationSchemeProvider類維護了一個_schemes的字典,通過它向外輸出.認證方案集合提供類.

 接著認證處理器集合提供類AuthenticationHandlerProvider通過解析

認證方案集合提供類,拿到所有的認證處理器.

到這裡,很明顯,所有的認證處理器都是通過向AuthenticationSchemeProvider的_schemes字典注入認證處理器.既然如此,入口在哪？在AuthenticationBuilder類下面.

 下面是Cookie認證方式注入認證處理器的方式

 AddScmeme方法.在配置引數的同時,指定了處理器.

 接著,回到中介軟體的圖

 我們通過AuthenticationBuilder的AddScheme方法向_schemes集合寫入了認證處理器且配置了處理器的引數,接著通過AuthenticationHandlerProvider拿到了所有的認證處理器.

接著我們通過Schemes方案集合拿到所有處理認證請求上下文的處理器,執行處理認證請求上下文引數.處理完畢.

接著我們解析Schemes中提供的預設認證方案,程式碼如下:

 根據

 這個配置引數,一般在入口注入:

 中配置預設方案名稱,拿到預設認證方案.再將處理過的認證請求上下文和預設方案傳給IAuthenticationService,這個Service也有預設實現,如下:

 AuthenticationService將處理過的認證請求上下文交給具體的認證請求處理器來處理.並返回處理結果.認證請求處理器前面說過了,通過AuthenticationBuilder的AddScheme方法來注入.

到這裡,整個元件的流程介紹結束.純屬個人理解,能力有限,有問題,請指正,謝謝.

下面開始介紹基於Cookie的認證元件.