ASP.NET核心身份详细介绍(2)

序

上一篇文章讲了Identity需要知道的单词和几个对应的知识点，知道了Identity在整个登录过程中的位置。本文主要是整个认证系统中的一个重要环节。NET，也就是身份验证，因为要想让Identity明确，就不能绕过身份验证。

事实上，身份也是认证系统的一个具体应用。每个人都必须把认证和身份视为两件事。一旦他们迷茫了，你就很容易陷入其中。

先说说ASP.NET芯的认证系统。别怕，其实很简单，都是干货~

入门指南

你应该记得前一篇文章中的奥巴马先生。他现在不住在华盛顿。他去过中国，现在住在北京。听说西湖这几天风景不错，就订了12306北京到杭州的高铁票。拿到票后，他给我们看了：

今天是11/11，奥巴马很开心。你知道为什么。快到出发时间了，我拿着票到了火车站的检票口，就把身份证和火车票交给了检票员。“切”，导演喊道。尼玛本来是拍电影的~

导演说：“奥巴马，你太可怕了。别演戏了。你应该扮演检票员。让你旁边的小李演想旅行的奥巴马。”。奥巴马无奈地说：“好吧，我希望小挺你。”。

“行动”，导演又喊了一声，故事开始了~

身份验证管理器

奥巴马成为检票员后，他非常高兴，因为他有权控制别人能不能上车，也许他可以偷偷带几个人进去拿点外快。

在了解了自己能做什么之后，他觉得检票员这个名字简直太低了。很快，他有了一个新的名字：身份验证管理器。此外，他觉得自己应该处于整个核心位置。为什么呢？你想想，一个庞大的铁路载人系统能不能挣钱，就看他把人放进去没有。如果没有人放在里面，一大群人只能喝西北风。

现在，聪明的学生可能已经知道奥巴马把自己放在什么样的核心位置了。是的，他把自己放在了HttpContext中。最近怎么样？足够核心。

这里扩展了第一个知识点：身份验证管理器的位置

一些学生发现公共抽象声明主体用户{ get设置；}，这不就是我们上一篇文章讲的“证书党”，现在小李扮演的角色吗？是的，这个用户就是本文中的小李。你提前发现他藏在这里了，呵呵。

还有一个知识点，就是AuthenticationScheme，是什么意思？看到奥巴马敢于把自己放在这样的核心位置，也有他的能力。怎么说呢？比如有人在验票的时候交出了身份证和火车票，如何验证这两个证件是合法的？以下是奥巴马针对两类文件提出的验证方案：

方案一。对于身份证的验证，可以查看该人是否与身份证头像一致，年龄是否符合当事人的具体年龄。

方案二。对于火车票的验证，我们可以看到车次和时间是否符合发车目标，车票上的身份号码是否与身份证一致。

其中，每个方案对应一个身份验证方案。你明白吗？

这是第二个知识点。AuthenticationScheme非常重要。

知道了奥巴马的职责，编写代码就很容易了：

