ASPNET-ASPNETCORE 認證

 

話題背景

關於認證我的個人理解是，驗證信息的合法性。在我們生活當中，比如門禁，你想進入一個有相對安全措施的小區或者大樓，你需要向保安或者門禁系統提供你的身份信息證明，只有確定你是小區業主，才可以進來，我這只是打個比方啊，不要糾結。對於我們計算機的安全領域，認證其實也非常類似，windows系統登陸就是一個很好的例子。今天我們主要學習的是ASPNET以及ASPNETCORE平台上面一些主流的認證方式。

正式話題-認證

我最開始接觸NET平台的WEB框架是從APSNETWEBFORM開始->ASPNETMVC->ASPNETMVCCORE，下面我們就從WEBFORM開始吧（包括MVC1.x-4.x）。在MVC5之前，我們常用的認證方式有，Forms、Windows、Passport、None這三種認證方式，嚴格意義上說是三種，None為不認證，而在這三種認證方式當中，我們最常用的就是Forms表單認證，下面我們一起來看看Forms表單認證的實現原理。

Forms表單認證

我會以我自己的使用方式介紹再到實現原理。整個Forms認證的實現邏輯大概是，說到Forms認證我們就不得不說ASPNET處理管道，為什么這么說呢？因為ASPNET的很多基礎功能都是通過相應的HttpModule實現的，比如認證、授權、緩存、Session等等。ASPNET平台的Forms認證就是基於FormsAuthenticationModule模塊實現，相應的Windows認證也是一樣，由WindowsAuthenticationModule實現。對於Forms認證方式登錄而言。

1.匹配用戶名&密碼是否正確。
2.構建FormsAuthenticationTicket對象。

3.通過FormsAuthentication.Encrypt方法加密Ticker信息。
4.基於加密Ticker信息，構建HttpCookie對象。
5.寫入Response，輸出到客戶端。
以上就是我們基於Forms表單認證方式的登錄實現邏輯，下面我們來梳理一下認證的大概實現邏輯，針對每次請求而言。
1.在ASPNET管道生命周期里，認證模塊FormsAuthenticationModule會接管並讀取Cookie。
2.解密Cookie獲取FormsAuthenticationTicket對象並且驗證是否過期。
3.根據FormsAuthenticationTicket對象構造FormsIdentity對象並設置HttpContext.User。
4.完成認證。
下面我們一起看看Forms認證的具體實現，我會以我自己開發過程中使用的方式加以介紹。首先我們會在web.config文件里面定義authentication配置節點，如下。

<authentication mode="Forms">
      <forms name="AUTH" loginUrl="~/login" protection="All" timeout="43200" path="/" requireSSL="false" slidingExpiration="true" />
    </authentication>

 

mode屬性對應了4屬性值，除Forms以外還有上面我提到的三種方式。其他三種由於篇幅問題，在這里不做介紹。這些屬性我相信大家應該都比較熟悉。下面我們看看關於Forms認證具體的后台代碼。看代碼。

public virtual void SignIn(User user, // 這個user是你校驗合法性之后的這么一個用戶標識對象
bool createPersistentCookie)
        {
            var now = DateTime.UtcNow.ToLocalTime();
            // 構建Ticker對象
            var ticket = new FormsAuthenticationTicket(
                1 ,
               user.Username,
                now,
                now.Add(_expirationTimeSpan),
                createPersistentCookie,
                user.Username,
                FormsAuthentication.FormsCookiePath);
            // 加密ticker對象
            var encryptedTicket = FormsAuthentication.Encrypt(ticket);
            // 通過加密ticker對象構建HttpCookie對象
            var cookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);
            cookie.HttpOnly = true;
            if (ticket.IsPersistent)
            {
                cookie.Expires = ticket.Expiration;
            }
            cookie.Secure = FormsAuthentication.RequireSSL;
            cookie.Path = FormsAuthentication.FormsCookiePath;
            if (FormsAuthentication.CookieDomain != null)
            {
                cookie.Domain = FormsAuthentication.CookieDomain;
            }
            // 寫入輸出流Response
            _httpContext.Response.Cookies.Add(cookie);
        }

 

以上代碼就完成了我們的Forms認證所需的Cookie信息，可能有些朋友在以往開發WebForms到4.x最常用的使用方式是FormsAuthentication.SetAuthCookie(user.UserName, true)，其實SetAuthCookie里面的實現邏輯跟上面實現大同小異，只是我比較喜歡手動創建可以更多的控制一些輔助信息而已。在以上代碼片段中，我着重想介紹一下FormsAuthentication.Encrypt(ticket)加密方法，因為它涉及到了Forms認證的安全機制，也好讓各位朋友大概了解Forms認證到底安全不安全。FormsAuthentication該對象位於System.Web.Security名稱空間下面，主要作用是安全相關輔助工具類，比如加解密等。
1.在默認情況下，ASPNETFORMS認證模塊針對Ticker的加密Key是由ASPNET隨機生成，並存儲在本地安全機構LSA中。我們可以通過一下代碼片段驗證這一邏輯。

private CryptographicKey GenerateCryptographicKey(string configAttributeName, string configAttributeValue, int autogenKeyOffset, int autogenKeyCount, string errorResourceString)
    {
       // 其他代碼
      bool flag1 = false;
      bool flag2 = false;
      bool flag3 = false;
      if (configAttributeValue != null)
      {
        string str1 = configAttributeValue;
        char[] chArray = new char[1]{ ',' };
        foreach (string str2 in str1.Split(chArray))
        {
          if (!(str2 == "AutoGenerate"))
          {
            if (!(str2 == "IsolateApps"))
            {
              if (!(str2 == "IsolateByAppId"))
              flag3 = true;
            }
            else
              flag2 = true;
          }
          else
            flag1 = true;
        }
      }
      if (flag2)
        MachineKeyMasterKeyProvider.AddSpecificPurposeString((IList<string>) stringList, "IsolateApps", this.ApplicationName);
      if (flag3)
        MachineKeyMasterKeyProvider.AddSpecificPurposeString((IList<string>) stringList, "IsolateByAppId", this.ApplicationId);
    }

 

以上代碼片段邏輯也比較簡單，自己體會吧。
2.手動指定machineKey配置節點，該配置節在web.config文件里面，其中包括可支持的加密算法，加密算法支持DES，3DES，AES等。具體代碼我就不貼了，我們跟蹤其實現原理意在了解Forms認證其安全性。
3.通過以上兩點介紹，我個人認為Forms認證相對來說很安全。
Forms認證
下面我們看看Forms的實現原理。
ASPNET的Forms認證發生在ASPNET管道的FormsAuthenticationModule對象里面，在該對象里面的Init方法里面綁定了認證事件OnEnter，具體的認證實現是OnEnter里面調用的OnAuthenticate方法。我們來看下代碼。

private void OnAuthenticate(FormsAuthenticationEventArgs e)
    {
         // 其他代碼
        bool cookielessTicket = false;
        // 從請求cookie里面抽取ticker票據信息
        FormsAuthenticationTicket ticketFromCookie = FormsAuthenticationModule.ExtractTicketFromCookie(e.Context, FormsAuthentication.FormsCookieName, out cookielessTicket);
        // 過期或者為null直接返回
        if (ticketFromCookie == null || ticketFromCookie.Expired)
          return;
        FormsAuthenticationTicket ticket = ticketFromCookie;
        // 如果啟用滑動過期，更新過期時間
        if (FormsAuthentication.SlidingExpiration)
          ticket = FormsAuthentication.RenewTicketIfOld(ticketFromCookie);
        e.Context.SetPrincipalNoDemand((IPrincipal) new GenericPrincipal((IIdentity) new FormsIdentity(ticket), new string[0]));
        if (!cookielessTicket && !ticket.CookiePath.Equals("/"))
        {
          cookie = e.Context.Request.Cookies[FormsAuthentication.FormsCookieName];
          if (cookie != null)
            cookie.Path = ticket.CookiePath;
        }
        if (ticket == ticketFromCookie)
          return;
        if (cookielessTicket && ticket.CookiePath != "/" && ticket.CookiePath.Length > 1)
          ticket = FormsAuthenticationTicket.FromUtc(ticket.Version, ticket.Name, ticket.IssueDateUtc, ticket.ExpirationUtc, ticket.IsPersistent, ticket.UserData, "/");
        string cookieValue = FormsAuthentication.Encrypt(ticket, !cookielessTicket);
        
        if (cookielessTicket)
        {
          e.Context.CookielessHelper.SetCookieValue('F', cookieValue);
          e.Context.Response.Redirect(e.Context.Request.RawUrl);
        }
        else
        {
          if (cookie != null)
            cookie = e.Context.Request.Cookies[FormsAuthentication.FormsCookieName];
          if (cookie == null)
          {
            cookie = new HttpCookie(FormsAuthentication.FormsCookieName, cookieValue);
            cookie.Path = ticket.CookiePath;
          }
          if (ticket.IsPersistent)
            cookie.Expires = ticket.Expiration;
          cookie.Value = cookieValue;
          cookie.Secure = FormsAuthentication.RequireSSL;
          cookie.HttpOnly = true;
          if (FormsAuthentication.CookieDomain != null)
            cookie.Domain = FormsAuthentication.CookieDomain;
          cookie.SameSite = FormsAuthentication.CookieSameSite;
          e.Context.Response.Cookies.Remove(cookie.Name);
          e.Context.Response.Cookies.Add(cookie);
        }
    } 

 

