Bob使用Web应用程序来实现某些目标 . 和：
-
他的浏览器正在节食，因此它不支持 cookies .
-
网络应用程序很受欢迎，它在特定时刻处理了很多用户 - 它必须很好地扩展 . 只要保持会话会强加 a limit to the number of simultaneous connections ，当然会带来一个不可忽视的 performance penalty ，我们可能希望有一个无会话系统:)
Some important notes:
- 我们有 transport security （HTTPS及其最好的朋友）;
幕后 - ，Web应用程序将大量操作委托给 external services ，当前 user's behalf （这些系统确实将Bob视为其用户之一） - 这意味着 we have to forward them Bob's credentials .
现在，我们如何验证Bob（在每个请求上）？哪个是合理的方式来实现这样的事情？
-
使用凭证通过 HTML form hidden fields 打网球...球包含凭据（ username & password ），两个球拍分别是浏览器和Web应用程序 . 换句话说，我们可以通过表单字段而不是通过cookie来回传输数据 . 在每个Web请求中，浏览器都会发布凭据 . 虽然，在 single-page application 的情况下，这可能看起来像在橡胶墙上打壁球而不是打网球，因为包含凭证的网络表单可能在网页的整个生命周期中保持活动（并且服务器将被配置不提供凭证） .
-
在页面上下文中存储用户名和密码 - JavaScript变量等 . 这里需要单页，恕我直言 .
-
加密的基于令牌的身份验证 . 在这种情况下，登录操作将导致生成加密的安全令牌（用户名密码等） . 该令牌将被返回给客户端，即将到来的请求将伴随令牌 . 这有意义吗？我们已经有了HTTPS ......
-
其他人......
-
不得已：不要这样做，在会话中存储凭据！ Session 很好 . 有或没有 Cookies .
关于任何先前描述的想法，是否存在任何网络/安全问题？例如，
-
超时 - 我们可以保留 timestamp ，以及凭证（时间戳= Bob输入凭据的时间） . 例如 . 当 NOW - timestamp > threshold 时，我们可能会拒绝该请求 .
-
跨站点脚本保护 - 不应该有任何不同，对吧？
非常感谢您花时间阅读本文:)
2 回答
啊，我喜欢这些问题 - 在没有会话的情况下维持会话 .
在应用程序评估期间，我已经看到了多种方法来执行此操作 . 其中一种流行的方式是你提到的打网球方式 - 在每个请求中发送用户名和密码来验证用户 . 在我看来，这是不安全的，特别是如果应用程序不是单页面 . 它也是不可扩展的，特别是如果你想在未来的身份验证中添加授权给你的应用程序（虽然我猜你也可以根据登录构建一些东西）
一种流行的，虽然不是完全无状态的机制（假设你有JavaScript执行）是在JavaScript中嵌入会话cookie . 我这里的安全人员正在为此而尖叫，但它实际上可以工作 - 每个请求都有一个
X-Authentication-TokenHeaders 或类似的东西，然后你将它映射到后端的数据库，内存中的文件存储等，以验证用户 . 此令牌可以在您指定的任何时间超时，如果超时，则用户必须再次登录 . 它具有相当的可扩展性 - 如果将其存储在数据库中，执行一个SQL语句，并且使用正确的索引，即使有多个并发用户，也只需要很少的时间来执行 . 这里负载测试肯定会有所帮助 . 如果我正确地阅读了这个问题，这将是你的加密令牌机制 - 尽管如此，我强烈建议你使用32字符的加密随机令牌，而不是使用用户名密码的组合 - 这样，它就会无法预测，但您仍然可以将其与用户ID或某些此类内容相关联 .无论您最终使用哪种，请确保它安全地发送给您 . HTTPS通过网络保护您，但如果您通过URL泄漏会话令牌（或者更糟糕的是，通过URL凭据），它不会保护您 . 我建议使用标头，或者如果这不可行，每次都通过POST请求发送令牌（这将意味着用户浏览器上的隐藏表单字段 . ）后一种使用POST请求的方法应该使用CSRF防御，只是万一，虽然我怀疑使用令牌本身可能是某种CSRF防御 .
最后，但并非最不重要，请确保后端有一些机制来清除过期的令牌 . 这是过去许多应用程序的祸根 - 一个快速增长的身份验证令牌数据库，似乎永远不会消失 . 如果你需要要支持多个用户登录，请确保限制数量，或者对每个令牌设置更短的时间限制 . 正如我之前所说，负载测试可能就是答案 .
还有其他一些我可以想到的安全问题，但它们太广泛了，无法在此阶段解决 - 如果你记住所有的使用（和滥用）案例，你应该能够做一个相当好的实现这个系统 .
关于登录选项 - 我认为通常您也希望为访客支持会话 .
因此，如果要强制执行登录，则加密令牌选项可能会很好 . 某种方式对于客人会话也许也不错 . 在另一个方向，我会在将令牌附加到URL和网球选项之间进行组合 .
请注意，仅在URL中发送凭据可能很危险 . 例如，您可能会通过HTTP referer标头泄漏令牌，甚至可能只是检查您的流量或监视您的计算机的人 .
另一件事，即使你可以使用cookies，我建议你添加随机令牌或随机verifer，以保护自己免受跨站点请求伪造（CSRF）攻击 .