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