上一篇文章（ASP.NET Core Identity Hands On（1）——Identity 初次體驗）中，我們初識了Identity，并且詳細分析了AspNetUsers用戶存儲表，這篇我們將一起學(xué)習(xí)Identity 默認生成的樣板代碼的注冊與登陸過程

注冊/Register

打開AccountController找到?public async Task<IActionResult> Register(RegisterViewModel model, string returnUrl = null)方法

這個方法切實的創(chuàng)建用戶并存儲到數(shù)據(jù)庫，完整的過程代碼比較復(fù)雜，所以我們用一張表格來展現(xiàn)具體過程，首先看緊挨著箭頭的那一列文本，即標題為“工作”的那一列，這是完整的順序過程，用戶創(chuàng)建即從頭走到尾。剩余的信息是幫助理解的，因為在Register方法中，并沒有展現(xiàn)關(guān)鍵的內(nèi)容，我列舉出他們出現(xiàn)的位置，這樣有助于理解

在看圖片之前，我們先看一下CreateAsync代碼，這可能和你的有點不同，因為我刪除了一點無關(guān)緊要的東西來減少篇幅

namespace IdentityDemo.Controllers

{

? ? public async Task<IActionResult> Register(RegisterViewModel model, string returnUrl = null)

? ? {

? ? ? ? if (ModelState.IsValid)

? ? ? ? {

? ? ? ? ? ? var user = new ApplicationUser { UserName = model.Email, Email = model.Email };

? ? ? ? ? ? var result = await _userManager.CreateAsync(user, model.Password);

? ? ? ? ? ? if (result.Succeeded)

? ? ? ? ? ? {

? ? ? ? ? ? ? ? var code = await _userManager.GenerateEmailConfirmationTokenAsync(user);

? ? ? ? ? ? ? ? var callbackUrl = Url.EmailConfirmationLink(user.Id, code, Request.Scheme);

? ? ? ? ? ? ? ? await _emailSender.SendEmailConfirmationAsync(model.Email, callbackUrl);

? ? ? ? ? ? ? ? await _signInManager.SignInAsync(user, isPersistent: false);

? ? ? ? ? ? ? ? return RedirectToLocal(returnUrl);

? ? ? ? ? ? }

? ? ? ? ? ? AddErrors(result);

? ? ? ? }

? ? ? ? // If we got this far, something failed, redisplay form

? ? ? ? return View(model);

? ? }

如果不太理解代碼也沒關(guān)系，我們看表格

另外值得注意的是圖中的標注①，驗證用戶名中的字符，他的默認值是

public string AllowedUserNameCharacters { get; set; } = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._@+";

如果我們想更改設(shè)置怎么辦？還有表格中提到了?如果用戶支持鎖定、如果要求郵件不能重復(fù)，這些未確定的值從哪來的？

如果你熟悉 asp.net core ，那我猜你可能已經(jīng)想到了

沒錯?Options?就是 Di中的 Options在起作用。

打開項目根目錄的Startup.cs文件

public class Startup{ ? ?//略...public void ConfigureServices(IServiceCollection services) ? ?{ ? ? ? ?//略...services.AddIdentity<ApplicationUser, IdentityRole>().AddEntityFrameworkStores<ApplicationDbContext>().AddDefaultTokenProviders(); ? ? ? ?//略...} }

當(dāng)前整個identity options應(yīng)用的都是默認配置，所以這里看不到option的蹤跡，接下來我們就以剛才提到的三個選項為例，修改option 的值，修改后的代碼如下

public class Startup{ ? ?//略...public void ConfigureServices(IServiceCollection services) ? ?{ ? ? ? ?//略...services.AddIdentity<ApplicationUser, IdentityRole>(options=>{options.User.AllowedUserNameCharacters = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789.@";options.User.RequireUniqueEmail = false;options.Lockout.AllowedForNewUsers = false;}).AddEntityFrameworkStores<ApplicationDbContext>().AddDefaultTokenProviders(); ? ? ? ?//略...} }

允許的用戶名字符由abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._@+變?yōu)閍bcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789.@?（現(xiàn)在你再試試注冊，之前可以用?_?現(xiàn)在不能用了）

要求郵件不重復(fù)由true變?yōu)閒alse

允許新用戶鎖定由true變?yōu)閒alse

IdentityOptions?可配置的選項非常多，完整的列表請移步?配置 ASP.NET 核心標識

更多關(guān)于Options的內(nèi)容請移步?asp.net core 文檔——配置與選項?一節(jié)

登陸之前——咱們得先弄清Claim

舉個例子

