我正在为 OpenId 提供商和依赖方实现 DotNetOpenAuth。在这两种情况下，服务器都位于负载均衡器后面，因此对于任何 HTTP 请求，我们不能假设我们会访问同一服务器。
看来 DotNetOpenAuth depends on the Session存储待处理的请求 key 。由于服务器可能会在请求之间发生变化，因此我们不能依赖标准的 InProc Session。不幸的是，我们无法成功实现 SQL 作为 Session 的存储。
我的问题是:将 PendingAuthenticationRequest 存储为客户端 cookie 是否安全？还有比使用 Session 更糟糕的吗？
最佳答案
ProviderEndpoint.PendingAuthenticationRequest 属性只是为了您的方便而存在，主要用于更简单的场景。如果它对您不起作用，请务必以其他方式存储它并完全忽略此属性。那里没有造成任何伤害。
最终， session 是由 HTTP cookie 跟踪的，因此如果您愿意，您当然可以将身份验证请求状态完全存储在 cookie 中，以便它在网络场环境中工作。另一种方法是根本不需要客户端(或服务器)跟踪状态，方法是直接在 OP 端点 URL 处理所有内容(包括身份验证)，或者使用包含所有内容的查询字符串从 OP 端点 URL 重定向用户。您需要跟踪的状态信息。但要小心后一种方法，因为您会将状态数据暴露给用户以查看并可能被篡改。
简而言之，您可以选择也可以不选择将用户 session 存储在 SQL 存储中。那应该没问题。我认为您遇到的问题(我们通过电子邮件讨论过)是您需要实现自己的 IProviderApplicationStore，它将在所有 Web 服务器之间共享的数据库中存储随机数和关联。这是必须要做的，并且与用户 session 状态正交，因为它存储在应用程序级别。
关于session - 网络场上的 DotNetOpenAuth，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3557514/