有关JSON Web令牌(JWT)的安全性和可靠性问题 [英] Security and reliability concerns about JSON Web Tokens (JWT)
问题描述
我正在为个人项目创建API和SPA，并且在以下用于验证用户身份的解决方案之间犹豫不决(请注意:通过HTTPS):
I'm creating an API along with a SPA for a personal project and I'm hesitating between the following solutions to authenticate users (note: over HTTPS):
- HTTP基本身份验证(在每个请求中发送用户名/密码)
- 基于令牌的身份验证(在数据库中存储SHA1编码的用户令牌)
- JSON Web令牌(JWT)身份验证
我什至不考虑使用OAuth，因为这似乎很痛苦，而且我不需要与其他应用程序进行身份验证，我只关心对用户进行身份验证.
I don't even consider OAuth cause it seems like a real pain plus I don't need to authenticate with other apps, I'm only concerned about authenticating users.
从我读到的内容来看，JWT似乎正在成为一个不断发展的标准.它基本上保存了调用方的数据，因此每次调用方发出API请求时，您都将您的 secret encrypt(base64(header)+." + base64(payload))它带有令牌本身最后一部分中提供的签名.这样可以避免执行数据库事务.
From what I've read, JWT seems to be a growing standard. It basically holds the caller's data so everytime he makes an API request you encrypt(base64(header) + "." + base64(payload)) with your secret and you compare it with the signature provided in the last part of the token itself. It avoids having to perform DB transactions.
问题是，如果我使用JWT 1)，则无法手动撤消特定令牌，并且大多数情况下 2)如果我更改了用户的权限，则先前授予的JWT仍将保留具有其旧权限的旧数据，只要他没有通过其新权限获得新令牌，就可以授予/限制他对某些数据的连续访问.确实有问题，我感到惊讶的是我还没有看到任何人提到这个问题.而且， 3) JWT声称允许服务器验证访问权限而无需访问数据库，但是我无法想象任何不以某种方式不涉及数据库的API请求，即使只是返回用户数据要求.因此，这种说法对我来说毫无意义.
The problem is that if I use JWT 1) I have no possibility to manually revoke specific tokens, and most of all 2) if I change a user's permissions, the previously granted JWT will still have the old data with his old permissions which could grant/restrict him continuous access to some data as long as he doesn't get a new token with his new permissions, which is really problematic and I'm surprised I haven't seen anyone mentionning this problem yet. Moreover, 3) JWT claims to allow the server to validate access without having access to DB but I can't imagine any API request that doesn't involve the database somehow, if only to return data the user asked for. So this argument doesn't make any sense to me.
对我来说，目前最好的选择是选择2 .网站的流量将受到限制和限制，因此将令牌存储在数据库中似乎是一个很小且值得的权衡，并且允许我使用这些令牌进行任何我想做的事情，包括管理其生命周期和权限.如果用户将相同的凭据用于其他在线服务，还可以避免像选项1中那样暴露用户的凭据.
To me, my best option right now is option 2. Website will have restricted and small traffic so storing tokens in the Database seems like a small and worthwhile trade-off and allow me to do anything I want with these tokens, including managing their lifecycle and permissions. It also avoids exposing the users' credentials like in option 1, in case they use the same ones for other online services.
我只想知道我对JWT的关注是否正确，或者我是否误解了JWT的功能?同样，即使我已经阅读了很多有关这些不同选项的内容，也可以随时链接可以启发我并帮助我做出更好选择的任何内容.谢谢.
I just want to know if my concerns about JWT are right or if I misunderstood its functioning? Also, even if I've already read a lot about these different options, feel free to link anything that could enlight me and help me make a better choice. Thanks.
推荐答案
您是正确的，在到期之前使令牌无效是一个常见的JWT问题.需要考虑以下几个原因:删除/阻止/暂停帐户，更改密码，更改权限，由管理员注销用户.
You are right and invalidating tokens before expiration time is a common JWT problem. There are several reason to consider: account deleted/blocked/suspended, password changed, permissions changed, user logged out by admin.
使用JWT，您还可以设置令牌黑名单来存储注销与登录之间的令牌.到期时间，标记为过期并在每个请求中进行检查.您只能包含ID(JWT的 jti 声明)或使用上次登录日期和 iat 声明(发布于)
With JWT, you can also set a token blacklist to store tokens that were between logout & expiry time, mark expired and check it in every request. You can include only the ID (jti claim of JWT) or use the last login date and the iat claim (issued at)
当用户更改其密码/权限时使令牌失效的另一种技术是使用这些字段的哈希值对令牌进行签名.如果字段值更改，则任何先前的令牌将自动无法验证.
Other technique to invalidate tokens when user changes their password/permissions is signing the token with a hash of those fields. If the field value changes, any previous tokens automatically fail to verify.
请参见 https://stackoverflow.com/a/37520125/6371459
最后，请注意，令牌是使用服务器私钥(未加密)签名的
Finally, be aware that the token is signed with server private key (not encrypted)
sign(base64(header) + "." + base64(payload))
这篇关于有关JSON Web令牌(JWT)的安全性和可靠性问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
