asp.net core 3.x 身份驗證-1涉及到的概念

前言

從本篇開始將圍繞asp.net core身份驗證寫個小系列，希望你看完本系列后，腦子里對asp.net core的身份驗證原理有個大致印象，
至于身份驗證是啥？與授權有啥聯系？就不介紹了，太啰嗦，你如果不曉得，自己去搜搜吧，
我的學習思路是詳細看原始碼 > 總結得出一個宏觀上的印象 + 如何使用，
如果發現有啥講錯的望指正，免得誤導觀眾

我們偶爾會思考如何設計一個牛X的軟體，其實通過對asp.net core框架本身的學習更劃算，一來我們熟悉了asp.net core框架，再者我們學習了微軟碰到需求是如何設計的，

計劃：

• 基本介紹 - 概述 + 核心類介紹
• 基于cookie/session的身份驗證原理 - 適合瀏覽器
• 基于Token身份驗證 - 適合移動端app
• 集成第三方登錄原理 - 比如集成微信、支付寶登錄
• IdentityServer - 目前不鳥解
• asp.net core Identity - 目前不鳥解

必備知識：asp.net core、配置、選項、依賴注入、中間件等...

參考：原始碼、Artech、mvc5基于owin的身份驗證視頻、ASP.NET Core 運行原理解剖[5]:Authentication

注意：本篇只講涉及到的幾個概念

推薦個不錯的流程圖/腦圖工具：https://www.processon.com/i/59accdd8e4b0859febda28e3，點這個鏈接注冊我可以獲得幾個檔案限額，抱拳~

身份驗證方式和簡易流程

常見的身份驗證方式：

• 基于cookie/session的身份驗證 - 適合瀏覽器
• 基于JWTToken身份驗證（OAuth2） - 適合移動端app
• 集成第三方登錄(OAuth2) - 比如集成微信、支付寶登錄

為了便于理解后續的概念，下面先以最簡單常見的 【用戶密碼+cookie】 的身份驗證方式說說核心流程

登錄：

1. 用戶輸入賬號密碼提交
2. 服務端驗證賬號密碼
3. 若驗證成功，則創建一個包含用戶標識的票證（下面會說）
4. 將票證加密成字串寫入cookie

攜帶cookie請求：

1. 用戶發起請求
2. 身份驗證中間件嘗試獲取并解密cookie，進而得到含用戶標識的票證（下面會說）
3. 將用戶標識設定到HttpContext.User屬性

注意：若身份驗證中間件即使沒有決議得到用戶標識，請求也會繼續執行，此時以匿名用戶的身份在訪問系統

用戶標識ClaimsPrincipal

它用來表示當前登錄的用戶，它包含用戶Id + 一些與權限檢查相關的附件屬性（角色、所屬部門），
當請求抵達時“身份驗證中間件”將從請求中決議得到當前用戶，如果獲取成功則賦值給HttpContext.User屬性

所以對于我們來說通常有兩個場景使用它
在任意能訪問HttpContext的地方獲取當前用戶，比如在Controller中，
如果需要自定義實作身份驗證，則我們要想方設法從請求中決議得到用戶，并賦值給HttpContext.User

現在你至少對用戶標識這個概念有點理解了，如果要刨根問底兒就自行搜索關鍵字：asp.net Claims

也許你曾經做過或見過這樣的設計，定義Employee表示當前系統的用戶，當用戶登錄時會從資料庫查詢得到對應的Employee，若賬號密碼驗證通過則將其放入Session或快取中，下次訪問時直接從Session/快取中獲取當前用戶，個人覺得這種設計存在如下問題：

• 浪費記憶體：我們的業務代碼訪問當前用戶最多的欄位可能只是用戶id，性別、地址、聯系電話、學歷....這些欄位不是每個業務處理都需要的
• 拋棄了asp.net身份驗證框架：從asp.net 2.0時代微軟就設計了IPrincipal，后續的版本直到mvc5中基于owin的身份驗證都在使用此介面，后續的權限驗證微軟也提供了，也是基于此介面的，但我們放棄了，反而是自己有寫了一套微軟本身就實作的功能，可能多數是覺得自己寫的更簡單，但我覺得判斷哪種方式更合適是在你對兩種方式都了解的情況下再做出判斷，

