DotNetOpenAuth2 中的单个 AuthZ/AuthN 端点

Posted 2023-03-04

【中文标题】DotNetOpenAuth2 中的单个 AuthZ/AuthN 端点

【英文标题】：Single AuthZ/AuthN Endpoint in DotNetOpenAuth2

【发布时间】：2017-10-01 20:57:34

【问题描述】：

我正在实施一个身份验证服务器，该服务器将为我们公司生产的 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 应用程序的安全性通常完全取决于该假设。而且我不会在令牌中存储敏感信息，只是权限标志。

【参考方案1】：

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

【讨论】：

阅读那篇文章，我认为它不适用于我的情况。如果我理解正确，这个流程是为了让我的应用程序服务器 (RP) 可以使用临时代码直接使用 HTTPS 从 STS 请求令牌，以应对我的应用程序运行 HTTP 并且浏览器不安全的情况将令牌发布到我的应用程序。我打算将令牌保留为客户端上的黑匣子（加密和签名），并将其用作跨多个应用程序/服务的身份验证方法。此外，我所有的应用程序都在运行 HTTPS。

【参考方案2】：

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

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

【讨论】：

好的，我们现在试试框架#3。我假设它有加密和签署 JWT 的方法。

据我所知。我一直在玩 IdentityServer4，它处理 JWT 加密/解密，但我很确定 v3 以这种方式具有相同的能力。我找到的文档非常详细。祝你好运。

哦，不。我将使用 v4，我的意思是它是我在查看 Thinktecture 的 ID Server 和 DotNetOpenAuth 后要尝试的第三个框架。

啊...有点开销，但似乎值得。除了网站上的文档，我发现这个博客也很有帮助：scottbrady91.com/Identity-Server/…

在一天结束的时候，即使是 Identity Server 也并不真正适合我想要做的事情，这实际上只是单点登录。只滚动我自己的令牌并在我的服务器上使用对称加密（它们都可以共享对称密钥）更简单。