我正在尝试了解为可以在任意数量的Web服务器上运行的应用程序创建身份验证机制时的选项。到目前为止，我只对使用（网络）服务器端会话管理身份验证方面的小型网站有经验。但是，只要我想添加更多Web服务器（或PaaS环境中的“Web实例”），这种方法显然就成了一个问题;绑定到特定计算机的身份验证状态来自我的理解，而不是您在使用负载平衡时所需要的（afaik粘性会话/粘性负载平衡是应该避免的）。我正在寻找一种解决方案，允许我动态地上下调整Web服务器/实例的数量，而无需考虑身份验证机制。
我认为实现此目标的唯一方法是从我的Web服务器中获取会话/身份验证状态。这就是我所说的“无国籍”。当然，这个状态必须暂时存储在某个地方，所以必须有一些不是无状态的东西。
我可以使用数据库服务器来管理所有身份验证会话。可以从每个http请求上的所有Web服务器访问数据库服务器，以请求用户的身份验证状态。但是，由于数据库服务器甚至比Web服务器更难扩展（这是我没有任何经验的假设），我只是将问题从Web服务器转移到数据库服务器。除此之外，我认为这不是性能方面的最佳解决方案。
我可以使用像memcached或redis这样的缓存服务器来管理会话以进行身份验证，而不是使用数据库服务器。我认为这会最小化可伸缩性问题，因为单个缓存服务器可以以高效的方式管理大量会话（或者我现在错了吗？）。但我有时会读到诸如“关于缓存的一个重要观点是它的行为就像缓存一样：你刚刚存储的数据可能会丢失。”。嗯，这将是一个问题。我不希望用户每2小时登录一次。我的问题是：如果缓存有足够的内存，为什么缓存中的数据会丢失？高速缓存服务器中的250MB内存是否足以同时管理超过一百万个会话而无需摆脱数据（当使用简单的键值对将会话ID映射到用户ID或反之）？
第三种解决方案可能是将auth sesson状态存储在由服务器签名且无法由客户端操纵的cookie中。但如果我没有错，服务器端就无法强制注销某个用户......
总结我的要求：
我想在负载均衡器后面上下调整Web服务器 auth系统应该处理它
应允许用户登录至少几天 像例如在stackoverflow.com上
我对最佳做法感兴趣。我认为有很多网站 面对同样的问题并找到解决方案。
答案 0 :(得分：6)
This github project是个好地方。实施在Play中！框架，但它是我认为你所追求的一个很好的解释。还有助于克服应用程序中固有的CSRF。
服务器在登录后发回auth_token（通过https）。 auth_token保存为cookie（只是因为它将被保留并可从客户端访问）。发出请求时，auth_token被放置为保存在cookie中的HTTP标头（通过JavaScript）。然后由服务器请求处理程序拉出并通过每个请求进行验证。所以它是一个cookie - 但不是用作cookie。如果你愿意，可以使用“两次烘焙”的cookie :)这些链接更详细地解释了。
我找到的另一个答案here on stack overflow解释了一个非常相似的事情。 “没有会话的会话”。
然后，如果你真的想深入了解它，请查看owasp.org上的CSRF预防，它解释了“General Recommendation: Synchronizer Token Pattern”标题下的类似技术
所有通信都应该是HTTPS。