用戶票證AuthenticationTicket

既然有了上面的用戶標識，何不直接在登錄時加密這個標識，決議時直接解密得到呢？因為我們還需要額外的控制，比如過期時間，這個屬性只是在身份驗證階段來判斷是否過期，在我們（如Controller.Action中）使用用戶標識的時候并不需要此欄位，類似的額外欄位根據不同的身份驗證方式可能有很多，因此定義了“用戶票證”這個概念，它包含 用戶標識 + 身份驗證程序中需要的額外屬性（如得到用戶標識的時間、過期時間等）

身份驗證處理器AuthenticationHandler

參考上面的用戶名密碼+cookie身份驗證流程我們發現有幾個核心的處理步驟：

• 在登錄時驗證通過后將用戶標識加密后存盤到cookie，SignIn
• 當用戶注銷時，需要清楚代表用戶標識的cookie，SignOut
• 在登錄時從請求中獲取用戶標識，Authenticate
• 在用戶未登錄訪問受保護的資源時，我們希望跳轉到到登錄頁，Challenge
  • Challenge叫做質詢/挑戰，意思是當發現沒有從當前請求中發現用戶標識是希望怎么辦，可能是跳轉到登錄頁，也可能是直接回應401，或者跳轉到第三方（如QQ、微信）的登錄頁　
• 因為某種原因（如權限驗證不過），阻止方案，Forbid

身份驗證處理器就是用來跟身份驗證相關的步驟的，這些步驟在系統的不同地方來呼叫（比如在登錄頁對于的Action、在請求抵達時、在授權中間件中），
每個呼叫時都可以指定使用哪種身份驗證方案，如果不提供將使用默認方案來做對應的操作，
不同的身份驗證方式有不同的實作

IAuthenticationHandler介面只定義了最核心的幾個步驟：Authenticate()、Challenge()、Forbid()，登錄和注銷這兩個步驟定義了對應的子介面，當然微軟還為我們定義了抽象類，參考
   

某個具體的身份驗證方案的選項AuthenticationSchemeOptions

在上述身份驗證處理的多個步驟中會用到一些選項資料，比如基于cookie的身份驗證 cookeName、有效時長、再比如從請求時從cookie中決議得到用戶標識后回呼選項中的某個回呼函式，允許我們的代碼向除錯中添加額外資料，或者干脆替換整個標識，

所以身份驗證選項用來允許我們控制AuthenticationHandler的執行，不同的身份驗證方式有不同的選項物件，它們直接或間接繼承AuthenticationSchemeOptions

身份驗證方案AuthenticationScheme

總結性的說：身份驗證方案 = 名稱 + 身份驗證處理器型別，暫時可以理解一種身份驗證方式 對應 一個身份驗證方案，比如：
基于用戶名密碼+cookie的身份驗證方式 對應的 身份驗證方案為：new AuthenticationScheme("UIDPWDCookie",typeof(CookieAuthenticationHandler))
基于用戶名密碼+token  的身份驗證方式 對應的 身份驗證方案為：new AuthenticationScheme("JwtBearer",typeof(JwtBearerHandler))

身份驗證方案在程式啟動階段配置，啟動后形成一個身份驗證方案串列，
程式運行階段從這個串列中取出指定方案，得到對應的處理器型別，然后創建它，最后呼叫這個處理器做相應處理
比如登錄操作的Action中xxx.SignIn("方案名") > 通過方案名找到方案從而得到對應的處理器型別 > 創建處理器 > 呼叫其SignIn方法

一種特殊的情況可能多種方案使用同一個身份驗證處理器型別，這個后續的集成第三方登錄來說

方案、處理器、選項、三者之間的關系

簡單但不準確的理解為：方案名+處理器+選項 = 身份驗證方式

身份驗證方案的容器AuthenticationSchemeProvider

