DotNetOpenAuth2 中的单个 AuthZ/AuthN 端点

Question

我正在实施一个身份验证服务器，该服务器将为我们公司生产的 Web 应用程序提供单点登录，目前正在使用 DotNetOpenAuth2。我的问题是 DNOA 是这样工作的（来自 Badrinarayanan Lakshmiraghavan 的 Apress 书 Pro ASP.NET Web API Security）

但我希望它像这样工作（我编辑的这张图片）：

有没有办法让它做到这一点，或者我应该使用另一个框架？我想这样做是为了让以后的开发人员更容易理解安全性。下面解释了为什么这很适合我的目的。

我们所有的网络应用程序都支持 HTTPS，并且位于 2 个父域中的 1 个域下（因此每个网络服务器都有 2 个 x509 证书，这些证书在 *.domain1.com 或 *.domain2.com 等子域上支持 SSL）。

我的计划是使用现有证书作为隐式共享密钥来加密由 DotNetOpenAuth2 生成的令牌。因此，在创建令牌时，AuthorizationServerAccessToken.ResourceServerEncryptionKey 将是 SSL 证书的公钥，AuthorizationServerAccessToken.AccessTokenSigningKey 将是 SSL 证书的私钥。

这样，我的任何服务器都能够以安全的方式解密用户令牌并从中提取授权声明。考虑到方案的简单性，我只想要一个接收用户名和密码并返回加密令牌的身份验证端点。

似乎这种简化使事情变得更加安全和易于实施。特别是因为我们可以取消随机数。一个可能的弱点是，获得网络证书私钥访问权限的攻击者也将能够欺骗用户身份验证令牌。但似乎假设您的 SSL 证书没有被泄露是可以的安全实践，因为 Web 应用程序的安全性通常完全取决于该假设。而且我不会在令牌中存储敏感信息，只是权限标志。

Answer 1

您的图表的主要目的似乎是省去授权代码交换步骤，只提供访问令牌。这是一个相关的post，我建议您阅读以说服自己相信这一步的有用性。另外，您真的想创建自己的类似 OAuth2.0 的授权协议，只是因为 OAuth2.0 令人困惑吗？我认为随着越来越多的开发人员采用 OAuth2.0，这些概念将开始变得不那么陌生。

Answer 2

我强烈推荐IdentityServer 来满足您的需求。我也即将为我的公司构建一个 IdentityServer，经过一些初步的尝试后，我发现它是最好的“自己动手”解决方案。另一个不错的部分是 Authentication 与 Authorization 分离，允许您在将来更换身份提供者（例如，如果您想将租户 ID 更改为路）或添加多个 Azure AD 租户。

此外，您可以更好地控制要传回给用户或守护程序的声明。