以上代碼片段反映了Forms認證具體邏輯，邏輯比較簡單，我也大概做了一些注釋，以上就是ASPNET在MVC5.x之前ASPNETForms認證的實現。接下來我們對ASPNET5.X之前的版本基於Forms認證做個簡單的總結。
1.用戶在未登錄的情況下，訪問我們受保護的資源。
2.FormsAuthenticationModule模塊驗證用戶的合法性，主要是生成Identity對象和設置IsAuthenticated屬性。
3.如果未登錄則endrequest階段跳轉到web.config配置的登錄頁或者硬編碼指定的登錄頁。
4.用戶登錄。
5.匹配用戶名&密碼，如果合法，生成ticker票據和cookie並寫入response。
6.訪問受保護的資源（授權部分）。
7.FormsAuthenticationModule模塊驗證用戶的合法性。
8.如果為以認證用戶IsAuthenticated=true，授權訪問相應的資源。
后續的每次請求也是6，7，8循環。
針對Forms認證就此告一段落，下面我們接着介紹MVC5的常規認證方式。
MVC5Cookies認證方式
為什么我要把MVC5的認證方式單獨做一個小結講解呢？它有什么特別之處嗎？沒錯，ASPNETMVC5引入了新的設計理念OWin，我個人的理解是，解耦webserver容器IIS和模塊化。同時NET4.5也引入了ASPNET.Identity，Identity主要是提供幫助我們管理用戶、角色以及存儲，當然Identity相較Membership強大多了。對於OWin和Identity我在這里不做詳細介紹，自己可以去搜一些帖子看或者查看官方文檔。OWin在WebServers與ASPNETWebApplication之間定義了一套標准接口，其官方的開源實現是Katana這個開源項目，我們今天要介紹的MVC5的認證就是基於Katana這個開源項目的CookieAuthenticationMiddleware中間件實現的，在介紹CookieAuthenticationMiddleware中間件之前，我想簡單羅列一下MVC5的cookies認證（你也可以認為是Katana實現的新的Forms認證）和我們早期使用的Forms認證做個簡單的對比。
相同點：1.基於cookie認證 2.支持滑動過期策略 3.實現令牌保護 4.重定向。
不同點：Identity結合Owin實現了聲明認證Claims-based。
以上是個人的一點理解，下面我們具體看看認證中間件的實現，CookieAuthenticationMiddleware的定義。

public class CookieAuthenticationMiddleware : AuthenticationMiddleware<CookieAuthenticationOptions>
    {
        // 其他成員
        public CookieAuthenticationMiddleware(OwinMiddleware next, IAppBuilder app, CookieAuthenticationOptions options)
            : base(next, options)
        {
        }
        // 創建具體的AuthenticationHandler
        protected override AuthenticationHandler<CookieAuthenticationOptions> CreateHandler()
        {
            return new CookieAuthenticationHandler(_logger);
        }
    }

 

CookieAuthenticationMiddleware里面就一個方法成員，通過CreateHandler方法創建了具體的CookieAuthenticationHandler對象，我們的認證核心實現就發生在這個Handler里面。接下來我們看看CookieAuthenticationHandler對象的定義。

internal class CookieAuthenticationHandler : AuthenticationHandler<CookieAuthenticationOptions>
    {
        // 其他成員
        private const string HeaderNameCacheControl = "Cache-Control";
        private const string HeaderNamePragma = "Pragma";
        private const string HeaderNameExpires = "Expires";
        private const string HeaderValueNoCache = "no-cache";
        private const string HeaderValueMinusOne = "-1";
        private const string SessionIdClaim = "Microsoft.Owin.Security.Cookies-SessionId";

        private bool _shouldRenew;
        private DateTimeOffset _renewIssuedUtc;
        private DateTimeOffset _renewExpiresUtc;
        private string _sessionKey;
        
        protected override async Task<AuthenticationTicket> AuthenticateCoreAsync()
        
        protected override async Task ApplyResponseGrantAsync()
        
        protected override Task ApplyResponseChallengeAsync()
    }

 

從CookieAuthenticationHandler對象的定義來看，其實也能看出一二，主要是針對cookie的相關操作，在該對象成員里面我們需要了解一下其中的三個方法。
1.AuthenticateCoreAsync，代碼我就不貼了，有興趣的朋友可以自己查看Katana開源項目的源代碼。該方法內部大概實現思路是：從IOWinContext對象獲取cookie，如果對owin不怎么熟悉的話，這個context你可以把它理解為我們之前熟悉的HttpContext，然后通過解密出來的cookie字符串構造ClaimsIdentity對象並添加到OwinContext對象Request.User，最后返回AuthenticationTicket對象，該對象包裝的就是當前用戶信息以及相關輔助信息。
2.ApplyResponseGrantAsync，設置、更新或者刪除cookie並寫入response。
3.ApplyResponseChallengeAsync，授權失敗，發生重定向。

public class AuthenticationTicket
    {
        public AuthenticationTicket(ClaimsIdentity identity, AuthenticationProperties properties)
        {
            Identity = identity;
            Properties = properties ?? new AuthenticationProperties();
        }
        // 用戶信息
        public ClaimsIdentity Identity { get; private set; }
        // 輔助信息，比如會話、過期等
        public AuthenticationProperties Properties { get; private set; }
    }

 

下面我們一起看看在我們開發過程中的應用以及內部實現
Startup是Katana開源項目引入的一種新的模塊初始化方式，其實也沒什么特別的，就是相關中間件的注冊以及一些默認上下文對象的初始化操作。下面我們具體看代碼，我們的MVC5新的認證方式在Startup里面如何注冊的。

public partial class Startup
    {
        public void ConfigureAuth(IAppBuilder app)
        {
            // 其他代碼
            app.UseCookieAuthentication(new CookieAuthenticationOptions
            {
                AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
                LoginPath = new PathString("/Account/Login"),
                Provider = new CookieAuthenticationProvider
                { }
            });           
        }
    }

 

注冊邏輯很簡單，通過IAppBuilder的擴展方法UseCookieAuthentication實現，接下來我們看看UseCookieAuthentication擴展方法的內部實現。

public static IAppBuilder UseCookieAuthentication(this IAppBuilder app, CookieAuthenticationOptions options, PipelineStage stage)
        {
            if (app == null)
            {  }
            // 注冊
            app.Use(typeof(CookieAuthenticationMiddleware), app, options);
            // 加入owin管道
            app.UseStageMarker(stage);
            return app;
        }

 

整個注冊邏輯就這么幾行代碼，相關方法都有注釋。最后在程序初始化過程中通過Build方法完成Owin管道所有中間件的初始化工作。接下來我們看看具體的登錄實現。

public async Task<ActionResult> Login(LoginModel model,string returnUrl)
{
    // 其他代碼
    if (ModelState.IsValid)
    {
        AppUser user = await UserManager.FindAsync(model.Name, model.Password);
        if (user==null)
        {
            ModelState.AddModelError("","無效的用戶名或密碼");
        }
        else
        {
            var claimsIdentity =
                await UserManager.CreateIdentityAsync(user, DefaultAuthenticationTypes.ApplicationCookie);
            AuthManager.SignIn(new AuthenticationProperties {IsPersistent = false}, claimsIdentity);
            return Redirect(returnUrl);
        }
    }
 
    return View(model);
}

 

