如何做无状态（无会话）和无cookie的身份validation？
Bob使用Web应用程序来实现某些function。 和：
- 他的浏览器正在节食，因此它不支持cookies 。
- Web应用程序是一个非常stream行的应用程序，它在特定时刻处理很多用户 – 它必须很好地扩展 。 只要保持会话会对同时连接的数量施加限制 ，当然会带来不可忽视的性能损失 ，所以我们可能希望有一个无会话的系统:)
一些重要的说明：
- 我们确实有运输安全 （ HTTPS及其最好的朋友）;
- 在幕后，Web应用程序将代表当前用户的许多操作委托给外部服务 （这些系统将Bob识别为其用户之一） – 这意味着我们必须将Bob的凭据转发给他们 。
现在，我们如何validation鲍勃（每个请求）？ 这将是一个合理的方式来实现这样的事情？
- 通过HTMLforms的隐藏字段与证书打网球 … 球包含的凭据（ 用户名和密码 ）和两个球拍分别是浏览器和Web应用程序。 换句话说，我们可以通过表单域而不是通过cookie来回传输数据。 在每个Web请求中，浏览器都会发布凭证。 尽pipe在单页应用的情况下，这可能看起来像在墙壁上打壁球 ，而不是打网球 ，因为包含凭证的网页表单可能在网页的整个生命周期（以及服务器将被configuration为不提供凭证）。
- 存储在页面的上下文中的用户名和密码 – JavaScriptvariables等单页需要在这里，恕我直言。
- encryption的基于令牌的authentication。 在这种情况下，login操作将导致生成一个encryption的安全令牌（用户名+密码+其他）。 这个令牌将被返回给客户端，并且即将到来的请求将伴随令牌。 这有道理吗？ 我们已经有HTTPS …
- 其他…
- 最后的手段：不要这样做，在会话中存储凭据！ 会议是好的。 有或没有cookies。
关于前面提到的任何想法，是否会出现任何networking/安全问题？ 例如，
- 超时 – 我们可能会保留一个时间戳 ，以及证书（时间戳=鲍勃input证书的时间）。 例如，当NOW – 时间戳>阈值时 ，我们可能会拒绝该请求。
- 跨站点脚本保护 – 不应有任何不同，对吧？
非常感谢您花时间阅读此:)
啊，我喜欢这些问题 – 没有一个会议保持一个会议。
我在应用程序评估期间看到了多种方式来执行此操作。 其中一种stream行的方式是你提到的打网球的方式 – 在每个请求中发送用户名和密码来authentication用户。 这在我看来是不安全的，尤其是如果应用程序不是单页。 这也是不可扩展的，尤其是如果你想在未来的authentication之外添加授权到你的应用程序（虽然我猜你也可以build立一些基于login的东西）
一个stream行的，尽pipe不是完全无状态的机制（假设你有JavaScript执行）是将会话cookieembedded到JavaScript中。 我的安全人员正在尖叫，但实际上它可以工作 – 每个请求都有一个X-Authentication-Token头或类似的东西，然后将其映射到后端的数据库，内存中的文件存储等validation用户。 这个令牌可以有任何时间的超时，如果超时，用户必须再次login。 它具有相当的可扩展性 – 如果将其存储在数据库中，则执行一条SQL语句，并且使用正确的索引，即使使用多个同时用户，执行所需的时间也很less。 在这里加载testing肯定会有所帮助。 如果我正确地阅读这个问题，这将是你的encryption的令牌机制 – 虽然，我强烈build议你使用一个32位字符的密码随机令牌，而不是使用用户名+密码+其他任何组合 – 这样，它保持不可预知的，但你仍然可以将它与用户ID或一些这样的事情联系起来。
无论你最终使用什么，确保它被安全地发送给你。 HTTPS通过线路保护您，但是如果您通过URL（或者更糟糕的是，通过URL访问凭证）泄露会话令牌，则无法保护您。 我build议使用头，或者如果这是不可行的，每次都通过POST请求发送令牌（这将意味着在用户的浏览器上隐藏的表单字段）。后一种使用POST请求的方法应该使用CSRF防御在这种情况下，虽然我怀疑使用令牌本身可能是某种CSRF防御。
最后，但并非最不重要，请确保您在后端有一些机制来清除过期的令牌。 过去，这一直是许多应用程序的祸根 – 一个快速增长的身份validation令牌数据库，它似乎永远不会消失。 如果您需要支持多个用户login，请确保限制数量，或者每个令牌的时间限制较短。 正如我之前所说，负载testing可能是对此的答案。
还有其他一些我能想到的安全问题，但是这些问题太广泛了，无法在这个阶段加以解决 – 如果你牢记所有的使用（和滥用）的情况，你应该可以做一个相当好的实施这个系统。
关于login选项 – 我认为你通常也想为客人提供会话支持。
所以，如果你想强制login，encryption的令牌选项可能是好的。 某种程度上也可能是客人会议。 在另一个方向，我会结合之间的标记附加到url和网球选项。
注意，仅在URL中发送凭据可能是危险的。 例如，您可能会通过HTTP referer头，甚至只是检查您的stream量或观看您的计算机泄漏令牌。
另一件事，即使你可以使用cookies，我也会build议你添加随机标记或随机标记，以保护自己免受跨站请求伪造（CSRF）攻击。
