如何做无状态（无会话）＆amp;无cookie身份验证？

Question

Bob使用Web应用程序来实现某些目标。和

• 他的浏览器正在节食，因此它不支持 cookies 。
• 网络应用程序很受欢迎，它在特定时刻处理很多用户 - 它必须扩展。只要保持会话会强制限制同时连接数，当然会带来不可忽视的性能损失，我们可能希望无会话系统：）

一些重要说明：

• 我们确实有传输安全性（ HTTPS 及其最好的朋友）;
• 幕后，网络应用程序将大量操作委托给外部服务，代表当前的用户（这些系统确实将Bob视为其用户之一） - 这意味着我们必须转发他们的Bob凭据。

现在，我们如何对Bob进行身份验证（在每个请求中）？ 哪个是合理的方式来实现这样的事情？

• 通过 HTML表单隐藏字段使用凭据播放网球 ... 球包含凭据（用户名和密码）和两个球拍分别是浏览器和Web应用程序。换句话说，我们可以通过表单字段而不是通过cookie来回传输数据。在每个Web请求中，浏览器都会发布凭据。但是，对于单页应用程序，这可能看起来像是在橡皮墙上玩壁球，而不是像网球那样玩包含凭据的 Web表单可能会在网页的整个生命周期内保持活动状态（并且服务器将配置为不提供凭据）。
• 存储用户名＆amp;页面上下文中的密码 - JavaScript变量等。这里需要单页，恕我直言。
• 基于加密令牌的身份验证。在这种情况下，登录操作将导致生成加密的安全令牌（用户名+密码+其他内容）。该令牌将被返回给客户端，即将到来的请求将伴随令牌。这有意义吗？我们已经有了HTTPS ......
• 其他...
• 最后的手段：不要这样做，在会话中存储凭据！会议很好。有或没有饼干。

对于任何先前描述的想法，您是否会想到任何网络/安全问题？例如，

• 超时 - 我们可能会保留时间戳以及凭据（时间戳= Bob输入凭据的时间）。例如。当现在 - 时间戳＆gt;阈值，我们可能会拒绝该请求。
• 跨站点脚本保护 - 不应该有任何不同，对吗？

非常感谢您花时间阅读本文：）

Answer 1

啊，我喜欢这些问题 - 在没有会话的情况下维持会话。

在应用程序评估期间，我已经看到了多种方法来执行此操作。其中一种流行的方式是你提到的打网球方式 - 在每个请求中发送用户名和密码来验证用户身份。在我看来，这是不安全的，特别是如果应用程序不是单页面。它也是不可扩展的，特别是如果你想在未来的身份验证中添加授权给你的应用程序（虽然我猜你也可以根据登录构建一些东西）

一种流行的，虽然不是完全无状态的机制（假设你有JavaScript执行）是将会话cookie嵌入到JavaScript中。我这里的安全人员正在为此尖叫，但它实际上可以工作 - 每个请求都有一个X-Authentication-Token标题或者类似的东西，然后你将它映射到后端的数据库，内存中的文件存储等验证用户。此令牌可以在您指定的任何时间超时，如果超时，则用户必须再次登录。它具有相当的可扩展性 - 如果将其存储在数据库中，执行一个SQL语句，并且使用正确的索引，即使有多个并发用户，也只需要很少的时间来执行。这里负载测试肯定会有所帮助。如果我正确地阅读了这个问题，这将是你的加密令牌机制 - 尽管如此，我强烈建议你使用一个32字符的加密随机令牌，而不是使用用户名+密码+其他任何东西的组合 - 这样，它就会停留不可预测，但您仍然可以将其与用户ID或某些此类事物相关联。

无论您最终使用哪种方式，请确保将其安全发送给您。 HTTPS通过网络保护您，但如果您通过URL泄漏会话令牌（或者更糟糕的是，通过URL凭据），它不会保护您。我建议使用标头，或者如果这不可行，每次都通过POST请求发送令牌（这将意味着用户浏览器上的隐藏表单字段。）后一种使用POST请求的方法应该使用CSRF防御，只是如果我怀疑使用令牌本身可能是某种CSRF防御。

最后，但并非最不重要，请确保后端有一些机制来清除过期的令牌。这是过去许多应用程序的祸根 - 一个快速增长的身份验证令牌数据库，似乎永远不会消失。如果您需要支持多个用户登录，请确保限制数量，或者对每个令牌设置更短的时间限制。正如我之前所说，负载测试可能就是答案。

我还可以考虑其他一些安全问题，但它们太宽泛，无法在此阶段解决 - 如果您记住所有使用（和滥用）案例，您应该可以做到公平很好地实施了这个系统。

Answer 2

关于登录选项 - 我认为通常您也希望为来宾支持会话。

因此，如果要强制执行登录，则加密令牌选项可能会很好。某种方式对于客人会话也许也不错。 在另一个方向，我会在将令牌附加到URL和网球选项之间进行组合。

请注意，仅在URL中发送凭据可能很危险。例如，您可能会通过HTTP referer标头泄漏令牌，甚至可能只是检查您的流量或观看您的计算机的人。

另外，即使你可以使用cookies，我也会建议你添加随机令牌或随机verifer，以保护自己免受跨站点请求伪造（CSRF）攻击。