身份驗證方案的容器（Dictionary<方案名,身份驗證方案>）
默認是單例形式注冊到依賴注入容器的
在應用啟動時通過AuthenticationOptions添加的各種身份驗證方案會被存盤到這個容器中
各種GetDefaultXXX用來獲取針對特定步驟的默認方案，如：GetDefaultAuthenticateSchemeAsync中間件從請求獲取用戶標識時用來獲取針對此步驟的默認方案、GetDefaultSignInSchemeAsync獲取默認用來登錄的方案、GetDefaultSignOutSchemeAsync...等等，身份驗證的不同步驟可以設定不同的默認方案，如果針對單獨的步驟沒有設定默認方案，則自動嘗試獲取總的默認方案，通過AuthenticationOptions設定這些默認值
身份驗證程序中各個步驟都會通過此物件拿到指定方案，并通過關聯的身份驗證型別獲得最終身份驗證處理器，然后做相應處理

整個應用的身份驗證選項AuthenticationOptions

AuthenticationSchemeBuilder的屬性跟AuthenticationScheme幾乎是一樣對應的，它的Build()方法會生成一個AuthenticationScheme，所以我們可以理解為AuthenticationSchemeBuilder = AuthenticationScheme

上面說的AuthenticationSchemeOptions是指某個具體身份驗證方案的選項，不同身份驗證方案有對應的子類，比如：CookieAuthenticationOptions、JwtBearerOptions.. 它們都是AuthenticationSchemeOptions的子類，AuthenticationOptions則是針對整個身份驗證功能的選項物件，我們需要在應用啟動階段通過它來配置身份驗證功能，可以把它理解為IDictionary<方案名, AuthenticationSchemeBuilder>（方案配置容器） + 一些默認值設定，

在應用啟動階段（Startup.ConfigreService）多次呼叫 AddScheme以添加身份驗證方案，

public void AddScheme(string name, Action<AuthenticationSchemeBuilder> configureBuilder)
{
    var builder = new AuthenticationSchemeBuilder(name);
    configureBuilder(builder);
    _schemes.Add(builder);
}

name方案名；configureBuilder允許我們提供委托對方案進行配置

添加的這些方案最侄訓被存盤到AuthenticationSchemeProvider供其使用

另外DefaultAuthenticateScheme、DefaultSignInScheme、DefaultSignOutScheme..看名字也曉得它是說當我們呼叫某個步驟未指定使用那個方案是的默認選擇

身份驗證處理器工廠AuthenticationHandlerProvider

它是以Scope的形式注冊到依賴注入容器的，所以每次請求都會創建一個實體物件，
唯一方法GetHandlerAsync從AuthenticationSchemeProvider獲取指定身份驗證方案，然后通過方案關聯的AuthenticationHandler Type從依賴注入容器中獲取AuthenticationHandler ，獲取的AuthenticationHandler會被快取，這樣同一個請求的后續呼叫直接從快取中拿，
所以也可以把它理解為AuthenticationHandler的運行時容器或工廠
AuthenticationService就是通過它來得到AuthenticationHandler然后完成身份驗證各種功能的

身份驗證服務AuthenticationService

身份驗證中的步驟是在多個地方被呼叫的，身份驗證中間件、授權中間件、登錄的Action(如：AccountController.SignIn())、注銷的Action(如：AccountController.SignOut())，身份驗證的核心方法定義在這個類中，但它本質上還是去找到對應的身份驗證處理器并呼叫其同名方法，其實這些方法還進一步以擴展方法的形式定義到HttpContext上了，以SignIn方法為例
HttpContext.SignIn() > AuthenticationService.SignIn() > AuthenticationHandler.SignIn() 

后續

這一篇只盡量簡單的說了下身份驗證涉及到的幾個核心概念，如果不明白的可以留言或等到下篇結合理解，下一篇將以用戶名密碼+cookie的身份驗證方式來詳細梳理下流程，

標籤：.NET Core

上一篇：【原創】在 ASP.NET Core 3.1 中使用 Senparc.Weixin.Work 企業微信 SDK —— 發送文本訊息

下一篇：Docker常用命令