公共抽象类authenticationmanager {//authenticate context包含需要身份验证的上下文，包括小李的公共抽象任务authenticate async(authenticate context)；//握手公共抽象任务质询async(字符串身份验证方案、身份验证属性属性、质询行为行为)；//登录公共抽象任务登录async(字符串身份验证方案，声明主体主体，身份验证属性属性)；//注销公共抽象任务注销异步(字符串身份验证方案，身份验证属性属性)；}作为检票员，奥巴马有一个身份验证方法，AuthenticateAsync()。注意，这是它的核心功能之一，其他人可以没有这个功能，但没有它他不能被称为检票员。

然后是握手挑战，登录登录同步和注销登录异步。我来说说作者对这三种方法的理解。

ChallengeAsync:是RFC2167中定义的握手过程，主要是摘要式认证。

是不是有点专业，看不懂，没事，有流行版本。小李正要进站。这时，小李问我们的检票员，奥巴马先生。

小李：“检票员您好，我可以进站吗？”检票员奥巴马：“你想赶火车吗？是的，请出示你的证件？”小李：“好的，这是我的证件。你能检查一下吗？”检票员奥巴马：“嗯，证件还行，进去吧。”这个过程是一个消化-挑战或问答的过程。你明白挑战容易的原理吗？是不是很简单。

SignInAsync，SignOutAsync:个人认为这两个不应该放在这里，因为不属于认证的责任，也不属于协议约定的内容。但是，这两种方法确实需要抽象，应该单独提取一个接口进行存储。至于为什么会这样做，可能是因为以下原因：

1.登录和注销的抽象与身份验证紧密结合。在大多数情况下，身份验证数据需要保存在登录中。例如，cookie身份验证中间件在SignIn方法中保存cookie。

2.身份验证管理器该对象位于HttpContext中

在上下文中，基于抽象和封装的原则，把它放在里面是合适的，这样用户可以方便地调用它。

AuthenticationManager已经推出了，是不是很简单？

IAuthenticationHandler

有些同学可能会问，如果AuthenticationManager不提供接口，那它只是一个抽象类，那么如果用户定义的身份验证方法必须继承它，对开发人员不友好，违背了面向接口编程的理念。没错，这就是界面：

公共接口IAuthenticationHandler { void GetDescriptions(descriptebschemescontext上下文)；任务AuthenticateAsync(AuthenticateContext上下文)；任务挑战上下文；任务签名同步(签名上下文)；任务SignOutAsync(SignOutContext上下文)；}这个接口是从AuthenticationManager实现类DefaultAuthenticationManager扩展而来的，所以不用看里面的源代码。请记住，如果将来需要重写身份验证相关的东西，可以实现IAuthenticationHandler。

认证中间件

对于IAuthenticationHandler的初步实现，封装了抽象类AuthenticationHandler，具体核心功能交给下游实现。下面这个CookieAuthenticationHandler核心类的CookieAuthentication中间件是继承了AuthenticationHandler的，知道这么多就够了。

认证中间件

故事还在继续。收到小李递过来的身份证和火车票后，奥巴马先拿着火车票在二维码机上扫描，然后拿着身份证在机器上刷。经过核实，发现没有问题。然后他拿起印章，在上面盖了一个“退房”的章。

中间发生了什么？

首先，在二维码扫描过程中，二维码机会对你的火车票上的二维码进行解析，如果解析失败，会直接响应认证失败。也就是说，你不能进入车站。

如果分析成功，你会得到你账单中的信息，然后得到你账单中的当事人信息，验证是否被列入铁路局黑名单。

如果验证成功，会给你一个识别码，与你身份相符的识别码会写入你的火车票和检票员旁边的电脑系统，即“已验证”。

说这个验证有点高级，会把一些信息写入你的火车票芯片，那么写的是什么信息呢？1.奥巴马的个人信息。2.验证过程中的一些上下信息。3.使用的验证方案。

知道了这一点，实现这个验证方法就很容易了，对吧？以下是CookieAuthenticationhandler中间件核心类CookieAuthenticationhandler中的核心方法HandleAuthenticateAsync()，也可以理解为实现的IAuthenticationHandler接口的AuthenticateAsync:

受保护覆盖async task authenticateresult handleauthenticateasync(){//解析二维码var result=wait surecokieticket()；if(！结果。成功){返回结果；}//从二维码中核实当事人信息。var context=new cookievalidateprincipalcontext(上下文，结果。机票、期权)；等待选项。Events.ValidatePrincipal(上下文)；if(上下文。Principal==null) {返回AuthenticateResult。失败(没有主体));} if(上下文。应该更新){ RequestRefresh(结果。门票)；}//检查并将其写入芯片返回authenticateresult . success(new authenticationticket(context . principal，context.properties，options . authenticationscheme))；} HandleSignInAsync

我们的故事还在继续.

奥巴马验票后，把票交给小李。小李拿到票后，导演又喊：“停”.

为什么又停了？小李和奥巴马充满了疑惑。导演说：“奥巴马，你是个好检票员。你应该继续扮演你自己的角色。中午打完饭盒，给你双份。小李，你应该演检票员。”。该吃两份午餐了。奥巴马听完还是很开心。

“行动”主任喊道.

奥巴马拿着票，走到车站内的火车停车处，当他走到火车门口要进去时，又出现了一个人。奥巴马知道这个人登记了列车上的乘客(ps:一般来说，乘客登记都是在列车运行的过程中进行的，这里我们假设这个乘客登记人在列车门口勤勤恳恳守护着)。注册完成后，奥巴马被允许进入。

那么，你在注册过程中做了什么？

首先，登记员手持设备会对火车票中芯片写的信息进行分析，如果没有问题，就会开始用手中的登记簿登记信息，主要包括车主信息、过期时间、审核人等。

这样，整个过程就是一个HandleSignInAsync的过程。换句话说，cookie登录上下文信息被组装并写入Http流的头部，该头部也被写入客户端浏览器Cookie。

至此，整个过程已经结束，让我们来看看代码：

//我只在方法中列出了流程的核心部分，删除了所有影响阅读的部分。受保护覆盖异步任务句柄signinasync(登录上下文登录){//分析chip var结果中的信息=wait surecokieticket()；//组织登录上下文，设置到期时间等。//使用数据保护对寄存器var cookie值=options . ticket data format . protect(ticket)上的信息进行加密；//写入浏览器头等待应用头(cookie值)；}如果不想知道更多，可以忽略这部分：

在HandleSignInAsync函数的源代码中，有一个非常巧妙的设计，那就是awaitooptions . events . signedin(signed context)；这样的代码是干什么的？前后叫了两次。有学生知道为什么吗？我将在下一篇文章中给出答案。

还记得之前HttpContext中的ClaimsPrincipal用户吗？是小李临时顶替的角色。现在值得了。他就是奥巴马。

奥巴马坐在座位上后，6个小时后从北京到杭州。他不得不佩服中国高铁的速度。欣赏完后期西湖的风景后，奥巴马给我们发了一张照片：

至此，CookieAuthentication中间件的整个工作流程已经完成，故事也就结束了。

以上是这两行代码背后的故事：

Varuser=新索赔负责人(新索赔标识(new[]{新索赔(索赔类型。名称，'奥巴马' }，cookieauthenticationdefaults。authenticationscheme))；等待HttpContext。身份验证。签名同步(CookieAuthenticationDefaults。AuthenticationScheme，用户)；摘要

在本文中，我们了解了AuthenticationManager和IAuthenticationHandler，并简单介绍了身份验证中间件和CookieAuthentication中间件，其中CookieAuthentication中间件是未来使用最多的中间件之一，本文也对其进行了详细的介绍。我认为这篇文章在未来的使用中应该没有问题。

有的同学可能会问，讲了这么多认证，跟Identity有什么关系？你没看到我一直在隐瞒他和Identity的关系吗？真的想知道吗？让我们读下一篇。