.NET 4.5、MVC 5：自从上次接触我的网站身份验证功能以来，ClaimsAuthenticationManager、IAuthenticationFilter、OWIN Forms Authentication和ClaimsPrincipals都是新的。我发现所有文档都缺乏明确指出“这个”或“那个”是正确的方式。我甚至无法确定哪些功能是相互排斥的。
这份文件说旧的ASP.NET FormsAuthenticationModule不支持Claims，但新的OWIN不支持无cookie。然而，我感觉OWIN是未来的特性？
走向正确方向的推动将不胜感激，我的大脑在这个问题上被烤焦了。
在MVC中，IAuthorizationFilter通常用于执行自定义身份验证。使用该过滤器的原因在于应用程序具有两个授权规范和一个身份验证规范的情况下。两种选择 - 将身份验证规范添加到单个任意授权例程中，或将这三个规范全部创建为不同的IAuthorizationFilter - 都意味着我们不能确保首先进行身份验证。
IAuthenticationFilter最初添加到MVC程序集中以解决此问题，然后被重定位以供WebAPI使用。可以在这里找到一篇相关文章; ASP.NET Web API Security Filters。
严格来说，IAuthenticationFilter和OWIN身份验证并不是互斥的，但OWIN身份验证将首先发生，并可能妨碍同时使用两者的任何意图。
OWIN表单身份验证是一个令人困惑的短语，我从阅读一篇措辞不当的文章（上面链接的文章）中得到了这个短语。它代表两个非依赖解决方案组件：
“解决方案”的“表单”方面仍然与以前的表单身份验证相同。它是授权失败的结果（例如由
[Authorize]属性或web.config <authorization>元素引起的），并配对重定向到登录处理程序表单。（您选择的技术将确定在哪里配置该重定向URL。对于OWIN，您将在CookieAuthenticationOptions中进行配置。）以前，社交登录是通过重定向和称为OAuthWebSecurity的MessageHandler来实现的。 OWIN提供了一种机制，既可以重定向，又可以处理身份验证提供程序回调；有关更多信息，请阅读Creating Custom OAuth Middleware for MVC 5。
ClaimsAuthenticationManager并不像它听起来的那样。它实际上是Windows Identity Foundation（WIF）已经执行的身份验证过程的尾部方面。它旨在转换该过程产生的声明以满足您的自定义需求。例如，Claims列表可能包括用户名，您可以从数据库中查找频繁访问的角色或权限，并将这些添加到Claims列表以提高性能。
它适用于使用WIF的任何地方。相对于当前的ASP.NET Web应用程序，这将意味着OWIN。
没错。在现代ASP.NET Web应用程序中，您可能会使用OWIN、WIF和cookies。如果您使用“盒装材料”，则需要接受这一点，以及WebForms和VB.NET在此版本中的死亡。
因此，既然您可能会进行OWIN身份验证，这里有一系列关于该主题的优秀文章; 这个OWIN是什么？
OWIN更多地是在最小化服务Web页面的堆栈方面具有更宏大的范围，而最小化堆栈是未来的新浪潮(就像node.js)。所提到的"OWIN身份验证中间件"，Brock Allen在这里表述得最好:
使用.NET 4.5.1对于ASP.NET应用程序，处理“单个用户帐户”（以及Visual Studio 2013中的模板）的所有基础代码都是新的。这意味着对于基于cookie的身份验证，我们不再使用Forms身份验证，对于外部身份提供者，我们也不再使用DotNetOpenAuth。
替换品是一个名为OWIN身份验证中间件的框架，它针对OWIN API进行了定位。我不打算在这里说明OWIN（这是一篇关于该主题的好文章），但简而言之，它是Web主机的抽象API。许多框架，如Web API和SignalR（以及其他非Microsoft框架）都编码到此抽象中，因此它们不需要任何特定的Web主机（如IIS）。