程式師世界 >> 編程語言 >> .NET網頁編程 >> 關於.NET >> 詳解ASP.NET Core 之 Identity 入門（二），asp.netidentity

詳解ASP.NET Core 之 Identity 入門（二），asp.netidentity

編輯：關於.NET

詳解ASP.NET Core 之 Identity 入門（二），asp.netidentity

前言

在上篇文章中講了關於 Identity 需要了解的單詞以及相對應的幾個知識點，並且知道了Identity處在整個登入流程中的位置，本篇主要是在 .NET 整個認證系統中比較重要的一個環節，就是認證（Authentication），因為想要把 Identity 講清楚，是繞不過 Authentication 的。

其實 Identity 也是認證系統的一個具體使用，大家一定要把 Authentication 和 Identity 當作是兩個東西，一旦混淆，你就容易陷入進去。

下面就來說一下 ASP.NET Core 中的認證系統是怎麼樣一回事。不要怕，其實很簡單，全是干貨~

Getting Started

大家應該還記得在上一篇中的奧巴馬先生吧，他現在不住在華盛頓了，他到中國來旅游了，現在住在北京，這幾天聽說西湖風景不錯，於是在 12306 定了一張北京到杭州的高鐵票。取到票之後，他向我們展示了一下：

今天是11.11號，奧巴馬很開心，原因你懂的。快到出發的時間了，於是，拿著票走到了火車站檢票口，剛把身份證和火車票遞給檢票員。“cut”，導演喊了一聲。尼瑪原來是在拍電影呢~

導演說：奧巴馬，你演的太爛了，別演了，你來演檢票員吧，讓旁邊小李來演要出行路由的奧巴馬吧。奧巴馬不情願的說了一聲：“好吧，希望小李能夠受的了你”。

“action”，導演又喊了一聲，故事開始了~

AuthenticationManager

奧巴馬當了檢票員以後，特別高興，因為他有權利了呀，他可以控制別人能不能上車了，說不定還能偷偷放幾個人進去撈點外快呢。

得知了他能干什麼以後，他覺得檢票員這個名字簡直太 low 了，很快，他就有了一個新的高大上的名字，叫：認證管理員（AuthenticationManager），而且，他覺得他自己應該處在整個核心位置，為什麼呢？你想想看，那麼龐大的一套鐵路載人系統，能不能有收入有錢賺，全靠他給不給放人進去，如果一個人都不放進去，另外那一大幫人只能去喝西北風了。

到這裡，聰明的同學可能已經知道奧巴馬把他自己放在怎麼樣一個核心位置了。對，他把自己放到了 HttpContext 裡面。怎麼樣？夠核心吧。

這裡延伸第一個知識點：AuthenticationManager 所處的位置

有同學在上面的截圖裡面發現了 public abstract ClaimsPrincipal User { get; set; }，這不就是我們上一篇中講到的 “ 證件當事人 ” ，現在小李扮演的那個角色麼？對，這個 User 就是本文中的小李，被你提前發現他躲著這裡了，嘿嘿。

還有一個知識點，就是 AuthenticationScheme，什麼意思呢？且看
奧巴馬敢把自己放在這麼核心的位置也是有他的能力的，怎麼講呢？比如說在檢票的時候，別人遞過來一張身份證和一張火車票，那怎麼樣驗證這兩個證件是合法的呢？以下就是奧巴馬提出的針對兩種證件的驗證方案：

方案1、針對身份證的驗證，可以查看其本人是否和身份證頭像是否一致，年齡是否符合當事人具體年齡。

方案2、針對火車票的驗證，可以看車次，時間是否符合發車目標，另外可以看車票上的身份號碼是否和身份證一致。

其中，這每一種方案，就對應一個 AuthenticationScheme（驗證方案名稱），是不是明白了。

這就是第二個知識點 AuthenticationScheme 很重要。

知道了奧巴馬的職責後，就很容易的把代碼寫出來了：

public abstract class AuthenticationManager
{

  //AuthenticateContext包含了需要認證的上下文，裡面就有小李
  public abstract Task AuthenticateAsync(AuthenticateContext context);
  
  //握手
  public abstract Task ChallengeAsync(string authenticationScheme, AuthenticationProperties properties, ChallengeBehavior behavior);
  
  //登入
  public abstract Task SignInAsync(string authenticationScheme, ClaimsPrincipal principal, AuthenticationProperties properties);
  
  //登出
  public abstract Task SignOutAsync(string authenticationScheme, AuthenticationProperties properties);
}