通過以上代碼片段就完成了我們系統的登錄操作，在以上Login方法里面，我們需要注意這么幾個方法。
1.FindAsync主要是通過Identity實現用戶名和密碼的匹配。
2.CreateIdentityAsync主要是創建ClaimsIdentity對象，該對象后續會寫入cookie。
3.SignIn包裝CreateIdentity方法創建的ClaimsIdentity以及ClaimsPrincipal對象，為cookie寫入Response提供相關認證信息，只有在設置cookie階段才會寫入response。
接下來我們針對Katana里面的cookie認證做個簡單的總結。
1.用戶在未登錄的情況下，訪問我們受保護的資源。
2.CookieAuthenticationMiddleware中間件驗證用戶的合法性。
3.用戶登錄。
4.匹配用戶名&密碼，如果合法，包裝相關認證信息。
5.創建\更新cookie寫入response。
6.訪問受保護的資源。
7.CookieAuthenticationMiddleware中間件解密cookie驗證用戶認證信息。
8.如果為以認證用戶，授權訪問相應的資源。
后續的每次請求也是6，7，8循環。
以上MVC5新的Cookies認證方式就此告一段落，下面我們接着介紹ASPNET.Identity三方認證。
三方認證
在我們介紹三方認證之前，我們不妨先來了解一下什么是Claim，大家把它翻譯成聲明，我也就這么跟着叫把。Claim所描述的是一個用戶單一的某個信息，比如用戶名，只有多個Claim組合才能描述一個完整的用戶ClaimsIdentity對象。個人理解這是一種通用的信息存儲結構，一種規范，可以很方便的基於用戶數據信息驅動認證和授權並且提供獨立服務，各自都不需要關心自己的實現。在我們傳統的認證windows或者forms認證方式中，每個系統都有自己認證方式、授權和用戶數據信息，如果是幾年以前，可能沒有什么問題，但是在如今飛速發展的互聯網時代，就顯的有很大的局限性、擴展性以及安全性。接下來我們要介紹的就是MVC5基於ASPNET.Identity結合Katana實現的三方認證，也就是我們上面說的基於Claims-based實現第三方認證，這里我們以google認證為例，由於網絡問題這里我們以木宛城主大拿的實例代碼做示例，我會結合實例代碼分析內部實現。
首先我們需要添加google服務認證中間件。

app.UseGoogleAuthentication(new GoogleOAuth2AuthenticationOptions()
{
     // 以下為客戶端憑據，可以通過google認證服務注冊
    ClientId = "",
    ClientSecret = "",
});

 

其二我們需要設計實現登錄邏輯，通常情況下我們在登錄論壇的時候，旁邊可能會有基於QQ登錄或者別的三方認證提供商。

public ActionResult GoogleLogin(string returnUrl)
{    // 創建AuthenticationProperties對象，我們可以理解為認證復制信息字典
    var properties = new AuthenticationProperties
    {    
        RedirectUri = Url.Action("GoogleLoginCallback",
        new { returnUrl = returnUrl })
    };
    // 初始化google認證相關輔助信息
    HttpContext.GetOwinContext().Authentication.Challenge(properties, "Google");
    // 返回401
    return new HttpUnauthorizedResult();
}

 

以上代碼比較簡單，我也做了相應的注釋，其邏輯是初始化google認證的一些輔助信息，然后返回401狀態碼，繼而重定向到google登錄頁。下面我們看看登錄成功之后的代碼邏輯。

public async Task<ActionResult> GoogleLoginCallback(string returnUrl)
{
    // 從google認證服務獲取claims
    ExternalLoginInfo loginInfo = await AuthManager.GetExternalLoginInfoAsync();
    // 檢查該用戶是否首次登錄系統
    AppUser user = await UserManager.FindAsync(loginInfo.Login);
    if (user == null)
    {
        user = new AppUser
        {
            Email = loginInfo.Email,
            UserName = loginInfo.DefaultUserName,
            City = Cities.Shanghai,
            Country = Countries.China
        };
        // 持久化用戶數據
        IdentityResult result = await UserManager.CreateAsync(user);
        // 緩存
        result = await UserManager.AddLoginAsync(user.Id, loginInfo.Login);
    }
    ClaimsIdentity ident = await UserManager.CreateIdentityAsync(user,
        DefaultAuthenticationTypes.ApplicationCookie);
    ident.AddClaims(loginInfo.ExternalIdentity.Claims);
    // 創建用戶ClaimsIdentity對象
    AuthManager.SignIn(new AuthenticationProperties
    {
        IsPersistent = false
    }, ident);
    return Redirect(returnUrl ?? "/");
}

 

以上就是三方認證的實現方式，下面我們通過Katana源碼看看三方認證的實現原理。通過上面Katana的cookies認證，我們了解到認證中間件的認證邏輯是實現在相應的AuthenticationHandler里面，我們同樣以google為例，去看看內部的實現。下面我們一起來上面注冊的認證中間件GoogleOAuth2AuthenticationMiddleware的定義。

public class GoogleOAuth2AuthenticationMiddleware : AuthenticationMiddleware<GoogleOAuth2AuthenticationOptions>
    {
        // 其他成員
        public GoogleOAuth2AuthenticationMiddleware(
            OwinMiddleware next,
            IAppBuilder app,
            GoogleOAuth2AuthenticationOptions options)
            : base(next, options);
        // 構建認證handler
        protected override AuthenticationHandler<GoogleOAuth2AuthenticationOptions> CreateHandler()
        {
            return new GoogleOAuth2AuthenticationHandler(_httpClient, _logger);
        }
        // 構建httpclienthandler
        private static HttpMessageHandler ResolveHttpMessageHandler(GoogleOAuth2AuthenticationOptions options)；
    }

 

根據以上代碼片段我們了解到，GoogleOAuth2AuthenticationMiddleware中間件似乎比我們常規的cookies認證多了一個方法ResolveHttpMessageHandler，其實這個方法沒有別的套路，就是輔助創建httpclient對象，完成http請求而已，在handler的認證邏輯里面需要獲取googletoken，就是通過它來獲取的。
第二個方法CreateHandler返回的GoogleOAuth2AuthenticationHandler對象就是我們接下來要重點討論的對象。

internal class GoogleOAuth2AuthenticationHandler : AuthenticationHandler<GoogleOAuth2AuthenticationOptions>
    {
        private const string TokenEndpoint = "https://accounts.google.com/o/oauth2/token";
        private const string UserInfoEndpoint = "https://www.googleapis.com/plus/v1/people/me";
        private const string AuthorizeEndpoint = "https://accounts.google.com/o/oauth2/auth";

        private readonly ILogger _logger;
        private readonly HttpClient _httpClient;

        public GoogleOAuth2AuthenticationHandler(HttpClient httpClient, ILogger logger)
        {
            _httpClient = httpClient;
            _logger = logger;
        }
        // 通過httpclient訪問google認證服務器獲取token，根據token數據包裝Claim
        protected override async Task<AuthenticationTicket> AuthenticateCoreAsync();
        // 如果未認證，401授權失敗發生重定向
        protected override Task ApplyResponseChallengeAsync()；

        public override async Task<bool> InvokeAsync()
        {
            return await InvokeReplyPathAsync();
        }
        // 調用signin，保存用戶信息  
        private async Task<bool> InvokeReplyPathAsync();
    }

 

代碼比較長，我把具體實現刪掉了，實現邏輯我注釋到了方法上面，有興趣的朋友可以自己多看看源碼。以上就是NET平台上面一些主流的認證方式和實現原理。接下來我們繼續介紹ASPNETCORE的認證。

ASPNETCORE認證
熟悉微軟web平台認證授權體系的朋友應該知道，不管是早期的Forms還是Katana的cookies甚至是我接下來要介紹的ASPNETCORE基於cookies認證，其實整體的設計邏輯大致都差不多，只是具體實現上的區別，尤其是OWin的設計理念，當然現在我們幾乎已經模糊了OWin的慨念，但是在ASPNETCORE平台上到處都有它的縮影。下面我們一起來看看ASPNETCOREMVC的認證機制。
在這里，整個認證邏輯我就直接用一張圖展示：

