.NET Core中的認證管理解析

0x00 問題來源

在新建.NET Core的Web項目時選擇“使用個人用戶賬戶”就可以創建一個帶有用戶和許可權管理的項目，已經準備好了用戶註冊、登錄等很多頁面，也可以使用AuthorizeAttribute進行各種許可權管理，看起來似乎十分方便。不過生成的代碼都替我幹了些什麼我一團霧水。看了下生成的數據表，功能也挺複雜的。實際上我需要的只是基於用戶和角色的認證管理，而且用戶資料是使用現有的庫，但使用.NET Core自帶的認證組件必須要依賴EF，表的結構也很多對不上，所以學習了下自帶的認證組件的實現，然後自己寫了個認證服務替換了Identity組件，同時Cookie管理使用自帶的Cookie中間件、可以使用AuthorizeAttribute進行認證。複雜的需求還沒遇到，所以就學習到了這裡。這篇博客主要討論最簡單情況下的的基於用戶和角色的認證。關於.NET Core自帶認證組件的一些基本用法，可以參考https://docs.asp.net/en/latest/security/authentication/accconfirm.html。

0x01 .NET Core中的認證管理

提到認證管理，首相想到的就是用戶的註冊、登錄、註銷以及給用戶添加/刪除角色等功能。其中用戶信息，角色信息等都是保存在資料庫中的。所以主要包含資料庫操作和登錄業務邏輯兩部分。在登錄業務邏輯層面，.NET Core主要通過三個比較核心的類UserManager、RoleManager、SigninManager進行管理（在Microsoft.AspNetCore.Identity程式集）。其中：

• UserManager主要負責用戶的認證、註冊、修改、刪除以及與用戶相關的角色、令牌、聲明等的管理。
• RoleManager負責角色、角色相關聲明的管理。
• SigninManager負責登錄、註銷等相關操作。在涉及到用戶操作（如登陸時用戶驗證）會調用UserManager進行操作。

這三個核心類在操作資料庫時，使用資料庫層面的UserStore、RoleStore進行操作（在Microsoft.AspNetCore.Identity.EntityFrameworkCore程式集）。業務關係如下圖所示：

我們在開發認證相關功能時使用這三個核心類即可滿足大多數需求。我們在使用這幾個核心類的對象時都是通過依賴註入獲取的，那麼這些相關的依賴是什麼時候註入的呢？在Startup的ConfigureServices方法中有AddIdentity擴展方法，就是在這個方法中添加了需要的所有依賴。

0x02 登錄和註銷

瞭解了Identity組件的整體分工後，再來看一下登錄和註銷的操作的部分細節。登錄和註銷過程主要由SigninManager負責，的先來看一下登錄的過程：

登錄成功後Response的Header中包含了Set-Cookie，Cookie的Key需要和Cookie中間件中設置的要解密的Cookie的Key一致，在截圖中這個Cookie的Key是IdentityCookie。設置Cookie的同時返回302重定向到登錄頁面。

重定向到登陸頁面時，請求中已經帶有設置的Key為IdentityCookie的Cookie了。

註銷過程比較簡單，調用HttpContext.Authentication.SignOutAsync方法即可註銷，此時會給HttpContext.Response添加Set-Cookie，但內容為空。

0x03 通過Cookie識別用戶

.NET Core中通過CookieAuthenticationMiddleware這個中間件識別HttpContext中認證相關的Cookie，從而添加用戶的驗證和授權信息。最關鍵的是ClaimsPrincipal對象，它記錄用戶的認證和授權信息（除此之外當然也可以包含其它你需求的任意信息），從上面登錄過程可以看到，登錄成功後用戶認證和授權信息保存至ClaimsPrincipal對象（實際上對於這條Cookie鍵值對中的認證信息保存為ClaimsIdentity，一個ClaimsPrincipal可以包含多個ClaimsIdentity），然後在HttpContext.Response的Headers中添加Set-Cookie，Key為Cookie中間件中指定的CookieName，Value就是這個對象加密後的字元串。以後的HttpContext都會帶有這個Cookie，Cookie中間件會把符合這個CookieName的Cookie取出來，解密並還原為ClaimsPrincipal對象，並把HttpContext.User設置為這個對象。後面MVC中間件在路由到相應Controller和Action的時候就可以根據Authorize特性中指定的認證和角色在HttpContext.User中進行檢查，不滿足檢查則跳轉至相應頁面。因此需要註意的就是一定要把Cookie中間件放在MVC中間件之前。

這裡需要特別說一下ClaimsPrincipal。一個ClaimsPrincipal對象中包含了一個或多個ClaimsIdentity對象，一個ClaimsIdentity對象一般來說對應著一個Cookie中某條鍵值對（個人理解）。Cookie中間件和ClaimsIdentity是通過AuthenticationScheme聯繫起來的。後面我們在寫自己的認證服務時，也是把Cookie中間件的AuthenticationScheme和創建的ClaimsIdentity一致。所以更準確地說是ClaimsIdentity包含了用戶認證和許可權的聲明，而ClaimsPrincipal可以包含多個ClaimsIdentity。當管道中存在多個Cookie中間件時，通過AuthenticationScheme進行區分。

在ClaimsIdentity中除了AuthenticationScheme外還有兩個比較重要的屬性，UserType和RoleType，其中UserType指定了用戶驗證類型，RoleType指定可角色驗證類型。意思就是如果我指定了RoleType為”RoleName”，那麼在進行角色認證時就會尋找Claims中所有的Type為”RoleName”的值，並檢查其中是否包含了Authorize中指定的RoleName。不過.NET Core中自帶了ClaimTypes，可以直接使用。例如角色類型就是ClaimTypes.Role。如果添加角色時用的自帶的ClaimTypes.Role，那麼在創建ClaimsIdentity時就不需要顯示指定RoleType了，預設角色認證就是使用ClaimTypes.Role。

關於Cookie中間件的添加，是通過Startup中Configure方法中的app.UseIdentity擴展方法實現的。這個擴展方法實際上添加了多種Cookie識別方式。在後面我在寫自己的用戶認證管理時只用一種。

0x04 自己寫用戶認證管理

瞭解了用戶認證的過程，我們可以自己寫認證管理來代替Identity組件了，同樣分為資料庫操作和認證業務邏輯。資料庫相關就不多說了，都寫到了IdentityRepository類，只有很簡單的數據操作。為了方便使用了Dapper，資料庫用的Sqlite。程式在啟動時會檢查資料庫表，沒有會自動創建空表。

認證服務也比較簡單就都寫到了IdentityService類，提供了註冊和登錄操作，註銷太簡了直接寫在了Action里。為了方便沒有提供角色管理頁面，如果要測試角色認證功能，需要手動去資料庫添加Role，然後在UserRoles中給用戶添加Role。

登錄：

註冊：

註銷：

具體示例可以到：

https://github.com/durow/NetCoreStudy

只是為了測試，邏輯上很多問題，比如用戶密碼明文存儲。重點看過程:)

0x05 寫在最後

第一次接觸Web應用，很多概念都不是很瞭解。就拿Cookie認證用戶來說，我之前的只知道通過Cookie識別用戶，一直以為是收到Cookie後再從資料庫或緩存中查出相應的許可權信息。不過看了自帶的Cookie中間件代碼後才知道認證信息是直接存在Cookie中的，這樣只要解密後反序列化就可以了。Identity這個程式集涉及了很多其它程式集（Security、HttpAbstraction等等），看得我很暈，最後總算搞明白了一些，很多細節也沒去深究，文中內容有的基於代碼，有的基於個人理解，有錯誤希望大家嘴下留情。