奧巴馬做為一個檢票員，有一個認證方法，AuthenticateAsync() ，注意這是其一個核心功能，其他幾個都可以沒有，但是唯獨不能沒有這個功能，沒有的話他就不能稱之為一個檢票員了。

然後還有一個握手ChallengeAsync，登入SignInAsync和登出SignOutAsync，下面說說筆者對這三個方法的理解吧。

ChallengeAsync：是社區協議文件 RFC2167 定義的關於在HTTP Authentication 過程中的一種關於握手的一個過程，主要是摘要認證（digest authentication）。

是不是有點專業，看不懂，沒事，有通俗版本的。小李要進站了，這個時候小李問了一下我們的檢票員奧巴馬先生。

小李：“你好，檢票員，我可以進站嗎？”
檢票員奧巴馬：“要趕火車嗎？可以啊，請出示你的證件？”
小李：“好的，這是我的證件，你檢查一下？”
檢票員奧巴馬：“嗯，證件沒問題，進去吧”

這樣一個過程就是握手（digest-challenge）或者叫問答的一個過程，明白了 ChallengeAsync 的原理了吧? 是不是很簡單。

SignInAsync，SignOutAsync：個人覺得這兩個不應該放在這裡，因為並不屬於認證的職責，也不屬於協議規定的內容。但是這兩個方法確實需要抽象，應該單獨抽取一個接口存放，至於為什麼這樣做，或許是因為以下原因：

1、對登入登出的抽象是和認證緊密結合的，大多數情況下認證資料的保存是需要在SignIn進行的，比如 Cookies Authentication 中間件就在SignIn方法裡面做了Cookie的保存。

2、 AuthenticationManager 這個對象是處在 HttpContext

上下文裡面的，本著面向抽象和封裝的原則，放到其裡面是合適的，這樣能夠很方便的用戶對其調用。

關於 AuthenticationManager 已經介紹完了，是不是很簡單呢？

IAuthenticationHandler

有些同學可能會問了，如果 AuthenticationManager 不提供接口的話，只是一個抽象類的話，那如果自定義認證方法就必須繼承它，這對於開發者來說是不友好的，也違背了面向接口編程的理念。嗯，確實是這樣，那麼接口來了：

public interface IAuthenticationHandler
{
  void GetDescriptions(DescribeSchemesContext context);

  Task AuthenticateAsync(AuthenticateContext context);

  Task ChallengeAsync(ChallengeContext context);

  Task SignInAsync(SignInContext context);

  Task SignOutAsync(SignOutContext context);
}

這個接口是在 AuthenticationManager 實現類 DefaultAuthenticationManager 中延伸出來的，所以大家不用再去看裡面的源碼了，記住以後如果需要重寫認證相關的東西，實現IAuthenticationHandler就可以了。

Authentication 中間件

對 IAuthenticationHandler 的初步實現，封裝了 AuthenticationHandler 這個抽象類，把具體的核心功能都交給下游去實現了，下面的CookieAuthentication 中間件核心類 CookieAuthenticationHandler 就是繼承自AuthenticationHandler，知道這麼多就夠了。

CookieAuthentication 中間件

故事還要繼續，奧巴馬在接到小李遞來的身份證和火車票之後，首先拿著火車票在一個二維碼機器上掃描了一下，然後又拿著身份證在一個機器上刷了一下，經過核查，發現都沒有問題。於是拿起印章在上面蓋了一個 “ 驗訖 ”。

這中間都發生了什麼呢？

首先，在二維碼掃描的過程，這個過程二維碼機器會解析你火車票上的二維碼，如果發現解析失敗，會直接響應認證失敗。也就是你別想進站了。

如果解析成功，就會得到你這個票據中的信息了，然後拿到你票據裡面的的當事人信息進行驗證是否被列為了鐵路局黑名單中。

如果驗證通過，則會給你頒發一個識別碼，把符合你身份的一個識別碼寫入到你的火車票中和檢票員旁邊的電腦系統中，即 “ 驗訖 ”。

話說這個驗訖有點高級，它會向你的火車票芯片中寫入一些信息，那麼都寫入些什麼信息呢？ 1、奧巴馬個人的信息。2、驗證途中的一些上下信息。3、使用的驗證方案。

知道了，這些之後，那麼就很容易實現這個驗證方法了，對吧？以下是 CookieAuthentication 中間件中的核心類 CookieAuthenticationHandler 的裡面的核心方法HandleAuthenticateAsync()，同樣你可以理解為實現的 IAuthenticationHandler 接口的 AuthenticateAsync：