畫圖工具是網上在線編輯的，畫的不好，別見怪。下面我簡單解釋一下認證授權流程圖，以cookies認證為例。
1.認證中間件調用CookieAuthenticationHandler實現認證，如果認證成功設置HttpContext.Use對象。
2.在執行controller中的action之前，執行授權filter，如果有設置授權filter特性。
3.如果controller或者action上沒有授權filter，直接執行action，呈現view。
4.如果有定義授權filter特性，授權過濾器再次檢查用戶是否認證，並且合並Claim，因為可以指定多個認證scheme，認證階段使用的是默認的sheme。
5.認證失敗，授權filter設置context.Result為Challenge，在后續cookie認證中間件會發生重定向到login頁面。
6.認證成功，授權失敗，授權filter設置context.Result為Forbid，在后續cookie認證中間件會發生重定向到權限不足頁面。
7.認證、授權都通過，最后顯示view。
以上就是ASPNETCOREMVC認證授權的主要執行邏輯。接下來我們一起看看，基於COREMVC的cookies認證的應用以及內部實現。
熟悉ASPNETCORE平台開發的朋友應該知道，基礎功能模塊的配置初始化，一般分為兩部曲，注冊服務、配置中間件。當然這少不了NETCORE內置DI容器的功勞，我們將要介紹的認證系統也不例外。下面我們具體看看認證系統的配置，通過Startup類型配置，關於startup的提供機制可以看看我上一篇博客，有詳細介紹。
第一部曲服務配置

public static void AddAuthentication(this IServiceCollection services)
        {
        
            // 其他代碼
            var authenticationBuilder = services.AddAuthentication(options =>
            {
                options.DefaultChallengeScheme = AuthenticationDefaults.AuthenticationScheme;
                options.DefaultScheme = AuthenticationDefaults.AuthenticationScheme;
                options.DefaultSignInScheme = AuthenticationDefaults.ExternalAuthenticationScheme;
            })
            .AddCookie(AuthenticationDefaults.AuthenticationScheme, options =>
            {
                options.Cookie.Name = $"{CookieDefaults.Prefix}{NopCookieDefaults.AuthenticationCookie}";
                options.Cookie.HttpOnly = true;
                options.LoginPath = AuthenticationDefaults.LoginPath;
                options.AccessDeniedPath = AuthenticationDefaults.AccessDeniedPath;
            })
            .AddCookie(AuthenticationDefaults.ExternalAuthenticationScheme, options =>
            {
                options.Cookie.Name = $"{CookieDefaults.Prefix}{CookieDefaults.ExternalAuthenticationCookie}";
                options.Cookie.HttpOnly = true;
                options.LoginPath = AuthenticationDefaults.LoginPath;
                options.AccessDeniedPath = AuthenticationDefaults.AccessDeniedPath;
            });
        }

 

以上代碼片段就完成了cookies認證的所需服務注冊。其實際就是注冊cookies認證所需的基礎對象和輔助配置信息到DI容器，以便中間件可以通過DI容器方便獲取。AddAuthentication擴展方法，主要是注冊認證系統所需基礎對象。AddCookie擴展方法主要是注冊具體cookie認證Handler對象以及通過options模式配置輔助信息。
第二部曲中間件注冊

public static void UseAuthentication(this IApplicationBuilder application)
        {
            // 其他代碼
            application.UseMiddleware<AuthenticationMiddleware>();
        }

 

認證中間件的注冊就這么一句代碼，實際就是ASPNETCORE請求管道添加認證中間件，最后通過Build初始化到這個請求管道，后續所有的請求都會通過這個認證中間件的invoke方法處理，然后傳遞下一個中間件，關於中間件的原理也可以看我上一篇帖子。認證系統的配置我們已經准備完成，下面我們看看系統登錄。
登錄

  [HttpPost]
        public virtual IActionResult Login(LoginModel model, string returnUrl, bool captchaValid)
        {
        
            // 其他代碼
            if (ModelState.IsValid)
            {
                var loginResult = _userService.ValidateUser(model.Username, model.Password);
                switch (loginResult)
                {
                    case LoginResults.Successful:
                        {
                            var user = _userService.GetUserByUserName(model.Username);
                            
                            _authenticationService.SignIn(user, model.RememberMe);

                            return Redirect(returnUrl);
                        }
                }
            }

            return View(model);
        }

 

以上登錄代碼片段比較簡單，主要完成兩個動作，1.收集用戶輸入的用戶名&密碼等信息，然后通過我們系統的存儲介質，校驗用戶名&密碼的合法性。2.登錄到我們的認證系統，實現我們核心登錄邏輯是SignIn方法里面。下面我們繼續看看SignIn方法的具體實現。

public virtual async void SignIn(User user, bool isPersistent)
        {
            // 其他代碼
            // 創建身份信息集合
            var claims = new List<Claim>();

            if (!string.IsNullOrEmpty(user.Username))
                claims.Add(new Claim(ClaimTypes.Name, user.Username, ClaimValueTypes.String, AuthenticationDefaults.ClaimsIssuer));

            if (!string.IsNullOrEmpty(user.Email))
                claims.Add(new Claim(ClaimTypes.Email, user.Email, ClaimValueTypes.Email, AuthenticationDefaults.ClaimsIssuer));
            
            var userIdentity = new ClaimsIdentity(claims, AuthenticationDefaults.AuthenticationScheme);
            var userPrincipal = new ClaimsPrincipal(userIdentity);
            // 輔助信息
            var authenticationProperties = new AuthenticationProperties
            {
                IsPersistent = isPersistent,
                IssuedUtc = DateTime.UtcNow
            };
            // 創建cookie ticket，以備寫入response輸出到客戶端
            await _httpContextAccessor.HttpContext.SignInAsync(AuthenticationDefaults.AuthenticationScheme, userPrincipal, authenticationProperties);
        }

 

以上代碼片段就完成了我們認證系統的登錄。大致邏輯是構建身份聲明信息，調用HttpContext的SignInAsync方法創建ticket，在endrequest階段創建cookie寫入response。以上就是我們基於ASPNETCORE平台開發web應用對於認證的真實應用。接下來我們重點看看平台的內部實現。
Cookies認證內部實現
我們還是從服務注冊開始吧，畢竟它是完成認證系統的基石。我們把視線轉移到上面的AddAuthentication方法，注冊服務，我們看看它到底為我們的認證系統注冊了哪些基礎服務，看NETCORE源代碼。

public static AuthenticationBuilder AddAuthentication(this IServiceCollection services)
        {
            // 其他代碼   
            services.AddAuthenticationCore();
            services.AddDataProtection();
            services.AddWebEncoders();
            services.TryAddSingleton<ISystemClock, SystemClock>();
            return new AuthenticationBuilder(services);
        }

 

從以上代碼片段了解到，我們的認證服務注冊是在平台AddAuthenticationCore方法里面完成的。我們一起看看AddAuthenticationCore方法的實現。

public static IServiceCollection AddAuthenticationCore(this IServiceCollection services)
        {
            services.TryAddScoped<IAuthenticationService, AuthenticationService>();
            services.TryAddSingleton<IClaimsTransformation, NoopClaimsTransformation>(); // Can be replaced with scoped ones that use DbContext
            services.TryAddScoped<IAuthenticationHandlerProvider, AuthenticationHandlerProvider>();
            services.TryAddSingleton<IAuthenticationSchemeProvider, AuthenticationSchemeProvider>();
            return services;
        }

 

AddAuthenticationCore方法里面主要注冊了我們NETCORE認證系統的三個基礎對象，你可以把它們理解為黑幫的一個老大兩個堂主，由它們吩咐下面的小弟完成任務，言歸正傳這三個對象也是完成我們NETCORE平台認證的三劍客，通過Provider模式實現，下面我們一個個來介紹，我們先看看IAuthenticationService接口的定義。

