标签：介绍 核心 指正 uid 用户名 handler 运行 设计 employee
从本篇开始将围绕asp.net core身份验证写个小系列，希望你看完本系列后，脑子里对asp.net core的身份验证原理有个大致印象。
至于身份验证是啥？与授权有啥联系？就不介绍了，太啰嗦。你如果不晓得，自己去搜搜吧。
我的学习思路是详细看源码 > 总结得出一个宏观上的印象 + 如何使用。
如果发现有啥讲错的望指正，免得误导观众
我们偶尔会思考如何设计一个牛X的软件，其实通过对asp.net core框架本身的学习更划算，一来我们熟悉了asp.net core框架，再者我们学习了微软碰到需求是如何设计的。
计划：
必备知识：asp.net core、配置、选项、依赖注入、中间件等...
参考：源码、Artech、mvc5基于owin的身份验证视频
注意：本篇只讲涉及到的几个概念
常见的身份验证方式：
为了便于理解后续的概念，下面先以最常见的 用户密码+cookie的身份验证方式说说核心流程
登录：
携带cookie请求：
注意：若身份验证中间件即使没有解析得到用户标识，请求也会继续执行，此时以匿名用户的身份在访问系统
它用来表示当前登录的用户，它包含用户Id + 一些与权限检查相关的附件属性（角色、所属部门）。
当请求抵达时“身份验证中间件”将从请求中解析得到当前用户，如果获取成功则赋值给HttpContext.User属性
所以对于我们来说通常有两个场景使用它
在任意能访问HttpContext的地方获取当前用户，比如在Controller中。
如果需要自定义实现身份验证，则我们要想方设法从请求中解析得到用户，并赋值给HttpContext.User
现在你至少对用户标识这个概念有点理解了，如果要刨根问底儿就自行搜索关键字：asp.net Claims
也许你曾经做过或见过这样的设计，定义Employee表示当前系统的用户，当用户登录时会从数据库查询得到对应的Employee，若账号密码验证通过则将其放入Session或缓存中。下次访问时直接从Session/缓存中获取当前用户。个人觉得这种设计存在如下问题：
既然有了上面的用户标识，何不直接在登录时加密这个标识，解析时直接解密得到呢？因为我们还需要额外的控制，比如过期时间，这个属性只是在身份验证阶段来判断是否过期，在我们（如Controller.Action中）使用用户标识的时候并不需要此字段，类似的额外字段根据不同的身份验证方式可能有很多，因此定义了“用户票证”这个概念，它包含 用户标识 + 身份验证过程中需要的额外属性（如得到用户标识的时间、过期时间等）
参考上面的用户名密码+cookie身份验证流程我们发现有几个核心的处理步骤：
身份验证处理器就是用来定义这些步骤的
asp.net core中定义了对应的接口、和抽象类，不同的身份验证方式有不的实现类，比如基于token的身份验证方式在SignIn时直接加密票证然后返回这个字符串（而不是写入cookie）
这些步骤都是围绕身份验证来定义的，在不同地方来调用（比如在登录页对于的Action、在请求抵达时、在授权中间件中）
在上述身份验证处理的多个步骤中会用到一些选项数据，比如基于cookie的身份验证 cookeName、有效时长、再比如从请求时从cookie中解析得到用户标识后回调选项中的某个回调函数，允许我们的代码向调试中添加额外数据，或者干脆替换整个标识。
所以身份验证选项用来允许我们控制AuthenticationHandler的执行。不同的身份验证方式有不同的选项对象，它们直接或间接实现AuthenticationSchemeOptions
总结性的说：身份验证方案 = 名称 + 身份验证处理器类型，暂时可以理解一种身份验证方式 对应 一个身份验证方案，比如：
基于用户名密码+cookie的身份验证方式 对应的 身份验证方案为：new AuthenticationScheme("UIDPWDCookie",typeof(CookieAuthenticationHandler))
基于用户名密码+token 的身份验证方式 对应的 身份验证方案为：new AuthenticationScheme("JwtBearer",typeof(JwtBearerHandler))
身份验证方案在程序启动阶段配置，启动后形成一个身份验证方案列表。
程序运行阶段从这个列表中取出制定方案，得到对应的处理器类型，然后创建它，最后调用这个处理器做相应处理
比如登录操作的Action中xxx.SignIn("方案名") > 通过方案名找到方案从而得到对应的处理器类型 > 创建处理器 > 调用其SignIn方法
一种特殊的情况可能多种方案使用同一个身份验证处理器类型，这个后续的集成第三方登录来说
我们说一个系统可能同时支持多种身份验证方案，因此我们需要一个容器，可以把它理解为Dictionary<方案名,身份验证方案>
可以暂时把它理解为Dictionary<方案名, 身份验证处理器容器>，因为这个对象是每次请求都会创建，并且它提供AuthenticationHandler时时从方案列表中去找到制定方案从而得到对应的处理器类型然后创建的。如果不理解没关系，下一篇讲流程就懂了
身份验证中的步骤是在多个地方被调用的，身份验证中间件、授权中间件、登录的Action(如：AccountController.SignIn())、注销的Action(如：AccountController.SignOut())，身份验证的核心方法定义在这个类中，但它本质上还是去找到对应的身份验证处理器并调用其同名方法。其实这些方法还进一步以扩展方法的形式定义到HttpContext上了。以SignIn方法为例
HttpContext.SignIn() > AuthenticationService.SignIn() > AuthenticationHandler.SignIn()
这一篇只尽量简单的说了下身份验证涉及到的几个核心概念，如果不明白的可以留言或等到下篇结合理解。下一篇将以用户名密码+cookie的身份验证方式来详细梳理下流程。
标签：介绍 核心 指正 uid 用户名 handler 运行 设计 employee
原文地址：https://www.cnblogs.com/jionsoft/p/12289419.html
