关于ASP.NET Web API RESTful服务上的OpenID/OAuth的建议

Question

我一直在阅读很多关于OpenID和OAuth的内容，但在编写一些关于如何在基于服务的体系结构中工作的连接时遇到了困难。

这里是我的情况：

• 我写
• 这些服务将通过客户端应用程序中使用新的ASP.NET Web API服务（基于REST/JSON）（当前桌面网站，新的移动网站，和可能的PHP的网站或在未来JavaScript的唯一客户端）
• 我们的桌面网站目前使用ASP.NET成员提供程序（web表单）

我们正在创建的新API应用程序应该处理所有事情，包括身份验证和授权。

我的问题是：

• 既然我们已经访问过我们的API（即这不是一个公共的API，而是一个整合批准的合作伙伴）我们一定需要OAuth的客户端应用程序明确的控制？
• OpenID会取代我们的.NET Membership功能，还是对它进行补充？
• 考虑到我们需要使用Membership Provider对传统系统进行身份验证，我们是否需要使用某种.NET Membership OpenID Provider，或者我们只是像往常一样进行身份验证，并向用户授予我们当前的Membership Token做？

我想，在总结：

• 我写了一些新的服务
• 他们应该被任何批准的客户端应用程序使用，该客户端应用程序的用户
• 我们需要继续支持我们的.NET会员数据

对不起，这些都是基本问题，但我相信他们很容易回答。谢谢！

Answer 1

看ThinkTecture的身份服务器

https://github.com/thinktecture/Thinktecture.IdentityServer.v2

它使用用户存储库模式，并使用默认成员资格提供作为用户存储 - 您将能够很容易地插入，在旧版成员资格提供。

OpenID connect将在您的会员供应商之上工作，并且您将启用该选项仅允许注册的依赖方 - 意味着只有您的已批准客户端（应用程序）才能访问。

这似乎是一个完美的结合 - 希望这会有所帮助。

马特