public interface IAuthenticationService
    {
        Task<AuthenticateResult> AuthenticateAsync(HttpContext context, string scheme);

        Task ChallengeAsync(HttpContext context, string scheme, AuthenticationProperties properties);

        Task ForbidAsync(HttpContext context, string scheme, AuthenticationProperties properties);

        Task SignInAsync(HttpContext context, string scheme, ClaimsPrincipal principal, AuthenticationProperties properties);

        Task SignOutAsync(HttpContext context, string scheme, AuthenticationProperties properties);
    }

 

IAuthenticationService接口定義了5個方法成員，它本身不實現任何認證邏輯，只是為IAuthenticationSchemeProvider 和 IAuthenticationHandlerProvider這兩個Provider實現了封裝，提供認證服務的統一接口。下面我大概解釋一下這個5個方法在認證服務中的作用。
1.SignInAsync 登錄操作，如果登錄成功，生成加密ticket，用來標識用戶的身份。
2.SignOutAsync 退出登錄，清除Coookie等。
3.AuthenticateAsync 解密cookie，獲取ticket並驗證，最后返回一個 AuthenticateResult 對象，表示用戶的身份。
4.ChallengeAsync 未認證，返回 401 狀態碼。
5.ForbidAsync 權限不足，返回 403 狀態碼。
下面我們一起看看它的唯一默認實現類AuthenticationService。

public class AuthenticationService : IAuthenticationService
    {
    
        // 其他成員
        public AuthenticationService(IAuthenticationSchemeProvider schemes, IAuthenticationHandlerProvider handlers, IClaimsTransformation transform);

        public IAuthenticationSchemeProvider Schemes { get; }

        public IAuthenticationHandlerProvider Handlers { get; }

        public IClaimsTransformation Transform { get; }

        public virtual async Task<AuthenticateResult> AuthenticateAsync(HttpContext context, string scheme);

        
        public virtual async Task ChallengeAsync(HttpContext context, string scheme, AuthenticationProperties properties)
        {
            if (scheme == null)
            {
                var defaultChallengeScheme = await Schemes.GetDefaultChallengeSchemeAsync();
                scheme = defaultChallengeScheme?.Name;
                if (scheme == null)
                {
                    throw new InvalidOperationException($"No authenticationScheme was specified, and there was no DefaultChallengeScheme found.");
                }
            }

            var handler = await Handlers.GetHandlerAsync(context, scheme);
            if (handler == null)
            {
                throw await CreateMissingHandlerException(scheme);
            }

            await handler.ChallengeAsync(properties);
        }

        public virtual async Task ForbidAsync(HttpContext context, string scheme, AuthenticationProperties properties);

        public virtual async Task SignInAsync(HttpContext context, string scheme, ClaimsPrincipal principal, AuthenticationProperties properties);

        public virtual async Task SignOutAsync(HttpContext context, string scheme, AuthenticationProperties properties);
    }

 

代碼比較多，我刪掉了大部分，其實現邏輯都差不多。我們以ChallengeAsync方法為例，先獲取相應的scheme，然后獲取對應的Handler，最后執行Handler的同名方法。也就說明，真正的認證邏輯是在Handler里面完成的。從AuthenticationService的定義了解到，AuthenticationService的創建是基於Handlers和schemes創建的，下面我們看看認證的第二個基礎對象IAuthenticationSchemeProvider。

public interface IAuthenticationSchemeProvider
    {
        Task<IEnumerable<AuthenticationScheme>> GetAllSchemesAsync();

        Task<AuthenticationScheme> GetSchemeAsync(string name);

        Task<AuthenticationScheme> GetDefaultAuthenticateSchemeAsync();

        Task<AuthenticationScheme> GetDefaultChallengeSchemeAsync();

        Task<AuthenticationScheme> GetDefaultForbidSchemeAsync();

        Task<AuthenticationScheme> GetDefaultSignInSchemeAsync();

        Task<AuthenticationScheme> GetDefaultSignOutSchemeAsync();

        void AddScheme(AuthenticationScheme scheme);

        void RemoveScheme(string name);

        Task<IEnumerable<AuthenticationScheme>> GetRequestHandlerSchemesAsync();
    }

 

scheme其實際就是提供認證方案標識，我們知道，NETCORE的認證系統所支持的認證方案非常豐富，比如openid、bearer、cookie等等。下面我們一起看看它的默認實現AuthenticationSchemeProvider對象。

public class AuthenticationSchemeProvider : IAuthenticationSchemeProvider
    {
        public AuthenticationSchemeProvider(IOptions<AuthenticationOptions> options)
            : this(options, new Dictionary<string, AuthenticationScheme>(StringComparer.Ordinal))
        {
        }

        protected AuthenticationSchemeProvider(IOptions<AuthenticationOptions> options, IDictionary<string, AuthenticationScheme> schemes)
        {
            _options = options.Value;

            _schemes = schemes ?? throw new ArgumentNullException(nameof(schemes));
            _requestHandlers = new List<AuthenticationScheme>();

            foreach (var builder in _options.Schemes)
            {
                var scheme = builder.Build();
                AddScheme(scheme);
            }
        }

        private readonly AuthenticationOptions _options;
        private readonly object _lock = new object();
        private readonly IDictionary<string, AuthenticationScheme> _schemes;
        private readonly List<AuthenticationScheme> _requestHandlers;
        private IEnumerable<AuthenticationScheme> _schemesCopy = Array.Empty<AuthenticationScheme>();
        private IEnumerable<AuthenticationScheme> _requestHandlersCopy = Array.Empty<AuthenticationScheme>();

        private Task<AuthenticationScheme> GetDefaultSchemeAsync()
            => _options.DefaultScheme != null
            ? GetSchemeAsync(_options.DefaultScheme)
            : Task.FromResult<AuthenticationScheme>(null);

        public virtual Task<AuthenticationScheme> GetDefaultAuthenticateSchemeAsync()
            => _options.DefaultAuthenticateScheme != null
            ? GetSchemeAsync(_options.DefaultAuthenticateScheme)
            : GetDefaultSchemeAsync();

        public virtual Task<AuthenticationScheme> GetDefaultChallengeSchemeAsync()
            => _options.DefaultChallengeScheme != null
            ? GetSchemeAsync(_options.DefaultChallengeScheme)
            : GetDefaultSchemeAsync();

        public virtual Task<AuthenticationScheme> GetDefaultForbidSchemeAsync()
            => _options.DefaultForbidScheme != null
            ? GetSchemeAsync(_options.DefaultForbidScheme)
            : GetDefaultChallengeSchemeAsync();

        public virtual Task<AuthenticationScheme> GetDefaultSignInSchemeAsync()
            => _options.DefaultSignInScheme != null
            ? GetSchemeAsync(_options.DefaultSignInScheme)
            : GetDefaultSchemeAsync();

         public virtual Task<AuthenticationScheme> GetDefaultSignOutSchemeAsync()
            => _options.DefaultSignOutScheme != null
            ? GetSchemeAsync(_options.DefaultSignOutScheme)
            : GetDefaultSignInSchemeAsync();

         public virtual Task<AuthenticationScheme> GetSchemeAsync(string name)
            => Task.FromResult(_schemes.ContainsKey(name) ? _schemes[name] : null);

         public virtual Task<IEnumerable<AuthenticationScheme>> GetRequestHandlerSchemesAsync()
            => Task.FromResult(_requestHandlersCopy);

         public virtual void AddScheme(AuthenticationScheme scheme)
        {
            if (_schemes.ContainsKey(scheme.Name))
            {
                throw new InvalidOperationException("Scheme already exists: " + scheme.Name);
            }
            lock (_lock)
            {
                if (_schemes.ContainsKey(scheme.Name))
                {
                    throw new InvalidOperationException("Scheme already exists: " + scheme.Name);
                }
                if (typeof(IAuthenticationRequestHandler).IsAssignableFrom(scheme.HandlerType))
                {
                    _requestHandlers.Add(scheme);
                    _requestHandlersCopy = _requestHandlers.ToArray();
                }
                _schemes[scheme.Name] = scheme;
                _schemesCopy = _schemes.Values.ToArray();
            }
        }

         public virtual void RemoveScheme(string name);

        public virtual Task<IEnumerable<AuthenticationScheme>> GetAllSchemesAsync()
            => Task.FromResult(_schemesCopy);
    }

 