假設(shè)有這樣一家動物園，這家動物園要門票，門票要從動物園門口的售票室買，購買后，能得到一張紙質(zhì)的票據(jù)。紙很特殊，動物園驗票能通過紙張來判斷門票是不是真的，還能看出你有沒有涂改門票。門票上還有時間，指示什么時候門票到期，只要門票沒有到期，你就可以隨意進出動物園

嗯，這么長個例子，其實和Claim沒什么關(guān)系 ：）

門票上有什么？我們來假設(shè)一下

好了，我們假設(shè)的門票就這樣，從門票的第二行（姓名...）開始,每一行都是一個Claim

有了上面的鋪墊，我們接下來正式介紹下Claim

釋義

Claim 本意有

• vt.聲稱;索取;斷言;需要

• vi.提出要求

• n.索賠;聲稱;（根據(jù)權(quán)利而提出的）要求;斷言

斷言是比較準確的釋義，另外可以理解成聲明，每一條claim 都代表了一條票據(jù)的信息，比如示例票據(jù)上的姓名等等。claim 的基本組成是?type和value，上面票據(jù)中左側(cè)的就是type右面就是value

在 .net core 基礎(chǔ)類庫中是含有Claim的實現(xiàn)類的，它的位置是

System.Security.Claims.Claim

我們看一個真實的claim的例子

{"sub": "1234567890","name": "John Doe","iat": 1516239022}

這個例子中含有3個claim

• sub subject 主題，往往指Id

• name 就是name

• iat issue at 發(fā)出時間

這個例子中的 type 都是?JWT RFC中的標準jwt claim，上面這個例子是一個jwt票據(jù)的一部分，而在identity 中，默認使用的是cookie 身份認證，所以使用的不是 jwt 票據(jù)，而是加密cookie票據(jù)（identity沒有這樣定義，這樣寫是為了和jwt票據(jù)區(qū)分開），但是票據(jù)里面的內(nèi)容，jwt和 加密cookie都是一樣的都是——“claim”

再回顧下 claim是什么？ 就是一條一條的 type-value 鍵值對，里面存儲了身份證明信息

而承載claim的東西就是票據(jù)，票據(jù)有很多種 jwt 和cookie 都是主流，不過應(yīng)用場景不一樣，by the way 票據(jù)的英文名稱是“token”，你需要記住它，后續(xù)的文章中，我們會學(xué)習(xí)如何同時使用支持移動后端驗證（jwt token）以及僅僅使用 jwt token

登陸過程

依舊在AccountController中，我們找到public async Task<IActionResult> Login(LoginViewModel model, string returnUrl = null)方法

public async Task<IActionResult> Login(LoginViewModel model, string returnUrl = null)

{

? ? ? ? var result = await _signInManager.PasswordSignInAsync(model.Email, model.Password, model.RememberMe, lockoutOnFailure: false);

? ? ? ? if (result.Succeeded)

? ? ? ? {

? ? ? ? ? ? return RedirectToLocal(returnUrl);

? ? ? ? }

? ? ? ? if (result.RequiresTwoFactor)

? ? ? ? {

? ? ? ? ? ? return RedirectToAction(nameof(LoginWith2fa), new { returnUrl, model.RememberMe });

? ? ? ? }

? ? ? ? if (result.IsLockedOut)

? ? ? ? {

? ? ? ? ? ? return RedirectToAction(nameof(Lockout));

? ? ? ? }

? ? ? ? else

? ? ? ? {

? ? ? ? ? ? ModelState.AddModelError(string.Empty, "Invalid login attempt.");

? ? ? ? ? ? return View(model);

? ? ? ? }

? ??

}

這是個簡略版本的代碼，只保留了關(guān)鍵信息

用于登陸的代碼只有一行var result = await _signInManager.PasswordSignInAsync(model.Email, model.Password, model.RememberMe, lockoutOnFailure: false);但里面做的事情可是非常多的，我們稍后在講，現(xiàn)在我們先要了解一下，登陸之后有哪些結(jié)果產(chǎn)生——result

SignInResult

SignInResult 只有5個屬性

• Success 表示一切順利，登陸成功

• Failed 登陸失敗

• LockedOut 用戶被鎖定了

• NotAllowed 不允許登陸

• TwoFactorRequired 要求雙因子驗證

然后我們看一下具體的登陸過程，這里仍舊是一個表格，

登陸過程描述

代碼范圍作用

我們的代碼	從用戶輸入獲取用戶名、密碼、記住我
Identity	檢查是否需要確認郵件以及此用戶郵件是否已經(jīng)確認
	檢查是否支持鎖定用戶以及此用戶是否已被鎖定
	檢查用戶密碼是否正確，以及是否需要升級①
	如果支持鎖定用戶，并且支持在登陸失敗超過指定次數(shù)鎖定用戶則增加AccessFailedCount計數(shù)，并且在到達設(shè)置的計數(shù)上限后清零計數(shù)設(shè)置LockoutEnd時間②
	通過用戶的基本信息生成Claims 及ClaimsIdentity③
	如果支持額外的Claims存儲則添加額外的Claims④ 【注：Identity支持，額外的Claims存儲在AspNetUserClaims表中】
	生成ClaimsPrinciple⑤
	添加認證方法Claim⑥
