如何在OData上实现自定义身份验证
我想通过与数据库中的用户表关联的自定义身份验证来防范OData服务。我一直对这个问题感到困惑，并且徒劳无功地搜索了很长时间。我的意思是，是的，网上有很多文章，但它们只是相当微不足道，例如实施IPrincipal或IHttpContext基本身份验证。值得注意的是，他们中的很多人可以回到2010年的数据，其中OData不像今天那么成熟。所以我想知道是否有快速解决方案来基于数据库的自定义身份验证。如何在OData上实现自定义身份验证
任何指导将不胜感激！
OData和身份验证（甚至是授权）与大多数设计无关。这并不意味着OData协议栈不能提供对认证和授权的良好支持，只是OData协议本身不对其发表评论。除了协议外，Web API和WCF数据服务都致力于在此获得更好的支持。作为.NET社区的成员（而不是Microsoft员工），我认为期望这些堆栈实施授权API时他们可能会期待基于声明的授权是合理的。再一次，我想明确指出，我并不试图隐藏或透露任何计划 - 我只是在猜测认证和授权的去向。
简而言之，如果我在你的鞋子里，我会发现我可以在OAuth2和基于声明的身份验证之间实现最简单的交集，并使其适用于现在。现在制定您的声明和身份验证意味着您只需稍后考虑集成实际授权代码即可。
感谢您的出色答案。是的，OAuth现在越来越受欢迎，绝对是一个合适的解决方案。但是，就我而言，这并不可行，因为我必须将身份验证基于已存在的内部数据库。无论如何，我正在考虑是否适合使用基本身份验证和附加到每个请求的自定义头。 –
适当的不是我可以评论的，因为我不知道你的情况如何。 OAuth仍然是一个完全可行的候选人 - 您只需拥有一台处理这些凭证的OAuth服务器即可。另一种选择是表单身份验证。我认为我试图提出的基本观点是OData本身并不关心你用什么来验证。 –
另外，请注意，使用自定义标题（或任何其他“标准”auth机制之外的任何标题）会产生生态系统问题。例如，您可能无法将数据导入Excel。如果您使用Forms auth或Windows auth或OAuth，我相信您应该能够使大部分OData生态系统正常工作。 –
不清楚我对数据库中与用户表关联的定制认证意味着什么。 – Paparazzi
@Blam我的意思是实际上我已经拥有一个存储用户凭证的数据库。因此，默认的ASP.NET身份验证将不适合这种情况。 –