從AuthenticationSchemeProvider的默認實現來看，它主要是提供scheme管理。從AuthenticationSchemeProvider構造器的定義來看，它的初始化是由我們注冊服務時所提供的options配置對象提供，其最終初始化體現在AddScheme方法上，也就是對所有注冊的scheme添加集合，所有scheme最終體現為一個AuthenticationScheme對象，下面我們看看它的定義。

public class AuthenticationScheme
    {
        public AuthenticationScheme(string name, string displayName, Type handlerType)
        {
            // 其他代碼
            if (!typeof(IAuthenticationHandler).IsAssignableFrom(handlerType))
            {
                throw new ArgumentException("handlerType must implement 
IAuthenticationHandler.");
            }

            Name = name;
            HandlerType = handlerType;
            DisplayName = displayName;
        }

        public string Name { get; }

        public string DisplayName { get; }

        public Type HandlerType { get; }
    }

 

每一個scheme里面都包含了對應的Handler，同時派生自IAuthenticationHandler。這個handler就是后續真正處理我們的認證實現。下面我們一起看看認證基石的第三個對象IAuthenticationHandlerProvider的定義。

public interface IAuthenticationHandlerProvider
    {
        Task<IAuthenticationHandler> GetHandlerAsync(HttpContext context, string authenticationScheme);
    }

 

這個接口的定義很簡單，就一個成員，GetHandlerAsync方法，顧名思義就是獲取authenticationScheme對應的Handler，我們看看IAuthenticationHandlerProvider的默認實現。

public class AuthenticationHandlerProvider : IAuthenticationHandlerProvider
    {
        public AuthenticationHandlerProvider(IAuthenticationSchemeProvider schemes)
        {
            Schemes = schemes;
        }

        public IAuthenticationSchemeProvider Schemes { get; }

        private Dictionary<string, IAuthenticationHandler> _handlerMap = new Dictionary<string, IAuthenticationHandler>(StringComparer.Ordinal);

        public async Task<IAuthenticationHandler> GetHandlerAsync(HttpContext context, string authenticationScheme)
        {
            if (_handlerMap.ContainsKey(authenticationScheme))
            {
                return _handlerMap[authenticationScheme];
            }

            var scheme = await Schemes.GetSchemeAsync(authenticationScheme);
            if (scheme == null)
            {
                return null;
            }
            var handler = (context.RequestServices.GetService(scheme.HandlerType) ??
                ActivatorUtilities.CreateInstance(context.RequestServices, scheme.HandlerType))
                as IAuthenticationHandler;
            if (handler != null)
            {
                await handler.InitializeAsync(scheme, context);
                _handlerMap[authenticationScheme] = handler;
            }
            return handler;
        }
    }

 

GetHandlerAsync方法的實現邏輯也比較簡單，首先通過_handlerMap字典根據scheme名稱獲取，一般首次獲取，都是null。然后通過schemeprovide獲取對應的scheme，通過上面分析我們知道，scheme體現為一個AuthenticationScheme對象，里面包含了handlertype。最后創建這個handler，創建handler有兩種情況，第一種從DI容器獲取，第二種情況反射創建，最終返回的是有如下定義的IAuthenticationHandler接口。

public interface IAuthenticationHandler
    {
        Task InitializeAsync(AuthenticationScheme scheme, HttpContext context);

        Task<AuthenticateResult> AuthenticateAsync();

        Task ChallengeAsync(AuthenticationProperties properties);

        Task ForbidAsync(AuthenticationProperties properties);
    }

 

該接口就是實打實干實事的，我們的認證邏輯就是通過該handler實現的。AuthenticateAsync方法就是我們的認證入口，其返回類型是一個AuthenticateResult類型，也就是我們的認證結果，接下來我們看看它的定義。

public class AuthenticateResult
    {
        protected AuthenticateResult() { }

        public bool Succeeded => Ticket != null;

        public AuthenticationTicket Ticket { get; protected set; }

        public ClaimsPrincipal Principal => Ticket?.Principal;

        public AuthenticationProperties Properties { get; protected set; }

        public Exception Failure { get; protected set; }

        public bool None { get; protected set; }

        public static AuthenticateResult Success(AuthenticationTicket ticket)
        {
            if (ticket == null)
            {
                throw new ArgumentNullException(nameof(ticket));
            }
            return new AuthenticateResult() { Ticket = ticket, Properties = ticket.Properties };
        }

        public static AuthenticateResult NoResult()
        {
            return new AuthenticateResult() { None = true };
        }

        public static AuthenticateResult Fail(Exception failure)
        {
            return new AuthenticateResult() { Failure = failure };
        }

        public static AuthenticateResult Fail(Exception failure, AuthenticationProperties properties)
        {
            return new AuthenticateResult() { Failure = failure, Properties = properties };
        }

        public static AuthenticateResult Fail(string failureMessage)
            => Fail(new Exception(failureMessage));

        public static AuthenticateResult Fail(string failureMessage, AuthenticationProperties properties)
            => Fail(new Exception(failureMessage), properties);
    }

 

如上代碼，AuthenticateResult對象的定義邏輯很簡單，就是包裝認證結果信息，比如AuthenticationTicket，它主要定義了我們的基本認證信息，我們可以把它理解為一張認證后的票據信息。AuthenticationProperties類型它主要定義了我們認證相關的輔助信息，其中包括過期、重定向、持久等等信息。關於這兩個類型的定義我就不貼代碼了，其實現比較簡單。兜兜轉轉終於到了我們的cooke認證實現類CookieAuthenticationHandler對象，下面我們一起看看它的定義。

public class CookieAuthenticationHandler : SignInAuthenticationHandler<CookieAuthenticationOptions>
    {
        // 其他代碼
        public CookieAuthenticationHandler(IOptionsMonitor<CookieAuthenticationOptions> options, ILoggerFactory logger, UrlEncoder encoder, ISystemClock clock)
            : base(options, logger, encoder, clock)
        { }

        protected override async Task<AuthenticateResult> HandleAuthenticateAsync();

        protected virtual async Task FinishResponseAsync();

        protected async override Task HandleSignInAsync(ClaimsPrincipal user, AuthenticationProperties properties);

        protected async override Task HandleSignOutAsync(AuthenticationProperties properties);

        protected override async Task HandleForbiddenAsync(AuthenticationProperties properties);

        protected override async Task HandleChallengeAsync(AuthenticationProperties properties);
    }

 

我們暫且先不討論CookieAuthenticationHandler認證實現邏輯，因為整個認證結構，有涉及多個Handler對象，我們還是一步一步按照這個層次結構來介紹吧，至少大家不會覺得突兀。從CookieAuthenticationHandler的定義來看，它並未直接實現IAuthenticationHandler，還是實現了有着如下定義的SignInAuthenticationHandler接口對象。

public abstract class SignInAuthenticationHandler<TOptions> : SignOutAuthenticationHandler<TOptions>, IAuthenticationSignInHandler
        where TOptions : AuthenticationSchemeOptions, new()
    {
        public SignInAuthenticationHandler(IOptionsMonitor<TOptions> options, ILoggerFactory logger, UrlEncoder encoder, ISystemClock clock) : base(options, logger, encoder, clock)
        { }

        public virtual Task SignInAsync(ClaimsPrincipal user, AuthenticationProperties properties)
        {
            var target = ResolveTarget(Options.ForwardSignIn);
            return (target != null)
                ? Context.SignInAsync(target, user, properties)
                : HandleSignInAsync(user, properties ?? new AuthenticationProperties());
        }

        protected abstract Task HandleSignInAsync(ClaimsPrincipal user, AuthenticationProperties properties);
    }

 

從該對象的定義來看，它就是負責處理登錄相關處理的。其中還有SignOutAuthenticationHandler，處理邏輯類似，負責登出操作，可能有些朋友會覺得有點奇怪，為什么登入登出會單獨定義成相關接口，個人理解，其一站在業務的角度，登入、登出和認證還是有一定的獨立性，並非所有業務場景必須要先登錄才能實現認證，而且認證更多關注的是過程，其二以適應更多認證方式，把登入登出抽象出來，使其擴展更方便。它們派生自抽象類AuthenticationHandler<TOptions>，下面我們看看它的定義。

public abstract class AuthenticationHandler<TOptions> : IAuthenticationHandler where TOptions : AuthenticationSchemeOptions, new()
    {
        // 其他代碼
        protected AuthenticationHandler(IOptionsMonitor<TOptions> options, ILoggerFactory logger, UrlEncoder encoder, ISystemClock clock)
        {
            Logger = logger.CreateLogger(this.GetType().FullName);
            UrlEncoder = encoder;
            Clock = clock;
            OptionsMonitor = options;
        }

        public async Task InitializeAsync(AuthenticationScheme scheme, HttpContext context)
        {
            if (scheme == null)
            {
                throw new ArgumentNullException(nameof(scheme));
            }
            if (context == null)
            {
                throw new ArgumentNullException(nameof(context));
            }

            Scheme = scheme;
            Context = context;

            Options = OptionsMonitor.Get(Scheme.Name);

            await InitializeEventsAsync();
            await InitializeHandlerAsync();
        }

        protected virtual async Task InitializeEventsAsync()
        {
            Events = Options.Events;
            if (Options.EventsType != null)
            {
                Events = Context.RequestServices.GetRequiredService(Options.EventsType);
            }
            Events = Events ?? await CreateEventsAsync();
        }

        protected virtual Task<object> CreateEventsAsync() => Task.FromResult(new object());

        protected virtual Task InitializeHandlerAsync() => Task.CompletedTask;

        protected string BuildRedirectUri(string targetPath)
            => Request.Scheme + "://" + Request.Host + OriginalPathBase + targetPath;

        protected virtual string ResolveTarget(string scheme)
        {
            var target = scheme ?? Options.ForwardDefaultSelector?.Invoke(Context) ?? Options.ForwardDefault;

            // Prevent self targetting
            return string.Equals(target, Scheme.Name, StringComparison.Ordinal)
                ? null
                : target;
        }

        public async Task<AuthenticateResult> AuthenticateAsync()
        {
            var target = ResolveTarget(Options.ForwardAuthenticate);
            if (target != null)
            {
                return await Context.AuthenticateAsync(target);
            }

            var result = await HandleAuthenticateOnceAsync();
            if (result?.Failure == null)
            {
                var ticket = result?.Ticket;
                if (ticket?.Principal != null)
                {
                    Logger.AuthenticationSchemeAuthenticated(Scheme.Name);
                }
                else
                {
                    Logger.AuthenticationSchemeNotAuthenticated(Scheme.Name);
                }
            }
            else
            {
                Logger.AuthenticationSchemeNotAuthenticatedWithFailure(Scheme.Name, result.Failure.Message);
            }
            return result;
        }

        protected Task<AuthenticateResult> HandleAuthenticateOnceAsync()
        {
            if (_authenticateTask == null)
            {
                _authenticateTask = HandleAuthenticateAsync();
            }

            return _authenticateTask;
        }

        protected async Task<AuthenticateResult> HandleAuthenticateOnceSafeAsync()
        {
            try
            {
                return await HandleAuthenticateOnceAsync();
            }
            catch (Exception ex)
            {
                return AuthenticateResult.Fail(ex);
            }
        }

        protected abstract Task<AuthenticateResult> HandleAuthenticateAsync();

        protected virtual Task HandleForbiddenAsync(AuthenticationProperties properties)
        {
            Response.StatusCode = 403;
            return Task.CompletedTask;
        }

        protected virtual Task HandleChallengeAsync(AuthenticationProperties properties)
        {
            Response.StatusCode = 401;
            return Task.CompletedTask;
        }

        public async Task ChallengeAsync(AuthenticationProperties properties)
        {
            var target = ResolveTarget(Options.ForwardChallenge);
            if (target != null)
            {
                await Context.ChallengeAsync(target, properties);
                return;
            }

            properties = properties ?? new AuthenticationProperties();
            await HandleChallengeAsync(properties);
            Logger.AuthenticationSchemeChallenged(Scheme.Name);
        }

        public async Task ForbidAsync(AuthenticationProperties properties)
        {
            var target = ResolveTarget(Options.ForwardForbid);
            if (target != null)
            {
                await Context.ForbidAsync(target, properties);
                return;
            }

            properties = properties ?? new AuthenticationProperties();
            await HandleForbiddenAsync(properties);
            Logger.AuthenticationSchemeForbidden(Scheme.Name);
        }
    }

 

該抽象類直接實現了我們上面提到的認證接口IAuthenticationHandler，是NETCORE所有認證類的基類，並且提供相關默認實現。抽象方法HandleAuthenticateAsync就是我們認證處理的入口，也是認證的核心實現，由具體的認證實現類實現。該基類的其他方法，邏輯都比較簡單，或者只提供默認實現就不再贅述，接下來我們圍繞上面提到的cookie認證的核心實現類CookieAuthenticationHandler介紹其具體認證實現，在介紹其具體實現之前，我們來看看它是如何被創建的或者說被注入到我們的DI容器的，其實是通過Startup的ConfigureServices方法注冊進來的，看代碼。

public static AuthenticationBuilder AddCookie(this AuthenticationBuilder builder, string authenticationScheme, string displayName, Action<CookieAuthenticationOptions> configureOptions)
        {
            builder.Services.TryAddEnumerable(ServiceDescriptor.Singleton<IPostConfigureOptions<CookieAuthenticationOptions>, PostConfigureCookieAuthenticationOptions>());
            builder.Services.AddOptions<CookieAuthenticationOptions>(authenticationScheme).Validate(o => o.Cookie.Expiration == null, "Cookie.Expiration is ignored, use ExpireTimeSpan instead.");
            return builder.AddScheme<CookieAuthenticationOptions, CookieAuthenticationHandler>(authenticationScheme, displayName, configureOptions);
        }

 

通過CookieExtensions的擴展方法AddCookie方法注入進來的，有疑惑的朋友可以看看我在開始介紹NETCORE認證的開始部分就貼出了這段代碼。接下來我們繼續看認證核心部分。

public class CookieAuthenticationHandler : SignInAuthenticationHandler<CookieAuthenticationOptions>
    {
        // 其他成員
        public CookieAuthenticationHandler(IOptionsMonitor<CookieAuthenticationOptions> options, ILoggerFactory logger, UrlEncoder encoder, ISystemClock clock)
            : base(options, logger, encoder, clock)
        { }

        protected new CookieAuthenticationEvents Events
        {
            get { return (CookieAuthenticationEvents)base.Events; }
            set { base.Events = value; }
        }
        // 初始化handler，設置響應cookie回調
        protected override Task InitializeHandlerAsync()
        {
            // Cookies needs to finish the response
            Context.Response.OnStarting(FinishResponseAsync);
            return Task.CompletedTask;
        }
        // cookie認證各個處理階段，默認注冊的事件
        protected override Task<object> CreateEventsAsync() => Task.FromResult<object>(new CookieAuthenticationEvents());
        // 獲取ticket票據
        private Task<AuthenticateResult> EnsureCookieTicket()；
        // 刷新票據
        private void CheckForRefresh(AuthenticationTicket ticket)；

        private void RequestRefresh(AuthenticationTicket ticket, ClaimsPrincipal replacedPrincipal = null);
        // clone票據
        private AuthenticationTicket CloneTicket(AuthenticationTicket ticket, ClaimsPrincipal replacedPrincipal);
        
        private async Task<AuthenticateResult> ReadCookieTicket();
        // cookie認證
        protected override async Task<AuthenticateResult> HandleAuthenticateAsync()
        {   
            // 獲取票據
            var result = await EnsureCookieTicket();
            if (!result.Succeeded)
            {
                return result;
            }
            // 用戶信息驗證，默認沒有任何邏輯實現
            var context = new CookieValidatePrincipalContext(Context, Scheme, Options, result.Ticket);
            await Events.ValidatePrincipal(context);

            if (context.Principal == null)
            {
                return AuthenticateResult.Fail("No principal.");
            }
            // 更新ticket票據，一般在之前會更新用戶信息
            if (context.ShouldRenew)
            {
                RequestRefresh(result.Ticket, context.Principal);
            }
            // 認證成功，包裝result返回
            return AuthenticateResult.Success(new AuthenticationTicket(context.Principal, context.Properties, Scheme.Name));
        }
        // 寫入response
        protected virtual async Task FinishResponseAsync()；
        // 登錄，
        protected async override Task HandleSignInAsync(ClaimsPrincipal user, AuthenticationProperties properties)
        {
            if (user == null)
            {
                throw new ArgumentNullException(nameof(user));
            }
            // 獲取配置信息
            properties = properties ?? new AuthenticationProperties();

            _signInCalled = true;

            // 初始化，比如sessionkey
            await EnsureCookieTicket();
            var cookieOptions = BuildCookieOptions();
            // 創建cookiecontext，以備寫入response
            var signInContext = new CookieSigningInContext(
                Context,
                Scheme,
                Options,
                user,
                properties,
                cookieOptions);
            // 設置認證輔助信息，比如過期時間等等。
            DateTimeOffset issuedUtc;
            if (signInContext.Properties.IssuedUtc.HasValue)
            {
                issuedUtc = signInContext.Properties.IssuedUtc.Value;
            }
            else
            {
                issuedUtc = Clock.UtcNow;
                signInContext.Properties.IssuedUtc = issuedUtc;
            }

            if (!signInContext.Properties.ExpiresUtc.HasValue)
            {
                signInContext.Properties.ExpiresUtc = issuedUtc.Add(Options.ExpireTimeSpan);
            }
            // 執行signin階段處理事件，如果有重寫，執行重寫邏輯
            await Events.SigningIn(signInContext);
            // 是否持久化
            if (signInContext.Properties.IsPersistent)
            {
                var expiresUtc = signInContext.Properties.ExpiresUtc ?? issuedUtc.Add(Options.ExpireTimeSpan);
                signInContext.CookieOptions.Expires = expiresUtc.ToUniversalTime();
            }
            // 創建認證票據ticket
            var ticket = new AuthenticationTicket(signInContext.Principal, signInContext.Properties, signInContext.Scheme.Name);
            // 基於session邏輯，實現復雜的cookie信息緩存到服務端
            if (Options.SessionStore != null)
            {
                if (_sessionKey != null)
                {
                    await Options.SessionStore.RemoveAsync(_sessionKey);
                }
                _sessionKey = await Options.SessionStore.StoreAsync(ticket);
                var principal = new ClaimsPrincipal(
                    new ClaimsIdentity(
                        new[] { new Claim(SessionIdClaim, _sessionKey, ClaimValueTypes.String, Options.ClaimsIssuer) },
                        Options.ClaimsIssuer));
                ticket = new AuthenticationTicket(principal, null, Scheme.Name);
            }
            // 加密票據
            var cookieValue = Options.TicketDataFormat.Protect(ticket, GetTlsTokenBinding());
            // 設置response響應頭
            Options.CookieManager.AppendResponseCookie(
                Context,
                Options.Cookie.Name,
                cookieValue,
                signInContext.CookieOptions);

            var signedInContext = new CookieSignedInContext(
                Context,
                Scheme,
                signInContext.Principal,
                signInContext.Properties,
                Options);
            // 登錄后的事件處理
            await Events.SignedIn(signedInContext);

            var shouldRedirect = Options.LoginPath.HasValue && OriginalPath == Options.LoginPath;
            await ApplyHeaders(shouldRedirect, signedInContext.Properties);

            Logger.AuthenticationSchemeSignedIn(Scheme.Name);
        }
        // 登出
        protected async override Task HandleSignOutAsync(AuthenticationProperties properties);
        
        private async Task ApplyHeaders(bool shouldRedirectToReturnUrl, AuthenticationProperties properties);
        // 權限不足
        protected override async Task HandleForbiddenAsync(AuthenticationProperties properties)
        {
            var returnUrl = properties.RedirectUri;
            if (string.IsNullOrEmpty(returnUrl))
            {
                returnUrl = OriginalPathBase + OriginalPath + Request.QueryString;
            }
            var accessDeniedUri = Options.AccessDeniedPath + QueryString.Create(Options.ReturnUrlParameter, returnUrl);
            var redirectContext = new RedirectContext<CookieAuthenticationOptions>(Context, Scheme, Options, properties, BuildRedirectUri(accessDeniedUri));
            await Events.RedirectToAccessDenied(redirectContext);
        }
        // 未認證用戶，訪問保護的資源
        protected override async Task HandleChallengeAsync(AuthenticationProperties properties)
        {
            // 通過配置信息獲取重定向url
            var redirectUri = properties.RedirectUri;
            if (string.IsNullOrEmpty(redirectUri))
            {
                redirectUri = OriginalPathBase + OriginalPath + Request.QueryString;
            }
            
            var loginUri = Options.LoginPath + QueryString.Create(Options.ReturnUrlParameter, redirectUri);
            var redirectContext = new RedirectContext<CookieAuthenticationOptions>(Context, Scheme, Options, properties, BuildRedirectUri(loginUri));
            // 重定向到登錄頁面
            await Events.RedirectToLogin(redirectContext);
        }
    }

 

以上就是cookie認證的核心實現，代碼注釋比較詳細，接下來我大致描述一下cookie認證的處理邏輯，其實跟傳統的Forms或者Katana的cookie認證思路差不多。
1.首先獲取請求cookie，解密並創建ticket票據。
2.如果配置了sessionstore方案，通過sessionkey獲取用戶完整的聲明信息。
3.校驗過期，如果未過期。
4.更新cookie，條件為過期時間范圍已過半。
5.校驗用戶信息，主要是針對cookie未失效，用戶聲明信息發生變更。
6.返回AuthenticateResult認證結果對象。
以上6點就是我個人針對NETCOREcookie認證的理解。接下來我們一起看看，認證中間件是如何關聯它們，實現我們的系統認證。
認證中間件
下面我們看看認證中間件的定義。

public class AuthenticationMiddleware
    {
        #region Fields

        private readonly RequestDelegate _next;

        #endregion

        #region Ctor

        public AuthenticationMiddleware(IAuthenticationSchemeProvider schemes, RequestDelegate next)
        {
            Schemes = schemes ?? throw new ArgumentNullException(nameof(schemes));
            _next = next ?? throw new ArgumentNullException(nameof(next));
        }

        #endregion

        #region Properties

        public IAuthenticationSchemeProvider Schemes { get; set; }

        #endregion

        #region Methods

        public async Task Invoke(HttpContext context)
        {
            context.Features.Set<IAuthenticationFeature>(new AuthenticationFeature
            {
                OriginalPath = context.Request.Path,
                OriginalPathBase = context.Request.PathBase
            });

            var handlers = context.RequestServices.GetRequiredService<IAuthenticationHandlerProvider>();
            foreach (var scheme in await Schemes.GetRequestHandlerSchemesAsync())
            {
                try
                {
                    if (await handlers.GetHandlerAsync(context, scheme.Name) is IAuthenticationRequestHandler handler && await handler.HandleRequestAsync())
                        return;
                }
                catch
                {
                }
            }

            var defaultAuthenticate = await Schemes.GetDefaultAuthenticateSchemeAsync();
            if (defaultAuthenticate != null)
            {
                var result = await context.AuthenticateAsync(defaultAuthenticate.Name);
                if (result?.Principal != null)
                {
                    context.User = result.Principal;
                }
            }

            await _next(context);
        }

        #endregion
    }

 

如上認證中間件就是這么簡單，關於中間件的原理可以參看我上一篇帖子。
1.首先從DI里面獲取IAuthenticationHandlerProvider的默認實現類AuthenticationHandlerProvider。
2.從schemes里面獲取所有實現IAuthenticationRequestHandler接口的handler，沒有什么特別的，就是多了一個請求方法，后續我會介紹，暫時我們把它理解為三方認證的實現handler。
3.如果有注冊該handler實例，將調用認證邏輯。
4.如果沒有注冊requesthandler實例，獲取默認scheme。
5.從指定的scheme里面獲取具體認證handler實現認證。
6.如果認證成功，返回result，並賦值httpcontext.user屬性，完成認證。

最后總結

 

本來打算把NETCORE的授權也一並講完，實在想睡覺了，今天就到這吧。下面我來做個簡單的總結吧，關於NET平台甚至NETCORE基於cookie認證的實現思路大致是一樣的，只是細節上面的區別，當然我理解的可能有些錯誤。我們學習微軟web平台的認證授權，其一是更好的掌握這個平台，其二是學習他的設計思路，當我們自己在實際開發中碰到安全相關的問題，如何去合理設計，更好的保證系統的安全性等等。