HttpAbstractions	確保上一個單元格中的認證方法不是空
	通過認證方法，獲取指定的IAuthenticationSignInHandler實例⑦
Security	使用ClaimsPrinciple創(chuàng)建 票據(jù)
	加密票據(jù)
	將加密后的票據(jù)添加到http響應(yīng)的cookie頭中

上表就是登陸過程，Identity默認使用cookie作為 claims 的載體，在最后的步驟中將含有claims的票據(jù)加密存儲到cookie中，這樣在登陸之后再次訪問就可以驗證cookie來識別當(dāng)前是否有用戶登錄，以及登陸用戶的身份

在代碼范圍一列中，我們看到有4列，這和注冊過程中相比，多出了 HttpAbstractions 和 Security，我們先來解釋下這兩個東西是什么

HttpAbstractions*

這是 asp.net core 中的http基礎(chǔ)相關(guān)抽象，例如HttpRequest、HttpResponse、HttpContext等等
關(guān)于 HttpAbstractions的更多信息，可以訪問它的GitHub主頁?https://github.com/aspnet/HttpAbstractions

Security*

這個庫里面主要包含用于web開發(fā)的安全與授權(quán)相關(guān)的中間件，在上表中 的標注⑦IAuthenticationSignInHandler的實例，事實上就是CookieAuthenticationHandler，在后續(xù)的文章里當(dāng)我么講到身份認證過程的時候會詳細講述身份認證中間件及handler是如何工作的

另外，還可以訪問他的GitHub主頁獲得更多信息https://github.com/aspnet/Security

接下來我們解釋一下上表中的標注

標注解釋

①檢查用戶密碼是否正確，以及是否需要升級

在ASP.NET Core Identity Hands On（1）——Identity 初次體驗?中，我們有提到 Identity的密碼哈希有兩個版本 v2和v3，那么如果一個舊的Identity升級到新的Identity那么密碼會不兼容，所以在Identity中密碼驗證為了兼容舊版，做了一些特殊處理。v3的密碼byte以0x01開頭，而v2以0x00開頭，從這里可以判斷出密碼哈希是哪個版本的然后根據(jù)不同的版本來驗證密碼，密碼驗證有3個結(jié)果——失敗、成功、成功且需要更新版本：

