为JWT令牌服务器端处理的最佳做法 [英] Best practices for server-side handling of JWT tokens

问题描述

（从<衍生的href=\"http://stackoverflow.com/questions/30494383/using-jwt-with-active-directory-authentication-in-nodejs-backend\">this线程，因为这实在是自己的，而不是专门来等的NodeJS）

(spawned from this thread since this is really a question of its own and not specific to NodeJS etc)

我实现与验证的REST API服务器，我已经成功地实施了智威汤逊令牌处理功能，使用户可通过A /登录端点的用户名/密码，在其上从服务器的秘密生成的JWT令牌和登录返回到客户端。令牌然后从客户端传递到每个认证的API请求的服务器，在其上的服务器秘密用来验证令牌

I'm implementing a REST API server with authentication, and I have successfully implemented JWT token handling so that a user can login through a /login endpoint with username/password, upon which a JWT token is generated from a server secret and returned to the client. The token is then passed from the client to the server in each authenticated API request, upon which the server secret is used to verify the token.

不过，我想了解的最佳做法究竟是如何以及在多大程度上令牌应验证，做一个真正安全的系统。究竟是什么应该确认令牌参与？它是足够的签名可以使用服务器秘密进行验证，或者我应该也交叉核对存储在服务器的一些数据令牌和/或令牌有效载荷？

However, I am trying to understand the best practices for exactly how and to what extent the token should be validated, to make a truly secure system. Exactly what should be involved in "validating" the token? Is it enough that the signature can be verified using the server-secret, or should I also cross-check the token and/or token payload against some data stored in the server?

一个基于令牌的认证系统将只在提供，它的同等或更难以获得令牌比，以获得用户的密码的每个请求传递的用户名/密码一样安全。然而，在我见过的例子，产生一个令牌所需的唯一信息是用户名和服务器端的秘密。这是否意味着承担服务器秘密恶意用户获得的知识，他现在可以代表的任何的用户，从而有机会获得不仅是一个给定的用户作为会产生令牌一分钟是这样的事实，如果获得一个密码，但事实的所有的用户帐户？

A token based authentication system will only be as safe as passing username/password in each request provided that it's equally or more difficult to obtain a token than to obtain a user's password. However, in the examples I've seen, the only information required to produce a token is the username and the server-side secret. Doesn't this mean that assuming for a minute that a malicious user gains knowledge of the server secret, he can now produce tokens on behalf of any user, thereby having access not only to one given user as would be the fact if a password was obtained, but in fact to all user accounts?

这使我想到的问题：

1）应JWT令牌验证限于验证令牌本身的签名，仅仅依靠服务器秘密的完整性，或伴有一个单独的验证机制？

1) Should JWT token validation be limited to verifying the signature of the token itself, relying on the integrity of the server secret alone, or accompanied by a separate validation mechanism?

• 在某些情况下，我见过的结合使用令牌和服务器会话，其中在通过/登录端点登录成功建立会话。 API请求验证该令牌，并且还比较与存储在会话一些数据令牌中找到的德$ C $光盘的数据。然而，使用会话使用cookie意味着，在某种意义上，它违背了使用令牌为基础的方法的目的。它也可能导致某些客户端的问题。

• In some cases I've seen the combined use of tokens and server sessions where upon successful login through the /login endpoint a session is established. API requests validate the token, and also compare the decoded data found in the token with some data stored in the session. However, using sessions means using cookies, and in some sense it defeats the purpose of using a token based approach. It also may cause problems for certain clients.

可以想象服务器将所有的令牌目前使用的内存缓存或类似的，以确保即使服务器的秘密被泄露，这样攻击者可能会产生有效标记，只有那名确切的令牌通过/登录端点产生将被接受。这是合理的，或只是多余/矫枉过正？

One could imagine the server keeping all tokens currently in use in a memcache or similar, to ensure that even if the server secret is compromised so that an attacker may produce "valid" tokens, only the exact tokens that were generated through the /login endpoint would be accepted. Is this reasonable or just redundant/overkill?

2）若智威汤逊签名验证是验证令牌，这意味着服务器秘密的完整性断裂点的唯一手段，应该如何服务器秘密进行管理？从环境变量读取和创建（随机？）每个堆栈部署一次？重新newed或定期轮换（如果有的话，如何处理被旋转之前创建的，但需要旋转后进行验证现有的有效标记，也许这是不够的，如果服务器持有到目前，在任何previous秘密给定的时间）？别的东西吗？

