我想通過與數據庫中的用戶表關聯的自定義身份驗證來防範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身份驗證將不適合這種情況。 –