Security框架主要用于身份认证的，基本上所有Asp.net项目有意或者无意的都在使用的，框架的源码包含在Katana项目下。
最常见的使用方式或许就是SignIn来给客户端浏览器生成包含身份信息的Cookie了，在Cookie的有效期内所有对Web网站的访问都会携带这样的Cookie，被CookieMiddleware解析出身份信息并设置到HttpContext的User属性上。
我认为Security框架核心就两个类
1.AuthenticationMiddleware
将身份认证模块添加到应用程序的处理管道中，配置Options参数
2.AuthenticationHandler
真正处理身份认证的逻辑代码，当发起登录操作的时候会创建经过加密的身份信息Token以及每次Request请求到来时提取Token信息解析出对应的ClaimsIdentity
在AuthenticationMiddleware的Invoke方法中会获取一个对应的AuthenticationHandler实例，比如CookieAuthenticationHandler，其AuthenticateCoreAsync方法被执行，在方法体中，会尝试获取存放身份信息的Cookie，并解析出AuthenticationTicket实例，如果Token未过期那么就会返回这样一个AuthenticationTicket实例，最后其Identity属性将会被设置到HttpContext的User属性上，在验证的过程中可以通过配置Options的Provider（类型为ICookieAuthenticationProvider）来添加扩展，自定义决定是否成功返回AuthenticationTicket。
当我们熟悉上述两个类的源码，基本上身份认证的整体逻辑就了解的差不多了，另外我们真实项目中常用的还有一个OwinContext的类型为IAuthenticationManager的属性--Authentication，常用的是它的SignIn，SignOut，Challenge三个方法，它们本身的执行逻辑是很简单的就是将相应的参数信息保存起来，AuthenticationHandler会调用Response.OnSendingHeaders来注册一个返回Response信息前的执行逻辑，在这个执行逻辑中会分别尝试获取SignIn，SignOut，Challenge三个方法调用时所保存的参数信息。
1.在OnSendingHeaders的执行逻辑中如果判断出SignIn被执行了那么会获取到SignIn的AuthenticationTicket，调用TicketDataFormat的Protect方法将AuthenticationTicket序列化为字符串后设置到Cookie上，返回Response。在这个执行过程中Security框架为我们提供了一些扩展点，我们可以修改AuthenticationTicket的数据。
2.如果执行过SignOut，那么OnSendingHeaders的执行逻辑会尝试删除上一步所创建的包含身份信息的Cookie，并执行一条Redirect语句跳转到StartUp类中配置的LoginPath，同样也提供了扩展点方便使用者修改参数。
3.如果执行过Challenge，那么OnSendingHeaders的执行逻辑中判断得到Response.StatusCode为401，同时LoginPath存在数据，那么就会执行Redirect语句跳转到LoginPath
有一点需要注意如果配置了Token过期时间，并且SlidingExpiration为true（默认为true），同时request请求发生时尚未超时，那么Token会被renew的
（纯粹是为了下个月找工作而准备的一系列博文，每一篇都尽量精简，并非给初学者看的☺）