我目前正与一家正在为一套新的多租户应用程序做出架构决策的公司签订合同。另一位承包商坚持认为我们应该使用基于声明的身份。我知道这是现在最热门的事情，但鉴于客户的情况，我不能肯定他的建议。
应用程序将面向服务，构建在.NET堆栈上，并严重依赖ASP.NET Web API。客户端应用程序（Web，Mobile和WPF）将相当愚蠢，消耗业务规则/功能的Web API服务。
服务的一部分将被视为单独的产品，并将公开供公司的业务合作伙伴使用。
这些应用程序将作为托管解决方案和内部部署解决方案提供，因为他们的一些客户希望自己托管所有内容，甚至可能无法访问互联网。
每个＆＃34;租户＆＃34;，无论是在托管解决方案上还是使用本地解决方案，都将负责维护其用户帐户，安全组和组成员身份。
对于内部部署解决方案，我们不能假设主机位置将具有Active Directory或任何其他基础结构。实际上，我们应该假设他们除了给予他们之外别无其他。
我理解基于声明的身份背后的概念，但我没有看到像这样的场景中的好处。客户端不会（也绝不会）希望用户使用来自Facebook，Google等的ID登录。每个用户都将使用他们的电子邮件地址登录，这可以是从gmail帐户到MomAndPopsEmailDomain.com电子邮件地址的任何内容。
为了使用声明进行此项工作，我们是否必须为公司构建可用于其托管解决方案的STS，并且还可以与任何内部部署安装一起分发以供独立使用？如果是这样，那么仅仅滚动我们自己的会员/身份提供商来验证用户并生成用户的授权令牌（群组成员资格信息）会带来什么好处呢？
在针对WebAPI服务进行身份验证时，声明是否更容易？
答案 0 :(得分：1)
基于声明的身份验证很好，但根据您的描述，它可能不是该方案的最佳选择，因为如果需求发生变化，它会将您描绘成一个角落。就个人而言，我会将OAuth 2.0与我自己的OAuth安全服务（可能是现有的web api的一部分）一起使用，因为在使用您无法控制的移动应用程序时它更像是一个标准，它将您的系统设置为能够维护用户名和密码。
您说客户端应用程序维护用户名和密码。所以，我会有一个OAuth安全服务，用一个刷新令牌发出一个持票人令牌。将为客户端应用程序提供系统将维护的api密钥，当他们请求令牌时，他们需要提供该API密钥，您将验证并发送回令牌。从那里，客户端将在每个请求的http头中发送该令牌。当令牌过期时，刷新令牌可用于获取新令牌。
如果要求更改为系统维护用户名和密码所需的位置，则只需修改OAuth令牌服务器以验证/授权用户以及api密钥。然后，对于具有密码的用户，OAuth安全服务将具有到客户端将显示的登录页面的重定向地址，并且最终用户将登录到该登录页面。这样客户端应用程序永远不会看到用户名和密码。
这是一个很好的视频 - http://vimeo.com/user22258446/review/79095048/9a4d62f61c
以下是如何实现承载令牌的示例。在Thinktecture.IdentityModel / samples / OAuth2 / EmbeddedResourceOwnerFlowWithRefreshTokens / EmbeddedAuthorizationServer - https://github.com/thinktecture/Thinktecture.IdentityModel
中打开项目我希望有所帮助。