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