protected override async Task<AuthenticateResult> HandleAuthenticateAsync()
{
  // 解析二維碼
  var result = await EnsureCookieTicket();
  if (!result.Succeeded)
  {
    return result;
  }

  // 從二維碼中拿當事人信息進行驗證
  var context = new CookieValidatePrincipalContext(Context, result.Ticket, Options);
  await Options.Events.ValidatePrincipal(context);

  if (context.Principal == null)
  {
    return AuthenticateResult.Fail("No principal.");
  }

  if (context.ShouldRenew)
  {
    RequestRefresh(result.Ticket);
  }
  
  // 驗訖， 寫入芯片
  return AuthenticateResult.Success(new AuthenticationTicket(context.Principal, context.Properties, Options.AuthenticationScheme));
}

HandleSignInAsync

我們故事繼續……

奧巴馬檢票完成之後，把票就交給了小李，小李拿到票之後，導演又喊了一聲：“ cut ”……

怎麼又停了，小李和奧巴馬一肚子的疑惑，導演說：“ 奧巴馬呀，你檢票員演的不錯，還是繼續扮演你的本職角色吧，演好了中午盒飯給你雙份，小李，你來演檢票員吧 ”。
可以吃兩份盒飯了，奧巴馬聽後心裡還是很開心。

“action” 導演喊了一聲……

奧巴馬接過票，向著車站裡面的列車停車處走去，走到了列車門口要進去的時候，又出現了一個人，奧巴馬知道，這個人就是做車內乘客登記的（ps: 一般情況下，做乘客登記都是在列車行駛的過程中，在這裡我們假設這個做乘客登記的人比較勤快，就在車門口守著），登記完成之後就讓奧巴馬進去了。

那麼，登記這個過程中都干了些什麼呢？

首先，登記員的手持設備會解析火車票票裡面寫入芯片中的信息，發現沒有問題，就開始向自己手裡面的登記本登記信息了，主要包含車票主人信息，過期時間，審核人等。

這樣整個過程就是 HandleSignInAsync 的一個過程，換成程序術語就是，組裝 Cookie 登入上下文信息，寫入到 Http 流的 header 中，也就寫入到了客戶端浏覽器cookie。

至此，整個過程就完了，我們來看一下代碼：

//方法裡面的流程，我只列出了核心部分，影響閱讀的全刪了
protected override async Task HandleSignInAsync(SignInContext signin)
{
  // 解析芯片中的信息
  var result = await EnsureCookieTicket();
  
  // 組織登入上下文，設置過期時間等
  // 使用 data protected 加密登記本上的信息
  var cookieValue = Options.TicketDataFormat.Protect(ticket);

  // 寫入到浏覽器header
  await ApplyHeaders(cookieValue);
}

不想深入了解的可以忽略這部分內容：

在 HandleSignInAsync 這個函數的源碼中，其中有一個很巧妙的設計, 就是 await Options.Events.SignedIn(signedInContext); 這樣一句代碼，干什麼用的呢？而且前後一共調用了兩次，有同學知道是為什麼嗎？我准備在下一篇中給出答案。

還記得前面 HttpContext 中的ClaimsPrincipal User嗎？就是小李臨時頂替的那個角色，現在有值了，他就是是奧巴馬了。

奧巴馬在座位上坐好之後，經過6個小時的路程就從北京到杭州了，不得不佩服中國高鐵的速度呀，在欣賞晚西湖的風景後，奧巴馬給我們傳來了一張照片：

至此，CookieAuthentication 中間件的整個工作流程已經講完了，故事也結束了。

以上，就是這兩行代碼背後的故事：

var user = new ClaimsPrincipal(new ClaimsIdentity(new[] { new Claim(ClaimTypes.Name, "奧巴馬") }, CookieAuthenticationDefaults.AuthenticationScheme));
await HttpContext.Authentication.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, user);

總結

在本篇中我們知道了 AuthenticationManager，也知道了 IAuthenticationHandler 並且簡單的介紹了一下 Authentication 中間件和 CookieAuthentication 中間件，其中 CookieAuthentication 中間件是我們以後使用最多的一個中間件了，本篇也對其做了一個詳細的介紹，我想通過本篇文章在以後使用的過程中應該問題不大了。

有同學可能會問了，講了這麼多認證的東西它和 Identity 有什麼關系呢？難道我通篇都在隱藏他和 Identity 的關系你沒看出來？。。。。真的想知道？看下一篇吧。