我想基于WebAPI和AngularJs为应用程序创建授权机制。
我见过一些使用BasicHttpAuthentication的文章，但我真的不喜欢在每个请求上发送用户名和密码的整个想法。它不适合我的是因为我想使用OpenId身份验证，你没有用户名/密码对。
我正在考虑解决方案，但我真的不知道如何实现它。概念是用户在通常的Web应用程序中进行身份验证 - 使用用户/密码发布表单或选择OpenId提供程序。如果用户成功通过身份验证，则会将其放置在静态对象中，该对象将用户对象存储一定时间。接下来生成usertoken并将其传递给客户端应用程序。客户端将每个请求上的令牌传递给服务器，如果用户存在于上述静态对象中，并且具有相应的身份验证令牌，则有权获取数据。
首先 - 您认为这是解决问题的好方法吗？ 其次 - 如何在不使用cookie的情况下传递身份验证令牌？我想它应该位于请求标头中，就像在BasicHttpAuthentication中一样，但我真的不知道如何处理它。
答案 0 :(得分：1)
<强> BasicHttpAuthentication
我和你在一起感到很尴尬，在客户端上缓存用户名和密码，并在每次请求时永远转移它。可能对您有用的基本身份验证的另一个方面是缺少签名。除了更改密码之外，您无法“使基本身份验证会话无效”。另一方面，令牌通常会提供到期日期，如果您希望服务器端失效，您可以检查发布日期并说“发布日期xyz以前的任何令牌都无效”。
服务器状态
您提到“如果用户已成功通过身份验证，则会将其置于静态对象中”。但这与令牌无关？这听起来像是您想要实现身份验证会话的服务器状态管理，但这不是绝对必要的。令牌本身应足以进行用户身份验证，管理服务器状态是另一个潜在的障碍。当您考虑应用程序池回收或Web场环境时，服务器状态可能变得难以管理（如果您希望两个服务共享相同的身份验证令牌，但不需要与中央“身份验证服务器”进行通信以存储状态/会话，那该怎么办？ ？）
传递身份验证令牌
标题绝对是一个好地方。真的，还有哪里呢？饼干，标题，消息。除了浏览器客户端之外，cookie没有多大意义，并且在消息中包含它可能会使您的消息格式化一些，因此在我看来，标题是唯一有意义的剩余选项。
客户端实施
您没有指定，但我怀疑您是否有兴趣从.NET调用该服务？在这种情况下System.Net.Http.HttpClient可能是你的朋友。特别是DefaultRequestHeaders集合。您可以使用此选项添加自定义标头来存储您的身份验证令牌。
服务器实施
最近研究ASP.NET身份验证时，通过检查Mixed Authentication Disposition ASP.NET Module（MADAM），我学到了很多关于自定义的知识。我对使用MADAM并不感兴趣，但是从那篇文章中学习并检查source code给了我很多关于如何将我自己的身份验证模块插入到Web堆栈中的想法。