2) If JWT signature verification is the only means of validating tokens, meaning the integrity of the server secret is the breaking point, how should server secrets be managed? Read from an environment variable and created (randomized?) once per deployed stack? Re-newed or rotated periodically (and if so, how to handle existing valid tokens that were created before rotation but needs to be validated after rotation, perhaps it's enough if the server holds on to the current and the previous secret at any given time)? Something else?

也许我只是过于偏执，当涉及到的服务器密码的风险受到损害，这是当然的，需要在所有密码的情况下得到解决一个更一般的问题...

Maybe I'm simply being overly paranoid when it comes to the risk of the server secret being compromised, which is of course a more general problem that needs to be addressed in all cryptographic situations...

推荐答案

我一直在玩令牌我的应用程序也是如此。虽然我不是专家，以任何方式，我可以分享我的一些经验和想法的问题。

I've been playing with tokens for my application as well. While I'm not an expert by any means, I can share some of my experiences and thoughts on the matter.

JWTs的点实质上是完整性。它为您的服务器的机制验证已给它提供的令牌是真正的，被你的服务器提供。通过你的秘密生成的签名是提供了这一点。所以，是的，如果你的秘密被泄露不知何故，个别可以生成你的服务器会认为是自己的标记。基于令牌的系统仍比仅仅是因为签名验证您的用户名/密码，系统更安全。在这种情况下，如果有人有你的秘密，无论如何，你的系统有其他安全问题的处理比别人做的假标记（即使如此，只是改变了秘密保证与老秘作出任何标记现在是无效的）。

The point of JWTs is essentially integrity. It provides a mechanism for your server verify that the token that was provided to it is genuine and was supplied by your server. The signature generated via your secret is what provides for this. So, yes, if your secret is leaked somehow, that individual can generate tokens that your server would think are its own. A token based system would still be more secure than your username/password system simply because of the signature verification. And in this case, if someone has your secret anyway, your system has other security issues to deal with than someone making fake tokens (and even then, just changing the secret ensures that any tokens made with the old secret are now invalid).

对于有效载荷，签名将只能告诉你，提供给您的令牌正是因为它是当你的服务器发送出去。验证显然，该有效载荷内容是为您的应用有效或合适的是由你。

As for payload, the signature will only tell you that the token provided to you was exactly as it was when your server sent it out. verifying the that the payloads contents are valid or appropriate for your application is obviously up to you.

有关您的问题：

1）。在我有限的经验，这绝对是更好地与第二个系统，以验证您的令牌。简单地验证签名只是意味着该令牌与你的秘密生成的。在某种DB（Redis的，内存缓存/ SQL /蒙戈，或者一些其他存储）​​的存储任何创建令牌是一种确保你只接受你的服务器创建令牌的一个很好的方式。在这种情况下，即使你的秘密被泄露，都不会有问题太多，因为任何生成的标记将无效反正。这是我和我的系统采用的方法 - 所有生成的标记都存储在一个数据库（Redis的），并在每次请求，我验证该标记是在我的数据库之前，我接受它。这样的令牌可以撤销以任何理由，如被释放到野外莫名其妙令牌，用户注销，密码修改，密改变等。

1.) In my limited experience, it's definitely better to verify your tokens with a second system. Simply validating the signature just means that the token was generated with your secret. Storing any created tokens in some sort of DB (redis, memcache/sql/mongo, or some other storage) is a fantastic way of assuring that you only accept tokens that your server has created. In this scenario, even if your secret is leaked, it won't matter too much as any generated tokens won't be valid anyway. This is the approach I'm taking with my system - all generated tokens are stored in a DB (redis) and on each request, I verify that the token is in my DB before I accept it. This way tokens can be revoked for any reason, such as tokens that were released into the wild somehow, user logout, password changes, secret changes, etc.

2）。这是我不具备太多的经验，是什么我仍在积极研究，因为我不是一个安全专家。如果您发现任何资源，随意张贴在这里！目前，我只是用私钥，我从磁盘加载，但显然这是远远最好的或最安全的解决方案。

2.) This is something I don't have much experience in and is something I'm still actively researching as I'm not a security professional. If you find any resources, feel free to post them here! Currently, I'm just using a private key that I load from disk, but obviously that is far from the best or most secure solution.

这篇关于为JWT令牌服务器端处理的最佳做法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！