如何做到无状态（无会话）及cookie的认证？ [英] How to do stateless (session-less) & cookie-less authentication?

问题描述

鲍勃以实现一些使用Web应用程序。和：

Bob uses a web application in order to achieve something. And:

• 他的浏览器是关于饮食，因此它不支持的饼干。


• Web应用程序是很受欢迎的一个，它在给定时刻有很多用户交易的 - 它的比例的好。只要保持会话会强加限制并发连接的数量，当然，会带来不可忽略的性能损失，我们可能想有一个会话更少的系统：）

• His browser is on diet, therefore it does not support cookies.
• The web application is a popular one, it deals with a lot of users at a given moment - it has to scale well. As long as keeping session would impose a limit to the number of simultaneous connections, and, of course, will bring a non-negligible performance penalty, we might like to have a session-less system :)

一些重要的注意事项：

• 我们确实有运输保障（ HTTPS 的和最好的朋友）;


• 窗帘后面，Web应用程序代表了很多操作为外部服务在用户的代表电流（这些系统确实认识鲍勃作为他们的用户之一） - 这意味着我们必须转发Bob的凭据

• we do have transport security (HTTPS and its best friends);
• behind the curtains, the web application delegates a lot of operations to external services, on current user's behalf (those systems do recognize Bob as one of their users) - this means that we have to forward them Bob's credentials.

现在，我们该如何进行身份验证鲍勃（在每一个请求）？
这将是实现这样的事情一个合理的方式？

Now, how do we authenticate Bob (on each and every request)? Which would be a reasonable way to implement such a thing?

• 玩的网球的通过的 HTML表单的隐藏字段 ...的的球的包含凭据（用户名和放大器的凭据;密码）和双球拍的是浏览器，分别为Web应用程序。换句话说，我们可以通过表单字段而不是通过Cookie传输数据来回。在每个Web请求，浏览器的上岗证书。虽然，在单页的应用程序的情况下，这可能看起来像玩的壁球的反对橡胶壁，而不是玩的网球的，因为在 Web表单的包含凭证可能是更让的网页的整个生命周期的（和服务器将被配置为不提供凭证背面）。


• 存储用户名和放大器;密码在页面的上下文 - JavaScript的变量等单页这里需要的，恕我直言


• 加密令牌 - 基础的认证。在这种情况下，登录动作将导致在一个加密的安全令牌（用户名+密码+其他内容）的产生。该令牌将被送达回客户端和即将到来的请求将被标记陪同。这是否有意义？我们已经有HTTPS ...


• 其他...


• 最后一招：不这样做，存储凭据在会话中！ Session是不错的。带或不带饼干。

• playing tennis with the credentials via HTML form hidden fields... the ball contains the credentials (username & password) and the two rackets are the browser and the web application respectively. In other words, we may transport data back and forth via form fields instead of via cookies. At each web request, the browser posts the credentials. Though, in the case of a single-page application, this may look like playing squash against a rubber wall, instead of playing tennis, as the web form containing the credentials might be kept alive the entire lifetime of the web page (and the server will be configured not to offer the credentials back).
• storing the username & the password in the context of the page - JavaScript variables etc. Single-page required here, IMHO.
• encrypted token - based authentication. In this case, the log-in action would result in the generation of an encrypted security token (username + password + something else). This token would be served back to the client and the upcoming requests will be accompanied by the token. Does this make sense? We already have HTTPS...
• others...
• last resort: do not do this, store credentials in the session! Session is good. With or without cookies.

有没有任何网络/安全问题走进你的心灵，对于任何previously描述的想法呢？例如，

Does any web / security concern come into your mind, regarding any of the previously described ideas? For example,

• 的一次郊游的 - 我们可以保留一个时间戳，与凭证（时间标记=时间鲍勃进入他的凭据）一起。例如。在立即 - 时间戳>阈值后，我们可能会拒绝请求


• 的跨站点脚本的保护？ - 不应该以任何方式不同，对

• time-outing - we may keep a timestamp, along with the credentials (time-stamp = the time Bob entered he's credentials). E.g. when NOW - timestamp > threshold, we might deny the request.
• Cross-site scripting protection - should not be different in any way, right?

感谢您了很多抽出时间来阅读本：）

Thank you a lot for taking the time to reading this :)

问候，

安德烈

推荐答案

嗯，我爱这些问题 - 维持会话没有会话

Ah, I love these questions - maintaining a session without a session.