namespace Microsoft.AspNetCore.Identity{ ? ?public enum PasswordVerificationResult{Failed = 0,Success = 1,SuccessRehashNeeded = 2略...

當(dāng)驗證結(jié)果是SuccessRehashNeeded時，就會重新計算新的密碼Hash存入數(shù)據(jù)庫，從而完成密碼的兼容升級

②AccessFailedCount計數(shù)、LockoutEnd時間

ASP.NET Core Identity Hands On（1）——Identity 初次體驗中有講解

Claim、IIdentity+ClaimsIdentity、IPrincipal+ClaimsPrincipal

在過去的asp.net mvc 以及現(xiàn)在的新的 asp.net mvc core中，HttpContext都有個User屬性，可能很多開發(fā)者都沒有使用過它

namespace Microsoft.AspNetCore.Http{ ?
?
? ??public abstract class HttpContext{ ? ? ?
? ?? ??public abstract ClaimsPrincipal User { get; set; } ? ? ? ?

所以，你暫時將ClaimsPrincipal理解成User就可以，而ClaimsPrincipal中有兩個重要的屬性

namespace System.Security.Claimspublic class ClaimsPrincipal : IPrincipal{ ? ?
? ? ? ?public virtual IEnumerable<ClaimsIdentity> Identities { get; } ?
? ? ? ?
? ? ? ?public virtual IIdentity Identity { get; }

Identities是這個Principal(user)擁有的所有Identity，Identity 是這個Principal(user)擁有的最重要的Identity，而這個Identity的實際類型是ClaimsIdentity，這里就相當(dāng)于Principal是用戶，而Identity是用戶的身份證，身份證里面記錄的是這個用戶的個人信息，也就是claims

namespace System.Security.Claims{
? ?public class ClaimsIdentity : IIdentity{ ? ?
? ? ? ? ??public virtual IEnumerable<Claim> Claims { get; }

再看一下上面的三小段代碼，你應(yīng)該就能理解 Principal、Identity、Claim的關(guān)系了

③通過用戶的基本信息生成Claims 及ClaimsIdentity

在這個步驟中大部分claims都被加入到 ClaimsIdentity中，如下所示（|右側(cè)是該claim的type）

• UserName |http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

• UserId|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

• SecurityStamp（如果支持的話）|AspNet.Identity.SecurityStamp

• 存儲在數(shù)據(jù)庫中的額外Claims（如果支持的話）

這里的 claim 的type 是url，還有字符串，而之前提到的都是縮寫，這是不是很令人疑惑呢？

原因是 并沒有什么規(guī)定type是什么的標準，我們也可以自定義type，type的意義在于發(fā)放票據(jù)的一方和驗證票據(jù)的一方知道是什么意思就可以了，所以，如上

④額外的claims 以及 AspNetUserClaims 表

現(xiàn)在我們 就來解析一下我們的第二張表 AspNetUserClaims

這張表相對就比較簡單，這張表就是用于存儲額外的屬于用的claim的

其中Id是int類型，這有別于User表中Id是varchar（450）要注意一下

我們來假設(shè)一個場景

假設(shè)我們的網(wǎng)站有一個特殊的設(shè)置，就是在用戶是男性的時候，顯示一個短發(fā)logo是女性時顯示一個長發(fā)logo，我們有很多方法實現(xiàn)，如果用claim實現(xiàn)的話就是相對簡單的，我們將性別的的type定義為 gender， value定義為 1、2，那么在用戶創(chuàng)建時或者創(chuàng)建后，為用戶創(chuàng)建一條claim數(shù)據(jù)，假設(shè)用戶是女性：

Id ? ? ? ? ?:10011ClaimType ? :genderClaimValue ?:2UserId ? ? ?:071d2a6e-ac2e-4db6-8941-372a3991b912q

當(dāng)這位用戶登錄時，就會將這條數(shù)據(jù)加入到cookie票據(jù)中，成為其中的一條claim，而在用戶后續(xù)的訪問中，我們直接從cookie中拿到票據(jù)，并看到票據(jù)上寫了，這為用戶是一位女性，然后為其顯示一個長發(fā)logo

⑤生成ClaimPrincipal

這是一個一步的操作

CalimsIdentity id = await GenerateClaimsAsync(user);return new ClaimsPrincipal(id);

就像我們把A用戶的身份證交到了A的手中，然后把A交還給了調(diào)用方，這很好理解

⑥添加認證方法Claim

Principal.Identities.First().AddClaim(new Claim(ClaimTypes.AuthenticationMethod, authenticationMethod));

這一步是將使用的認證方法添加到了 Identity中，它的type 是

http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod

不過登陸過程中，這個值是null，所以他沒有真的添加到Identity中

⑥ 和⑦

在表格中我們能看到⑥ 和⑦的范圍已經(jīng)不再Identity里了，所以Identity的任務(wù)已經(jīng)結(jié)束了，Identity就把用戶Principal做好，身份證Identity做好，身份證上的信息Claim填好，就結(jié)束了。接下來選擇哪個用于用戶登錄的handler，handler怎么做才能讓用戶登錄，Identity就不知道了，因為Identity是成員系統(tǒng)，而用戶登錄屬于web框架，舉一個反例，不用Identity就不能使用cookie登陸了嗎？答案顯然不是的，所以成員系統(tǒng)知道用戶是誰，將用戶信息做成一個票據(jù)，交給web框架

離開 Identity之后第一件事就是確保上一個單元格中的認證方法不是空，可是剛剛明明說了，它是null

沒錯當(dāng)它是null 的時候，會去尋找默認的authentication schema（這是認證方法的另一個名字），在startup 類中，注冊Identity的服務(wù)時，Identity還注冊了cookie authentication handler 順便還添加了 默認的 authentication scheme 我們看一個精簡版的代碼片段

public static IdentityBuilder AddIdentity<TUser, TRole>(略...) {services.AddAuthentication(options =>{ ? ? ? ?// 略...options.DefaultAuthenticateScheme = IdentityConstants.ApplicationScheme;}).AddCookie(IdentityConstants.ApplicationScheme, o =>{ ? ? ? ?// 略...})

ApplicationScheme的切實的默認值是Identity.Application,如果你不太能理解這一小節(jié)的內(nèi)容，沒關(guān)系，你只需要知道表格中做了什么事就可以，關(guān)于 身份認證 authentication 是個不算簡單的過程，后續(xù)會撰文專門講解

最后就是加密和將cookie寫入http響應(yīng)了，這段就不展開講了，就是一些基本操錯，而加密過程和配置 密鑰，后面會有單獨的講解章節(jié)

原文地址:?

https://www.cnblogs.com/rocketRobin/p/9077523.html

---

.NET社區(qū)新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結(jié)

以上是生活随笔為你收集整理的ASP.NET Core Identity Hands On（2）——注册、登录、Claim的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。