关于 JSON Web 令牌 (JWT) 的安全性和可靠性问题 [英] Security and reliability concerns about JSON Web Tokens (JWT)

查看:25
本文介绍了关于 JSON Web 令牌 (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):

  1. HTTP 基本身份验证(发送每个请求的用户名/密码)
  2. 基于令牌的身份验证(将 SHA1-ed 用户令牌存储在数据库中)
  3. JSON 网络令牌 (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 请求时,你 encrypt(base64(header) + "." + base64(payload)) 和你的 secret 并进行比较它带有令牌本身最后一部分提供的签名.它避免了必须执行数据库事务.

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 的担忧是否正确,或者我是否误解了它的功能?此外,即使我已经阅读了很多关于这些不同选项的内容,也可以随意链接任何可以启发我并帮助我做出更好选择的内容.谢谢.

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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