我将 token 存储在客户端的 session /本地存储上。我面临的问题是，一旦用户复制该 token 并将其用于其他已登录的 session 服务，它就会起作用，但它应该在JWT.varify上返回无效的 token 。
用户注销后，是否有任何方法可以Blacklist/Delete/Expire当前使用的 token ？
最佳答案
有几种方法可以为此目的建立黑名单:
1)(数据库中的黑名单用户)为用户添加一个数据库列isTokenExpired，并在成功登录时将其设置为false；如果要使 token 失效(例如，当用户更改密码，注销，或足够的时间已过期)。
上面的方法将达到您的目的，但我认为这是对编程的侮辱。我假设您正在使用JWT，以便用户不必每次都登录，并且只有一台服务器正在执行身份验证以及所有其他服务器功能。尽管JWT不是为“ session ”设计的，但为此目的使用JWT可以减轻数据库的负担。但是，如果您随后在每个用户操作上设置并检查另一个数据库标志，那么您将再次添加该负载，并且您仍然拥有与JWT等关联的所有负载，因此您最好对每个用户操作重新进行身份验证。
2)(在服务器RAM中将用户/ token 列入黑名单)当我自己研究此问题(如何使单个 token 无效)时，我发现了一些解决方案，其中服务器在RAM中维护白名单或黑名单，因此无需添加数据库或文件加载。这可能是一个更好的解决方案，但是我不记得任何促进此操作的库的名称。也许其他人可以提及其中一些。
3)将 token 设置为非常短的到期时间(例如60秒或5分钟)并将客户端设置为每隔(〜55秒或〜4分钟50秒)自动请求一个新 token 。然后，服务器将以我假设您现在正在执行的相同方式来检查和验证 token ，而无需访问数据库，然后将为所有其他字段生成具有相同值的新 token ，但使用新的“到期时间” ”值，然后将该 token 发送回客户端，客户端将用这个新的JWT替换其JWT，然后重新启动其5分钟计时器。这是其他选择之间的良好平衡，并保留了使用JWT的一些好处，但确实增加了一些小成本。我认为对于许多应用程序来说这是一个很好的解决方案，但是它绝对取决于特定的应用程序，但是它有些hacky，而且绝对不是“正确的方法”。
4)使用JWT + session 这是“正确的方法”。经过很长时间的研究，我意识到 JWT并非旨在用于维护 session :JWT只是表示声明的一种安全方式。想象一下，拥有一个拥有数千万用户的大型系统，并且您需要在全局范围内使用许多服务器。您可能有3个身份验证服务器(在美国，澳大利亚，英国)。然后，用户会将其用户名和密码发送到身份验证服务器，在该服务器中将检查数据库中的详细信息，如果有效，则会将其发送给JWT。然后，您可能还会有10多个常规服务器来处理您的API。然后，客户端将使用其JWT向API服务器发出每个请求。 API服务器将拥有认证服务器用来生成JWT的 key 的副本，并将验证您的声明。您的声明是“我已通过身份验证”。然后，此API服务器将生成一个 session ，并且客户端将被“登录”。可以将JWT设置为在5分钟后过期。如果用户在这5分钟内未登录，则将无法登录。如果登录，则将登录，直到API服务器将其踢出。每当发生会导致您想要踢用户的事情时，API服务器都可以关闭 session 。即使对于单服务器应用程序，这仍然是正确的方法。 JWT不是用于 session 的，而您(完全和我一样)开始注意到这些看似无法解决的问题，因为您正在使用JWT进行 session 。
无论如何，我建议3或4，这两个选项对于许多应用程序都具有净正值。
1和2似乎比它们提供的 yield 带来更多的问题。
但是，当然，它始终取决于应用程序。如果您只是以5美元的价格在fiverr上建立一个网站，那么无论做什么，您知道我的意思吗？
如果有更好的解决方案，我也想知道!请记住，JWT代表一项 claim ，并仔细考虑您的客户代表的 claim 。
关于node.js - jsonwebtoken存储在服务器nodejs中的位置。用户注销后如何使JWT过期，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48334052/