2

我已经阅读了很多关于 OpenID 和 OAuth 的内容，但是对于它们在基于服务的架构中的工作方式，我很难建立一些联系。

这是我的场景：

  • 我正在编写新的 ASP.NET Web API 服务（RESTful/JSON）
  • 这些服务将被客户端应用程序（当前的桌面网站、新的移动网站，以及未来可能的 PHP 网站或纯 JavaScript 客户端）使用
  • 我们的桌面网站目前使用 ASP.NET Membership Provider (webforms)

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

我的问题是：

  • 由于我们对访问我们 API 的客户端应用程序有明确的控制（即，这不是公共 API，而是用于集成已获批准的合作伙伴的 API），我们是否一定需要 OAuth？
  • OpenID 会取代我们的 .NET Membership 功能，还是补充它？
  • 鉴于我们需要使用 Membership Provider 对遗留系统的用户进行身份验证，我们是否需要使用某种 .NET Membership OpenID Provider，还是像往常一样进行身份验证并像现在一样授予用户一个 Membership Token？

我想，总结一下：

  • 我正在编写一些新服务
  • 它们应该可供任何已批准的客户端应用程序使用，供该客户端应用程序的用户使用
  • 我们需要继续支持我们的 .NET Membership 数据

抱歉，这些是基本问题，但我相信它们很容易回答。谢谢！

4

1 回答 1

5

查看 ThinkTecture 的身份服务器

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

它为用户存储使用存储库模式，并使用默认的成员资格提供程序作为用户存储——您将能够轻松地插入您的旧成员资格提供程序。

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

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

马特

于 2013-10-11T09:58:12.383 回答