我已经在申请过程中评估我看到他就职于多种方式来做到这一点。其中一个流行的方式是你提到的的打网球的方式 - 在每个请求验证用户发送用户名和密码。这一点，在我看来，是不安全的，尤其是如果应用程序不是单页。它也不是可扩展的，特别是如果你要授权除在将来添加到您的应用程序的认证（虽然我想你可以建立基于登陆的东西太）

I've seen multiple ways to do this during my stints during application assessments. One of the popular ways is the playing tennis way that you mentioned - sending the username and password in every request to authenticate the user. This, in my opinion, is unsafe, especially if the application isn't single page. It is also not scalable, especially if you want to add authorization to your app in addition to authentication in the future (although I guess you could build something based on logins too)

一种流行的，虽然不是完全无状态机制（假设你有JavaScript执行）是嵌入在JavaScript中的会话cookie。在我的安全家伙在这个尖叫，但它可能实际上工作 - 每一个请求有一个 X-认证令牌头或类似的东西，而你映射到一个数据库，文件存储在存储器等在后端验证用户。这个令牌可以让你指定的任何时间超时，如果超时，用户必须重新登录。这是相当可扩展性 - 如果你把它存储在数据库中，它的一条SQL语句执行的，并用正确的指标，应采取很少的时间来执行，即使多个用户同时使用。负载测试在这里肯定会有助于虽然。如果我正确读取的问题，这将是你的加密令牌机制 - 尽管，我强烈建议你使用的加密的随机令牌说32个字符，与使用的用户名+密码+其他任何的组合 - 这样一来，它保持未predictable，但你仍然可以将其与用户ID或一些这样的东西联系起来。

One popular, although not completely stateless mechanism (assuming you have JavaScript execution) is to embed the session cookie in the JavaScript. The security guy in me is screaming at this, but it could actually work - every request has a X-Authentication-Token header or something like that, and you map that to a database, file-store in memory, etc. on the backend to validate the user. This token can have a timeout of whatever time you specified, and if it times out, the user has to log in again. It's fairly scalable - if you store it in a database, its one SQL statement executed, and with the correct indexes, it should take very little time to execute, even with multiple simultaneous users. Load testing here would definitely help though. If I read the question correctly, this would be your encrypted token mechanism - although, I would strongly suggest that you use a cryptographically random token of say 32 characters, versus using a combination of username + password + whatever else - this way, it stays unpredictable, but you can still associate it with the user ID or some such thing.

无论你最终使用，确保其安全地发送给您。 HTTPS保护你​​跨线，但如果您泄漏通过URL会话令牌不会保护你（或者更糟，通过URL凭据）。我会建议使用一个头，或者如果这是不可行的，通过一个POST请求，每次发送的令牌（这将意味着用户的浏览器中隐藏表单域。）使用POST请求应使用CSRF攻击防御的后一种方法，只为了以防万一，虽然我怀疑使用令牌本身可能是某种一个CSRF防御。

Whichever you do end up using, ensure it is sent to you safely. HTTPS protects you across the wire, but it doesn't protect you if you leak the session token via the URL (or worse, credentials via the URL). I would recommend using a header, or if that's not feasible, sending the token via a POST request every time (this would mean a hidden form field on the user's browser.) The latter approach of using a POST request should use CSRF defenses, just in case, though I suspect using the token itself might be some sort of a CSRF defense.

最后，但并非最不重要的，请确保您有在后端的一些机制，以清除过期的令牌。这一直是许多应用在过去的克星 - 认证令牌的一个快速增长的数据库，似乎永远不会消失。如果你需要支持多用户登录，请确保您无论是数量限制，或者对每个标记更短的时间限制。正如我之前所说的，负载测试可能是这个问题的答案。

Last, but not the least, make sure you have some mechanism in the backend to purge expired tokens. This has been the bane of many applications in the past - a rapidly growing database of authentication tokens which never seems to go away. If you need to support multiple user logins, make sure you either limit the number, or have a shorter time limit on each token. As I said before, load testing may be the answer to this.

有，我能想到的一些其它安全问题，但他们过于宽泛在这一阶段得到解决 - 如果你把所有的使用（和滥用）病例记住，你应该能够做到一个相当好这项制度的实施。

There are some other security concerns that I can think of, but they are too broad to be addressed at this stage - if you keep all the use (and abuse) cases in mind, you should probably be able to do a fairly good implementation of this system.

这篇关于如何做到无状态（无会话）及cookie的认证？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！