我已经阅读了很多关于 OpenID 和 OAuth 的文章，但在建立一些关于它们如何在基于服务的架构中工作的联系时遇到了困难。
这是我的场景:
- 我正在编写新的 ASP.NET Web API 服务(RESTful/JSON)
- 这些服务将由客户端应用程序(当前的桌面网站、新的移动网站，以及 future 可能的 PHP 网站或纯 JavaScript 客户端)使用
- 我们的桌面网站目前使用 ASP.NET Membership Provider (webforms)
我们正在创建的一组新的 API 服务应该处理所有事情，包括身份验证和授权。
我的问题是:
- 由于我们对访问我们的 API 的客户端应用程序有明确的控制(即这不是一个公共(public) API，而是一个用于集成经批准的合作伙伴的 API)，我们是否一定需要 OAuth？
- OpenID 会取代我们的 .NET 成员(member)功能，还是对其进行补充？
- 鉴于我们需要使用 Membership Provider 对旧系统的用户进行身份验证，我们是否需要使用某种 .NET Membership OpenID Provider，或者我们是否像往常一样进行身份验证并像我们目前那样授予用户一个 Membership Token做什么？
我想，总结一下:
- 我正在编写一些新服务
- 它们应该可供任何批准的客户端应用程序使用，供该客户端应用程序的用户使用
- 我们需要继续支持我们的 .NET 成员(member)数据
抱歉，这些是基本问题，但我相信它们很容易回答。谢谢!
最佳答案
看看 ThinkTecture 的 Identity Server
https://github.com/thinktecture/Thinktecture.IdentityServer.v2
它为用户存储使用存储库模式，并使用默认的成员(member)提供程序作为用户存储 - 您可以轻松地插入您的旧成员(member)提供程序。
OpenID connect 将在您的成员(member)提供者之上运行，您将启用该选项以仅允许注册依赖方 - 这意味着只有您批准的客户(应用程序)才能访问。
这看起来非常合适 - 希望对您有所帮助。
马特
关于asp.net - 关于 ASP.NET Web API RESTful 服务上的 OpenID/OAuth 的建议，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19234681/