ASPNET-ASPNETCORE Cookie认证
一个小插曲
前几天去面了一家公司，跟面试官话不投机，问题犀利，态度傲慢。比如一上场就问你用过IOC框架吗？其实简历上面也有写Autofac、Unity等，我就说了几个Autofac、Unit、CastleWindsor而且自己参考Autofac也实现过轻量级简单的容器，第二句就是你真的用过IOC框架，Ninject在NET平台这么主流你都没用过？比如还有什么是webapi的基类？很多此类问题，后面我也蒙圈了。闲话就说到这吧，没有其他意思，开心就好。下面我们一起看看，ASPNET-ASPNETCORE平台上面的WEB框架有哪些主流的认证方式，以及底层实现。
话题背景
关于认证我的个人理解是，验证信息的合法性。在我们生活当中，比如门禁，你想进入一个有相对安全措施的小区或者大楼，你需要向保安或者门禁系统提供你的身份信息证明，只有确定你是小区业主，才可以进来，我这只是打个比方啊，不要纠结。对于我们计算机的安全领域，认证其实也非常类似，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配置节点，如下。
12 3
mode属性对应了4属性值，除Forms以外还有上面我提到的三种方式。其他三种由于篇幅问题，在这里不做介绍。这些属性我相信大家应该都比较熟悉。下面我们看看关于Forms认证具体的后台代码。看代码。
1 public virtual void SignIn(User user, // 这个user是你校验合法性之后的这么一个用户标识对象
2 bool createPersistentCookie)
3 {
4 var now = DateTime.UtcNow.ToLocalTime();
5 // 构建Ticker对象
6 var ticket = new FormsAuthenticationTicket(
7 1 ,
8 user.Username,
9 now,
10 now.Add(_expirationTimeSpan),
11 createPersistentCookie,
12 user.Username,
13 FormsAuthentication.FormsCookiePath);
14 // 加密ticker对象
15 var encryptedTicket = FormsAuthentication.Encrypt(ticket);
16 // 通过加密ticker对象构建HttpCookie对象
17 var cookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);
18 cookie.HttpOnly = true;
19 if (ticket.IsPersistent)
20 {
21 cookie.Expires = ticket.Expiration;
22 }
23 cookie.Secure = FormsAuthentication.RequireSSL;
24 cookie.Path = FormsAuthentication.FormsCookiePath;
25 if (FormsAuthentication.CookieDomain != null)
26 {
27 cookie.Domain = FormsAuthentication.CookieDomain;
28 }
29 // 写入输出流Response
30 _httpContext.Response.Cookies.Add(cookie);
31 }
以上代码就完成了我们的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中。我们可以通过一下代码片段验证这一逻辑。
1 private CryptographicKey GenerateCryptographicKey(string configAttributeName, string configAttributeValue, int autogenKeyOffset, int autogenKeyCount, string errorResourceString)
2 {
3 // 其他代码
4 bool flag1 = false;
5 bool flag2 = false;
6 bool flag3 = false;
7 if (configAttributeValue != null)
8 {
9 string str1 = configAttributeValue;
10 char[] chArray = new char[1]{ ',' };
11 foreach (string str2 in str1.Split(chArray))
12 {
13 if (!(str2 == "AutoGenerate"))
14 {
15 if (!(str2 == "IsolateApps"))
16 {
17 if (!(str2 == "IsolateByAppId"))
18 flag3 = true;
19 }
20 else
21 flag2 = true;
22 }
23 else
24 flag1 = true;
25 }
26 }
27 if (flag2)
28 MachineKeyMasterKeyProvider.AddSpecificPurposeString((IList) stringList, "IsolateApps", this.ApplicationName);
29 if (flag3)
30 MachineKeyMasterKeyProvider.AddSpecificPurposeString((IList) stringList, "IsolateByAppId", this.ApplicationId);
31 }
以上代码片段逻辑也比较简单，自己体会吧。
2.手动指定machineKey配置节点，该配置节在web.config文件里面，其中包括可支持的加密算法，加密算法支持DES，3DES，AES等。具体代码我就不贴了，我们跟踪其实现原理意在了解Forms认证其安全性。
3.通过以上两点介绍，我个人认为Forms认证相对来说很安全。
Forms认证
下面我们看看Forms的实现原理。
ASPNET的Forms认证发生在ASPNET管道的FormsAuthenticationModule对象里面，在该对象里面的Init方法里面绑定了认证事件OnEnter，具体的认证实现是OnEnter里面调用的OnAuthenticate方法。我们来看下代码。
1 private void OnAuthenticate(FormsAuthenticationEventArgs e)
2 {
3 // 其他代码
4 bool cookielessTicket = false;
5 // 从请求cookie里面抽取ticker票据信息
6 FormsAuthenticationTicket ticketFromCookie = FormsAuthenticationModule.ExtractTicketFromCookie(e.Context, FormsAuthentication.FormsCookieName, out cookielessTicket);
7 // 过期或者为null直接返回
8 if (ticketFromCookie == null || ticketFromCookie.Expired)
9 return;
10 FormsAuthenticationTicket ticket = ticketFromCookie;
11 // 如果启用滑动过期，更新过期时间
12 if (FormsAuthentication.SlidingExpiration)
13 ticket = FormsAuthentication.RenewTicketIfOld(ticketFromCookie);
14 e.Context.SetPrincipalNoDemand((IPrincipal) new GenericPrincipal((IIdentity) new FormsIdentity(ticket), new string[0]));
15 if (!cookielessTicket && !ticket.CookiePath.Equals("/"))
16 {
17 cookie = e.Context.Request.Cookies[FormsAuthentication.FormsCookieName];
18 if (cookie != null)
19 cookie.Path = ticket.CookiePath;
20 }
21 if (ticket == ticketFromCookie)
22 return;
23 if (cookielessTicket && ticket.CookiePath != "/" && ticket.CookiePath.Length > 1)
24 ticket = FormsAuthenticationTicket.FromUtc(ticket.Version, ticket.Name, ticket.IssueDateUtc, ticket.ExpirationUtc, ticket.IsPersistent, ticket.UserData, "/");
25 string cookieValue = FormsAuthentication.Encrypt(ticket, !cookielessTicket);
26
27 if (cookielessTicket)
28 {
29 e.Context.CookielessHelper.SetCookieValue('F', cookieValue);
30 e.Context.Response.Redirect(e.Context.Request.RawUrl);
31 }
32 else
33 {
34 if (cookie != null)
35 cookie = e.Context.Request.Cookies[FormsAuthentication.FormsCookieName];
36 if (cookie == null)
37 {
38 cookie = new HttpCookie(FormsAuthentication.FormsCookieName, cookieValue);
39 cookie.Path = ticket.CookiePath;
40 }
41 if (ticket.IsPersistent)
42 cookie.Expires = ticket.Expiration;
43 cookie.Value = cookieValue;
44 cookie.Secure = FormsAuthentication.RequireSSL;
45 cookie.HttpOnly = true;
46 if (FormsAuthentication.CookieDomain != null)
47 cookie.Domain = FormsAuthentication.CookieDomain;
48 cookie.SameSite = FormsAuthentication.CookieSameSite;
49 e.Context.Response.Cookies.Remove(cookie.Name);
50 e.Context.Response.Cookies.Add(cookie);
51 }
52 }
以上代码片段反映了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的定义。
1 public class CookieAuthenticationMiddleware : AuthenticationMiddleware2 { 3 // 其他成员 4 public CookieAuthenticationMiddleware(OwinMiddleware next, IAppBuilder app, CookieAuthenticationOptions options) 5 : base(next, options) 6 { 7 } 8 // 创建具体的AuthenticationHandler 9 protected override AuthenticationHandler CreateHandler() 10 { 11 return new CookieAuthenticationHandler(_logger); 12 } 13 }
CookieAuthenticationMiddleware里面就一个方法成员，通过CreateHandler方法创建了具体的CookieAuthenticationHandler对象，我们的认证核心实现就发生在这个Handler里面。接下来我们看看CookieAuthenticationHandler对象的定义。
1 internal class CookieAuthenticationHandler : AuthenticationHandler2 { 3 // 其他成员 4 private const string HeaderNameCacheControl = "Cache-Control"; 5 private const string HeaderNamePragma = "Pragma"; 6 private const string HeaderNameExpires = "Expires"; 7 private const string HeaderValueNoCache = "no-cache"; 8 private const string HeaderValueMinusOne = "-1"; 9 private const string SessionIdClaim = "Microsoft.Owin.Security.Cookies-SessionId"; 10 11 private bool _shouldRenew; 12 private DateTimeOffset _renewIssuedUtc; 13 private DateTimeOffset _renewExpiresUtc; 14 private string _sessionKey; 15 16 protected override async Task AuthenticateCoreAsync() 17 18 protected override async Task ApplyResponseGrantAsync() 19 20 protected override Task ApplyResponseChallengeAsync() 21 }
从CookieAuthenticationHandler对象的定义来看，其实也能看出一二，主要是针对cookie的相关操作，在该对象成员里面我们需要了解一下其中的三个方法。
1.AuthenticateCoreAsync，代码我就不贴了，有兴趣的朋友可以自己查看Katana开源项目的源代码。该方法内部大概实现思路是：从IOWinContext对象获取cookie，如果对owin不怎么熟悉的话，这个context你可以把它理解为我们之前熟悉的HttpContext，然后通过解密出来的cookie字符串构造ClaimsIdentity对象并添加到OwinContext对象Request.User，最后返回AuthenticationTicket对象，该对象包装的就是当前用户信息以及相关辅助信息。
2.ApplyResponseGrantAsync，设置、更新或者删除cookie并写入response。
3.ApplyResponseChallengeAsync，授权失败，发生重定向。
1 public class AuthenticationTicket
2 {
3 public AuthenticationTicket(ClaimsIdentity identity, AuthenticationProperties properties)
4 {
5 Identity = identity;
6 Properties = properties ?? new AuthenticationProperties();
7 }
8 // 用户信息
9 public ClaimsIdentity Identity { get; private set; }
10 // 辅助信息，比如会话、过期等
11 public AuthenticationProperties Properties { get; private set; }
12 }
下面我们一起看看在我们开发过程中的应用以及内部实现
Startup是Katana开源项目引入的一种新的模块初始化方式，其实也没什么特别的，就是相关中间件的注册以及一些默认上下文对象的初始化操作。下面我们具体看代码，我们的MVC5新的认证方式在Startup里面如何注册的。
1 public partial class Startup
2 {
3 public void ConfigureAuth(IAppBuilder app)
4 {
5 // 其他代码
6 app.UseCookieAuthentication(new CookieAuthenticationOptions
7 {
8 AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
9 LoginPath = new PathString("/Account/Login"),
10 Provider = new CookieAuthenticationProvider
11 { }
12 });
13 }
14 }
注册逻辑很简单，通过IAppBuilder的扩展方法UseCookieAuthentication实现，接下来我们看看UseCookieAuthentication扩展方法的内部实现。
1 public static IAppBuilder UseCookieAuthentication(this IAppBuilder app, CookieAuthenticationOptions options, PipelineStage stage)
2 {
3 if (app == null)
4 { }
5 // 注册
6 app.Use(typeof(CookieAuthenticationMiddleware), app, options);
7 // 加入owin管道
8 app.UseStageMarker(stage);
9 return app;
10 }
整个注册逻辑就这么几行代码，相关方法都有注释。最后在程序初始化过程中通过Build方法完成Owin管道所有中间件的初始化工作。接下来我们看看具体的登录实现。
1 public async TaskLogin(LoginModel model,string returnUrl) 2 { 3 // 其他代码 4 if (ModelState.IsValid) 5 { 6 AppUser user = await UserManager.FindAsync(model.Name, model.Password); 7 if (user==null) 8 { 9 ModelState.AddModelError("","无效的用户名或密码"); 10 } 11 else 12 { 13 var claimsIdentity = 14 await UserManager.CreateIdentityAsync(user, DefaultAuthenticationTypes.ApplicationCookie); 15 AuthManager.SignIn(new AuthenticationProperties {IsPersistent = false}, claimsIdentity); 16 return Redirect(returnUrl); 17 } 18 } 19 20 return View(model); 21 }
通过以上代码片段就完成了我们系统的登录操作，在以上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服务认证中间件。
1 app.UseGoogleAuthentication(new GoogleOAuth2AuthenticationOptions()
2 {
3 // 以下为客户端凭据，可以通过google认证服务注册
4 ClientId = "",
5 ClientSecret = "",
6 });
其二我们需要设计实现登录逻辑，通常情况下我们在登录论坛的时候，旁边可能会有基于QQ登录或者别的三方认证提供商。
1 public ActionResult GoogleLogin(string returnUrl)
2 { // 创建AuthenticationProperties对象，我们可以理解为认证复制信息字典
3 var properties = new AuthenticationProperties
4 {
5 RedirectUri = Url.Action("GoogleLoginCallback",
6 new { returnUrl = returnUrl })
7 };
8 // 初始化google认证相关辅助信息
9 HttpContext.GetOwinContext().Authentication.Challenge(properties, "Google");
10 // 返回401
11 return new HttpUnauthorizedResult();
12 }
以上代码比较简单，我也做了相应的注释，其逻辑是初始化google认证的一些辅助信息，然后返回401状态码，继而重定向到google登录页。下面我们看看登录成功之后的代码逻辑。
1 public async TaskGoogleLoginCallback(string returnUrl) 2 { 3 // 从google认证服务获取claims 4 ExternalLoginInfo loginInfo = await AuthManager.GetExternalLoginInfoAsync(); 5 // 检查该用户是否首次登录系统 6 AppUser user = await UserManager.FindAsync(loginInfo.Login); 7 if (user == null) 8 { 9 user = new AppUser 10 { 11 Email = loginInfo.Email, 12 UserName = loginInfo.DefaultUserName, 13 City = Cities.Shanghai, 14 Country = Countries.China 15 }; 16 // 持久化用户数据 17 IdentityResult result = await UserManager.CreateAsync(user); 18 // 缓存 19 result = await UserManager.AddLoginAsync(user.Id, loginInfo.Login); 20 } 21 ClaimsIdentity ident = await UserManager.CreateIdentityAsync(user, 22 DefaultAuthenticationTypes.ApplicationCookie); 23 ident.AddClaims(loginInfo.ExternalIdentity.Claims); 24 // 创建用户ClaimsIdentity对象 25 AuthManager.SignIn(new AuthenticationProperties 26 { 27 IsPersistent = false 28 }, ident); 29 return Redirect(returnUrl ?? "/"); 30 }
以上就是三方认证的实现方式，下面我们通过Katana源码看看三方认证的实现原理。通过上面Katana的cookies认证，我们了解到认证中间件的认证逻辑是实现在相应的AuthenticationHandler里面，我们同样以google为例，去看看内部的实现。下面我们一起来上面注册的认证中间件GoogleOAuth2AuthenticationMiddleware的定义。
1 public class GoogleOAuth2AuthenticationMiddleware : AuthenticationMiddleware2 { 3 // 其他成员 4 public GoogleOAuth2AuthenticationMiddleware( 5 OwinMiddleware next, 6 IAppBuilder app, 7 GoogleOAuth2AuthenticationOptions options) 8 : base(next, options); 9 // 构建认证handler 10 protected override AuthenticationHandler CreateHandler() 11 { 12 return new GoogleOAuth2AuthenticationHandler(_httpClient, _logger); 13 } 14 // 构建httpclienthandler 15 private static HttpMessageHandler ResolveHttpMessageHandler(GoogleOAuth2AuthenticationOptions options)； 16 }
根据以上代码片段我们了解到，GoogleOAuth2AuthenticationMiddleware中间件似乎比我们常规的cookies认证多了一个方法ResolveHttpMessageHandler，其实这个方法没有别的套路，就是辅助创建httpclient对象，完成http请求而已，在handler的认证逻辑里面需要获取googletoken，就是通过它来获取的。
第二个方法CreateHandler返回的GoogleOAuth2AuthenticationHandler对象就是我们接下来要重点讨论的对象。
1 internal class GoogleOAuth2AuthenticationHandler : AuthenticationHandler2 { 3 private const string TokenEndpoint = "https://accounts.google.com/o/oauth2/token"; 4 private const string UserInfoEndpoint = "https://www.googleapis.com/plus/v1/people/me"; 5 private const string AuthorizeEndpoint = "https://accounts.google.com/o/oauth2/auth"; 6 7 private readonly ILogger _logger; 8 private readonly HttpClient _httpClient; 9 10 public GoogleOAuth2AuthenticationHandler(HttpClient httpClient, ILogger logger) 11 { 12 _httpClient = httpClient; 13 _logger = logger; 14 } 15 // 通过httpclient访问google认证服务器获取token，根据token数据包装Claim 16 protected override async Task AuthenticateCoreAsync(); 17 // 如果未认证，401授权失败发生重定向 18 protected override Task ApplyResponseChallengeAsync()； 19 20 public override async Task InvokeAsync() 21 { 22 return await InvokeReplyPathAsync(); 23 } 24 // 调用signin，保存用户信息 25 private async Task InvokeReplyPathAsync(); 26 }
代码比较长，我把具体实现删掉了，实现逻辑我注释到了方法上面，有兴趣的朋友可以自己多看看源码。以上就是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的提供机制可以看看我上一篇博客，有详细介绍。
第一部曲服务配置
1 public static void AddAuthentication(this IServiceCollection services)
2 {
3
4 // 其他代码
5 var authenticationBuilder = services.AddAuthentication(options =>
6 {
7 options.DefaultChallengeScheme = AuthenticationDefaults.AuthenticationScheme;
8 options.DefaultScheme = AuthenticationDefaults.AuthenticationScheme;
9 options.DefaultSignInScheme = AuthenticationDefaults.ExternalAuthenticationScheme;
10 })
11 .AddCookie(AuthenticationDefaults.AuthenticationScheme, options =>
12 {
13 options.Cookie.Name = $"{CookieDefaults.Prefix}{NopCookieDefaults.AuthenticationCookie}";
14 options.Cookie.HttpOnly = true;
15 options.LoginPath = AuthenticationDefaults.LoginPath;
16 options.AccessDeniedPath = AuthenticationDefaults.AccessDeniedPath;
17 })
18 .AddCookie(AuthenticationDefaults.ExternalAuthenticationScheme, options =>
19 {
20 options.Cookie.Name = $"{CookieDefaults.Prefix}{CookieDefaults.ExternalAuthenticationCookie}";
21 options.Cookie.HttpOnly = true;
22 options.LoginPath = AuthenticationDefaults.LoginPath;
23 options.AccessDeniedPath = AuthenticationDefaults.AccessDeniedPath;
24 });
25 }
以上代码片段就完成了cookies认证的所需服务注册。其实际就是注册cookies认证所需的基础对象和辅助配置信息到DI容器，以便中间件可以通过DI容器方便获取。AddAuthentication扩展方法，主要是注册认证系统所需基础对象。AddCookie扩展方法主要是注册具体cookie认证Handler对象以及通过options模式配置辅助信息。
第二部曲中间件注册
1 public static void UseAuthentication(this IApplicationBuilder application)
2 {
3 // 其他代码
4 application.UseMiddleware();
5 }
认证中间件的注册就这么一句代码，实际就是ASPNETCORE请求管道添加认证中间件，最后通过Build初始化到这个请求管道，后续所有的请求都会通过这个认证中间件的invoke方法处理，然后传递下一个中间件，关于中间件的原理也可以看我上一篇帖子。认证系统的配置我们已经准备完成，下面我们看看系统登录。
登录
1 [HttpPost]
2 public virtual IActionResult Login(LoginModel model, string returnUrl, bool captchaValid)
3 {
4
5 // 其他代码
6 if (ModelState.IsValid)
7 {
8 var loginResult = _userService.ValidateUser(model.Username, model.Password);
9 switch (loginResult)
10 {
11 case LoginResults.Successful:
12 {
13 var user = _userService.GetUserByUserName(model.Username);
14
15 _authenticationService.SignIn(user, model.RememberMe);
16
17 return Redirect(returnUrl);
18 }
19 }
20 }
21
22 return View(model);
23 }
以上登录代码片段比较简单，主要完成两个动作，1.收集用户输入的用户名&密码等信息，然后通过我们系统的存储介质，校验用户名&密码的合法性。2.登录到我们的认证系统，实现我们核心登录逻辑是SignIn方法里面。下面我们继续看看SignIn方法的具体实现。
1 public virtual async void SignIn(User user, bool isPersistent)
2 {
3 // 其他代码
4 // 创建身份信息集合
5 var claims = new List();
6
7 if (!string.IsNullOrEmpty(user.Username))
8 claims.Add(new Claim(ClaimTypes.Name, user.Username, ClaimValueTypes.String, AuthenticationDefaults.ClaimsIssuer));
9
10 if (!string.IsNullOrEmpty(user.Email))
11 claims.Add(new Claim(ClaimTypes.Email, user.Email, ClaimValueTypes.Email, AuthenticationDefaults.ClaimsIssuer));
12
13 var userIdentity = new ClaimsIdentity(claims, AuthenticationDefaults.AuthenticationScheme);
14 var userPrincipal = new ClaimsPrincipal(userIdentity);
15 // 辅助信息
16 var authenticationProperties = new AuthenticationProperties
17 {
18 IsPersistent = isPersistent,
19 IssuedUtc = DateTime.UtcNow
20 };
21 // 创建cookie ticket，以备写入response输出到客户端
22 await _httpContextAccessor.HttpContext.SignInAsync(AuthenticationDefaults.AuthenticationScheme, userPrincipal, authenticationProperties);
23 }
以上代码片段就完成了我们认证系统的登录。大致逻辑是构建身份声明信息，调用HttpContext的SignInAsync方法创建ticket，在endrequest阶段创建cookie写入response。以上就是我们基于ASPNETCORE平台开发web应用对于认证的真实应用。接下来我们重点看看平台的内部实现。
Cookies认证内部实现
我们还是从服务注册开始吧，毕竟它是完成认证系统的基石。我们把视线转移到上面的AddAuthentication方法，注册服务，我们看看它到底为我们的认证系统注册了哪些基础服务，看NETCORE源代码。
1 public static AuthenticationBuilder AddAuthentication(this IServiceCollection services)
2 {
3 // 其他代码
4 services.AddAuthenticationCore();
5 services.AddDataProtection();
6 services.AddWebEncoders();
7 services.TryAddSingleton();
8 return new AuthenticationBuilder(services);
9 }
从以上代码片段了解到，我们的认证服务注册是在平台AddAuthenticationCore方法里面完成的。我们一起看看AddAuthenticationCore方法的实现。
1 public static IServiceCollection AddAuthenticationCore(this IServiceCollection services)
2 {
3 services.TryAddScoped();
4 services.TryAddSingleton(); // Can be replaced with scoped ones that use DbContext
5 services.TryAddScoped();
6 services.TryAddSingleton();
7 return services;
8 }
AddAuthenticationCore方法里面主要注册了我们NETCORE认证系统的三个基础对象，你可以把它们理解为黑帮的一个老大两个堂主，由它们吩咐下面的小弟完成任务，言归正传这三个对象也是完成我们NETCORE平台认证的三剑客，通过Provider模式实现，下面我们一个个来介绍，我们先看看IAuthenticationService接口的定义。
1 public interface IAuthenticationService
2 {
3 Task AuthenticateAsync(HttpContext context, string scheme);
4
5 Task ChallengeAsync(HttpContext context, string scheme, AuthenticationProperties properties);
6
7 Task ForbidAsync(HttpContext context, string scheme, AuthenticationProperties properties);
8
9 Task SignInAsync(HttpContext context, string scheme, ClaimsPrincipal principal, AuthenticationProperties properties);
10
11 Task SignOutAsync(HttpContext context, string scheme, AuthenticationProperties properties);
12 }
IAuthenticationService接口定义了5个方法成员，它本身不实现任何认证逻辑，只是为IAuthenticationSchemeProvider 和 IAuthenticationHandlerProvider这两个Provider实现了封装，提供认证服务的统一接口。下面我大概解释一下这个5个方法在认证服务中的作用。
1.SignInAsync 登录操作，如果登录成功，生成加密ticket，用来标识用户的身份。
2.SignOutAsync 退出登录，清除Coookie等。
3.AuthenticateAsync 解密cookie，获取ticket并验证，最后返回一个 AuthenticateResult 对象，表示用户的身份。
4.ChallengeAsync 未认证，返回 401 状态码。
5.ForbidAsync 权限不足，返回 403 状态码。
下面我们一起看看它的唯一默认实现类AuthenticationService。
1 public class AuthenticationService : IAuthenticationService
2 {
3
4 // 其他成员
5 public AuthenticationService(IAuthenticationSchemeProvider schemes, IAuthenticationHandlerProvider handlers, IClaimsTransformation transform);
6
7 public IAuthenticationSchemeProvider Schemes { get; }
8
9 public IAuthenticationHandlerProvider Handlers { get; }
10
11 public IClaimsTransformation Transform { get; }
12
13 public virtual async Task AuthenticateAsync(HttpContext context, string scheme);
14
15
16 public virtual async Task ChallengeAsync(HttpContext context, string scheme, AuthenticationProperties properties)
17 {
18 if (scheme == null)
19 {
20 var defaultChallengeScheme = await Schemes.GetDefaultChallengeSchemeAsync();
21 scheme = defaultChallengeScheme?.Name;
22 if (scheme == null)
23 {
24 throw new InvalidOperationException($"No authenticationScheme was specified, and there was no DefaultChallengeScheme found.");
25 }
26 }
27
28 var handler = await Handlers.GetHandlerAsync(context, scheme);
29 if (handler == null)
30 {
31 throw await CreateMissingHandlerException(scheme);
32 }
33
34 await handler.ChallengeAsync(properties);
35 }
36
37 public virtual async Task ForbidAsync(HttpContext context, string scheme, AuthenticationProperties properties);
38
39 public virtual async Task SignInAsync(HttpContext context, string scheme, ClaimsPrincipal principal, AuthenticationProperties properties);
40
41 public virtual async Task SignOutAsync(HttpContext context, string scheme, AuthenticationProperties properties);
42 }
代码比较多，我删掉了大部分，其实现逻辑都差不多。我们以ChallengeAsync方法为例，先获取相应的scheme，然后获取对应的Handler，最后执行Handler的同名方法。也就说明，真正的认证逻辑是在Handler里面完成的。从AuthenticationService的定义了解到，AuthenticationService的创建是基于Handlers和schemes创建的，下面我们看看认证的第二个基础对象IAuthenticationSchemeProvider。
1 public interface IAuthenticationSchemeProvider
2 {
3 Task> GetAllSchemesAsync();
4
5 Task GetSchemeAsync(string name);
6
7 Task GetDefaultAuthenticateSchemeAsync();
8
9 Task GetDefaultChallengeSchemeAsync();
10
11 Task GetDefaultForbidSchemeAsync();
12
13 Task GetDefaultSignInSchemeAsync();
14
15 Task GetDefaultSignOutSchemeAsync();
16
17 void AddScheme(AuthenticationScheme scheme);
18
19 void RemoveScheme(string name);
20
21 Task> GetRequestHandlerSchemesAsync();
22 }
scheme其实际就是提供认证方案标识，我们知道，NETCORE的认证系统所支持的认证方案非常丰富，比如openid、bearer、cookie等等。下面我们一起看看它的默认实现AuthenticationSchemeProvider对象。
1 public class AuthenticationSchemeProvider : IAuthenticationSchemeProvider
2 {
3 public AuthenticationSchemeProvider(IOptions options)
4 : this(options, new Dictionary(StringComparer.Ordinal))
5 {
6 }
7
8 protected AuthenticationSchemeProvider(IOptions options, IDictionary schemes)
9 {
10 _options = options.Value;
11
12 _schemes = schemes ?? throw new ArgumentNullException(nameof(schemes));
13 _requestHandlers = new List();
14
15 foreach (var builder in _options.Schemes)
16 {
17 var scheme = builder.Build();
18 AddScheme(scheme);
19 }
20 }
21
22 private readonly AuthenticationOptions _options;
23 private readonly object _lock = new object();
24 private readonly IDictionary _schemes;
25 private readonly List _requestHandlers;
26 private IEnumerable _schemesCopy = Array.Empty();
27 private IEnumerable _requestHandlersCopy = Array.Empty();
28
29 private Task GetDefaultSchemeAsync()
30 => _options.DefaultScheme != null
31 ? GetSchemeAsync(_options.DefaultScheme)
32 : Task.FromResult(null);
33
34 public virtual Task GetDefaultAuthenticateSchemeAsync()
35 => _options.DefaultAuthenticateScheme != null
36