无效的JSON Web令牌

app.get('/login', function(request, response) {
    var user = {username: request.body.username, password: request.body.password };
    // Validate somehow
    validate(user, function(isValid, profile) {
        // Create session token
        var token= createSessionToken();

        // Add to a key-value database
        KeyValueStore.add({token: {userid: profile.id, expiresInMinutes: 60}});

        // The client should save this session token in a cookie
        response.json({sessionToken: token});
    });
}

var jwt = require('jsonwebtoken');
app.get('/login', function(request, response) {
    var user = {username: request.body.username, password: request.body.password };
    // Validate somehow
    validate(user, function(isValid, profile) {
        var token = jwt.sign(profile, 'My Super Secret', {expiresInMinutes: 60});
        response.json({token: token});
    });
}

#1 楼

我也一直在研究这个问题，尽管以下所有想法都不是完整的解决方案，但它们可能会帮助其他人排除想法或提供进一步的想法。
1）只需从客户端中删除令牌
这对服务器端的安全性没有任何帮助，但是它确实通过删除令牌而阻止了攻击者（即，在注销之前，他们必须先窃取了令牌）。
2）创建一个令牌阻止列表
您可以存储无效令牌，直到它们的初始到期日期为止，然后将它们与传入请求进行比较。但是，这似乎可以消除完全基于令牌的原因，因为您将需要为每个请求触摸数据库。不过，存储空间可能会更小，因为您只需要存储注销和到期时间之间的令牌（这是一种直觉，并且绝对取决于上下文）。
3）只保留令牌到期时间缩短并经常轮换它们
如果您将令牌的到期时间保持在足够短的时间间隔内，并让运行中的客户端跟踪并在必要时请求更新，则数字1可以有效地用作完整的注销系统。这种方法的问题在于，它使得无法在关闭客户端代码之间保持用户登录状态（取决于您设置的到期间隔时间）。
应急计划
紧急情况或用户令牌遭到破坏时，您可以做的一件事是允许用户使用其登录凭据更改基础用户查找ID。这将使所有关联的令牌无效，因为将不再能够找到关联的用户。
我还想指出，最好将上次登录日期与令牌一起包含在内，这样您就可以能够在很长一段时间后强制重新登录。
关于使用令牌进行攻击的相似性/差异性，本文讨论了以下问题：https://github.com/dentarg/blog/blob/master/_posts/2014-01-07-angularjs-authentication-with-cookies -vs-token.markdown

#2 楼

上面发布的想法很好，但是使所有现有JWT失效的非常简单的方法就是更改机密。

如果服务器创建了JWT，请使用机密（JWS）对其进行签名然后将其发送给客户端，只需更改密钥即可使所有现有令牌失效，并要求所有用户获得新令牌进行身份验证，因为根据服务器，其旧令牌突然变得无效。

它不会不需要对实际令牌内容（或查找ID）进行任何修改。必需的（例如较短的令牌到期时间或使令牌中存储的密钥无效）。

#3 楼

这主要是一条长长的评论，以支持@mattway的答案并以此为基础。给出以下内容：此页面上的其他一些建议的解决方案主张在每次请求时都击中数据存储区。如果您访问主数据存储区以验证每个身份验证请求，那么我会发现使用JWT代替其他已建立的令牌身份验证机制的理由更少。本质上，您已使JWT成为有状态的，而不是每次都访问数据存储都变为无状态。可能还有其他用例。）

给出：

对于典型的现实世界Web应用程序，无法实现真正​​的无状态JWT身份验证，因为无状态JWT无法为以下重要用例提供立即和安全的支持：

用户的帐户已被删除/阻止/暂停。

用户的密码已更改。

用户的角色或权限已更改。

用户已被管理员注销。

站点更改了JWT令牌中的任何其他应用程序关键数据管理员。在这些情况下，您不能等待令牌到期。令牌失效必须立即发生。另外，您不能相信客户不要保留并使用旧令牌的副本，无论是否出于恶意目的。

因此：
我认为@ matt-way的回答是， ＃2 TokenBlackList是将所需状态添加到基于JWT的身份验证的最有效方法。与用户总数相比，令牌列表将非常小，因为它只需要保留列入黑名单的令牌，直到令牌到期为止。我可以通过将无效令牌放置在redis，memcached或另一个支持在密钥中设置过期时间的内存数据存储中来实现。

对于通过初始JWT身份验证的每个身份验证请求，您仍然必须对内存数据库进行调用，但是不必在其中存储整个用户组的密钥。 （对于给定的网站而言，可能不重要）。

#4 楼

我会在用户模型上记录jwt版本号。新的jwt令牌会将其版本设置为此。

验证jwt时，只需检查其版本号是否等于用户当前的jwt版本即可。用户jwt版本号。

#5 楼

还没有尝试过，它基于其他一些答案使用了大量信息。这里的复杂性是避免对用户信息请求的每次服务器端数据存储调用。大多数其他解决方案都需要对用户会话存储区的每个请求进行数据库查找。在某些情况下可以这样做，但这是为了避免此类调用并使所需的服务器端状态变得很小而创建的。您最终将重新创建服务器端会话，但是会话会话的规模很小，无法提供所有强制失效功能。但是，如果要执行此操作，请遵循以下要点：目标：减少数据存储的使用（无状态）。
可以强制注销所有用户。
可以随时强制退出任何个人的功能。
在一定时间后要求重新输入密码的功能。
可以与多个客户端一起使用的功能。当用户单击特定客户端的注销时，强制重新登录。 （为防止有人在用户离开后“删除”客户令牌，请参阅注释以获取更多信息）

解决方案：


使用短命（ <5m）访问令牌与寿命更长（几个小时）的客户端存储的刷新令牌配对。
每个请求都会检查auth或刷新令牌的到期日期是否有效。
当访问令牌过期时，客户端将使用刷新令牌来刷新访问令牌。
在刷新令牌检查期间，服务器会检查用户ID的小黑名单-如果发现拒绝刷新请求。
当客户端没有有效（未过期）的刷新或auth令牌时必须重新登录，因为所有其他请求都将被拒绝。
在登录请求时，请检查用户数据存储是否被禁止。
注销时-将用户添加到会话黑名单中，这样他们就必须重新登录。您必须存储其他信息，以免他们在多设备环境中从所有设备中注销，但是可以通过将设备字段添加到会话中来完成。用户黑名单。
要在x时间后强制重新输入-在auth令牌中保留上次登录日期，并根据请求进行检查。
要强制注销所有用户-重置令牌哈希密钥。

这要求您假设用户表中包含被禁止的用户信息，并在服务器上维护一个黑名单（状态）。无效的会话黑名单-是用户ID的列表。仅在刷新令牌请求期间才检查此黑名单。只要刷新令牌TTL，条目就必须存在。刷新令牌过期后，将要求用户重新登录。

缺点：


仍然需要对刷新令牌请求进行数据存储查找。
无效的令牌可能会继续作用于访问令牌的TTL。

优点：


提供所需的功能。
在正常操作下，对用户隐藏了刷新令牌操作。
只需要对刷新请求（而不是每个请求）进行数据存储查找。即每15分钟1次，而不是每秒1次。
将服务器端状态最小化到很小的黑名单。

使用此解决方案，不需要像reddis这样的内存数据存储，至少不需要用户信息，因为服务器仅每15分钟左右进行一次数据库调用。如果使用reddis，在其中存储有效/无效的会话列表将是一个非常快速和简单的解决方案。无需刷新令牌。每个身份验证令牌将具有一个会话ID和设备ID，它们可以在创建时存储在reddis表中，并在适当时失效。然后将对每个请求进行检查，并在无效时将其拒绝。

#6 楼

我一直在考虑的一种方法是在JWT中始终具有一个iat（在处发出）值。然后，当用户注销时，将该时间戳记存储在用户记录中。验证JWT时，只需将iat与上次注销的时间戳进行比较即可。如果iat较旧，则无效。是的，您必须去数据库，但是如果JWT有效，无论如何我都会一直拉用户记录。

我看到的主要缺点是它将记录它们如果它们是在多个浏览器中，或者也有移动客户端，则无需进行所有会话。部分检查可能与最后一次有效的iat时间的全局时间戳相对。

#7 楼

我来晚了一点，但是我想我有一个不错的解决方法。我还将发布的日期/时间存储在JWT中。验证令牌时，我检查密码在颁发令牌后是否已更改，并且即使令牌尚未过期也被拒绝。

#8 楼

------------------------回答这个问题有点晚了，但也许对某人会有帮助-----------

从客户端来看，最简单的方法是从浏览器的存储中删除令牌。

但是，如果您想销毁节点服务器上的令牌-

JWT软件包的问题在于它不提供销毁令牌的任何方法或方法。关于上文提到的JWT。但是在这里，我使用了jwt-redis。 -redis）完全重复了库jsonwebtoken的全部功能，但有一个重要的补充。 Jwt-redis允许您将令牌标签存储在redis中以验证有效性。 Redis中没有令牌标签会使令牌无效。要销毁jwt-redis中的令牌，有一种销毁方法

它以这种方式工作：

1）从npm安装jwt-redis

2）创建-

var redis = require('redis');
var JWTR =  require('jwt-redis').default;
var redisClient = redis.createClient();
var jwtr = new JWTR(redisClient);

jwtr.sign(payload, secret)
    .then((token)=>{
            // your code
    })
    .catch((error)=>{
            // error handling
    });

3）验证-

jwtr.verify(token, secret);

4）销毁-

jwtr.destroy(token)

注意：您可以在令牌登录期间像JWT中提供的一样提供expiresIn。帮助某人

#9 楼

您可以在数据库的用户文档/记录上有一个“ last_key_used”字段。在对令牌进行签名时将其添加到有效负载中。

当用户使用令牌登录时，请检查数据库中的last_key_used以匹配令牌中的令牌。

然后，例如，当用户注销时，或者您要使令牌无效时，只需将“ last_key_used”字段更改为另一个随机值，随后的任何检查都将失败，从而迫使用户使用user登录并再次通过。 br />

#10 楼

为什么不只使用jti声明（立即）并将其作为用户记录字段存储在列表中（取决于数据库，但至少用逗号分隔的列表就可以了）？无需单独查找，就像其他人指出的那样，无论如何您都希望获得用户记录，因此您可以为不同的客户端实例拥有多个有效令牌（“注销到处”可以将列表重置为空）

#11 楼

保持这样的内存列表

user_id   revoke_tokens_issued_before
-------------------------------------
123       2018-07-02T15:55:33
567       2018-07-01T12:34:21

如果令牌在一周内到期，则清除或忽略早于该记录的记录。还仅保留每个用户的最新记录。
列表的大小将取决于您保留令牌的时间以及用户撤销令牌的频率。
仅在表更改时才使用db。应用程序启动时将表加载到内存中。

#12 楼

每个用户字符串都是唯一的，并且将全局字符串哈希在一起作为JWT机密部分允许单个和全局令牌无效。在请求身份验证期间以数据库查找/读取为代价的最大灵活性。由于它们很少更改，因此也易于缓存。

这里是一个示例：

HEADER:ALGORITHM & TOKEN TYPE

{
  "alg": "HS256",
  "typ": "JWT"
}
PAYLOAD:DATA

{
  "sub": "1234567890",
  "some": "data",
  "iat": 1516239022
}
VERIFY SIGNATURE

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload), 
  HMACSHA256('perUserString'+'globalString')
)

where HMACSHA256 is your local crypto sha256
  nodejs 
    import sha256 from 'crypto-js/sha256';
    sha256(message);

示例用法请参见https：// jwt.io（不确定它们是否处理动态256位机密）

#13 楼

为令牌提供1天的到期时间
维护每日黑名单。
将无效的/注销的令牌放入黑名单中。如果令牌未过期，则先过期，然后再将其列入黑名单。

对于长时间的会话需求，应该有一种延长令牌到期时间的机制。

#14 楼

晚会之后，经过一些研究，下面给出了我的两分钱。
在注销期间，请确保正在发生以下事情... br />分别在发生登录或注销时更新用户表的上次登录日期时间和注销日期时间。因此，登录日期时间应始终大于注销时间（如果当前状态为登录状态且尚未注销，则注销日期时间为null）

这比保留其他黑名单表并定期清除要简单得多。多设备支持需要附加表来保持登录状态，登出日期以及一些其他详细信息，例如操作系统或客户端详细信息。

#15 楼

我是通过以下方式做到的：


生成unique hash，然后将其存储在redis和您的JWT中。这可以称为会话



我们还将存储特定JWT发出的请求数-每次将jwt发送到服务器时，我们都会增加请求整数。 （这是可选的）




因此，当用户登录时，将创建唯一的哈希，将其存储在redis中并注入到您的JWT中。

当用户尝试访问受保护的端点时，您将从JWT中获取唯一的会话哈希，查询redis并查看是否匹配！

我们可以扩展此范围，并使我们的JWT更加安全，方法如下：

每个X都请求特定的JWT，我们会生成一个新的唯一会话，并将其存储在我们的JWT中，然后将前一个列入黑名单。

，这意味着JWT不断变化，并停止了过时的JWT被黑客入侵，被盗等。

#16 楼

如果要撤消用户令牌，可以跟踪数据库中所有已颁发的令牌，并检查它们是否在会话表中有效（存在）。
缺点是您将在每个请求上都命中数据库。

我还没有尝试过，但是我建议使用以下方法来允许令牌撤销，同时将数据库命中率保持在最低水平-

数据库检查费率，根据确定性关联将所有已发行的JWT令牌划分为X组（例如，由用户ID的第一位数字组成10组）。创建令牌时创建的时间戳。例如，{ "group_id": 1, "timestamp": 1551861473716 }

服务器将所有组ID保留在内存中，并且每个组将具有一个时间戳，指示何时是属于该组的用户的最后一次注销事件。 ，{ "group1": 1551861473714, "group2": 1551861487293, ... }

带有JWT令牌且组时间戳较旧的请求将被检查有效性（数据库命中），如果有效，则将发出具有新时间戳的新JWT令牌以供客户将来使用。
如果令牌的组时间戳是新的，则我们信任JWT（无数据库命中）。如果令牌具有旧的组时间戳，则使用数据库，而将来的请求只有在用户组中的某人退出后才会得到验证。
我们使用组来限制时间戳更改的次数（例如，有一个用户像没有明天一样登录和注销-仅会影响有限数量的用户，而不是每个用户）
我们限制了组的数量，以限制保存在内存中的时间戳数量。只需将其从会话表中删除，并为用户组生成新的时间戳即可。

#17 楼

如果“从所有设备注销”选项是可接受的（在大多数情况下是这样）：


将令牌版本字段添加到用户记录中。
将此字段中的值添加到JWT中存储的声明中。
每次用户注销时都增加版本。
在验证令牌时，将其版本声明与存储在用户记录中的版本进行比较，如果不相同，则拒绝。

在大多数情况下，需要执行一次数据库访问以获取用户记录无论如何，这样不会增加验证过程的开销。与维护黑名单不同，在黑名单中，由于需要使用联接或单独的调用而导致数据库负载很大，因此清理旧记录等。

#18 楼

Kafka消息队列和本地黑名单
我考虑过使用像kafka这样的消息传递系统。让我解释一下：
例如，您可以拥有一个微服务（称为userMgmtMs服务），该微服务负责login和logout并产生JWT令牌。然后，此令牌将传递给客户端。
现在，客户端可以使用此令牌来调用不同的微服务（将其称为pricesMs），在priceMs内将没有数据库检查到users表，从中初始创建令牌被触发了。该数据库仅存在于userMgmtM中。此外，JWT令牌还应包含权限/角色，以便priceMs无需从数据库中查找任何内容即可使弹簧安全性正常工作。由JWT令牌中提供的数据创建（显然没有密码）。
那么，如何注销或使令牌无效？由于我们不想在每次请求priecesMs时都调用userMgmtMs数据库（这会引入很多不必要的依赖关系），因此解决方案是使用此令牌黑名单。
而不是将黑名单保留在中心并具有依赖关系在所有微服务的一个表上，我建议使用kafka消息队列。此外，它将带有此令牌内容的kafka事件发送到预订了所有其他微服务的内部kafka服务。
一旦其他微服务收到kafka事件，它们也会将其也放置在其内部黑名单中。
即使某些微服务在注销时已关闭，它们最终仍将再次启动，并在以后的状态下接收消息。
由于kafka是经过开发的，因此客户可以参考自己阅读过的消息，因此可以确保没有任何客户，不管是up还是up，都不会错过任何这种无效令牌。
我唯一想到的唯一问题是kafka消息传递服务将再次引入单点故障。但这是相反的，因为如果我们有一个全局表，其中保存了所有无效的JWT令牌，并且此数据库或微服务已关闭，则无效。使用kafka方法+对于普通用户注销，客户端删除JWT令牌后，在大多数情况下，kafka的停机时间甚至不会引起注意。由于黑名单是作为内部副本在所有微服务之间分发的。在这种情况下，将秘密作为最后的手段可以有所帮助。还是只是在执行此操作之前确保kafka已经启动。所以我在考虑另一种解决方案。
请让我知道您的想法，这有意义还是有明显的原因使它无法解决？

#19 楼

下面的方法可以提供两全其美的解决方案：
让“立即”表示“〜1分钟”。
情况：


用户尝试成功登录：
A.在令牌中添加一个“发出时间”字段，并根据需要保留到期时间。
B.存储用户密码的哈希值
或在用户表中创建一个新字段，例如tokenhash。
将令牌哈希值存储在生成的令牌中。


用户访问网址：
A.如果“发出时间”在“立即”范围内，请正常处理令牌。不要更改“发出时间”。根据“立即”的持续时间，这是一个易受攻击的持续时间。但是，像一两分钟这样的短持续时间不应太危险。 （这是性能和安全性之间的平衡）。三无须打这里的数据库。
B.如果令牌不在“立即”范围内，请对照数据库检查令牌哈希。如果还可以，请更新“发出时间”字段。如果还不行，则不要处理该请求（安全性最终得到加强）。


用户更改令牌哈希以保护帐户。在“即时”将来，该帐户将受到保护。


，我们将数据库查找保存在“即时”范围内。在“立即”持续时间内从客户端发送。

#20 楼

使用JWT的刷新...
我实用的一种方法是存储刷新令牌（可以是GUID）和对应的刷新令牌ID（无论完成多少刷新都不会更改） ）添加到数据库中，并在生成用户的JWT时将其添加为对用户的声明。可以使用数据库的替代方式，例如。内存缓存。但是我在这个答案中使用数据库。
然后，创建一个JWT刷新Web API端点，客户端可以在JWT到期之前调用它。调用刷新时，请从JWT中的声明中获取刷新令牌。
在对JWT刷新端点的任何调用上，请在数据库上将当前刷新令牌和刷新令牌ID验证为一对。生成一个新的刷新令牌，并使用该刷新令牌ID来替换数据库上的旧刷新令牌。请记住，它们是可以从JWT中提取的声明。
从当前JWT中提取用户的声明。开始生成新的JWT的过程。用新生成的刷新令牌替换旧的刷新令牌声明的值，该刷新令牌也已新保存在数据库中。因此，生成新的JWT并将其发送给客户端。
因此，在使用了刷新令牌之后，无论是由目标用户还是攻击者，任何其他尝试使用/刷新令牌的尝试，如果未在数据库上与其刷新令牌ID配对，则不会导致生成新的JWT，因此将阻止具有该刷新令牌ID的任何客户端再使用后端，从而导致完全注销此类客户端客户（包括合法客户）。
说明基本信息。
接下来要添加的内容是有一个窗口，用于刷新JWT的时间，以便该窗口之外的任何事物都是可疑活动。例如，窗口可以是JWT到期前的10分钟。生成JWT的日期时间可以保存为该JWT本身中的声明。并且当发生这种可疑活动时，即，当其他人尝试在窗口内或窗口内使用刷新令牌ID后，该令牌已在窗口中使用时，应将刷新令牌ID标记为无效。因此，即使刷新令牌ID的有效所有者也必须重新登录。
在数据库中找不到与提供的刷新令牌ID配对的刷新令牌意味着，刷新令牌ID应无效。因为闲置的用户可能会尝试使用例如攻击者已经使用的刷新令牌。
在目标用户之前，被攻击者窃取并使用的JWT也会被标记为无效用户也尝试使用刷新令牌，如前所述。
唯一没有解决的情况是，即使攻击者可能已经窃取了客户端，客户端也从未尝试刷新其JWT。但是，这种情况不太可能发生在不受攻击者监管的客户端上，这意味着攻击者无法预测客户端何时停止使用后端。
如果客户端启动通常的注销。应该注销以从数据库中删除刷新令牌ID和相关记录，因此，可以防止任何客户端生成刷新JWT。

#21 楼

不使用刷新JWT ...
会想到两种攻击情形。一种是关于受损的登录凭据。另一种是JWT的实际盗窃。
对于受损的登录凭据，当发生新登录时，通常会向用户发送电子邮件通知。因此，如果客户不同意登录，则建议他们重置凭据，这应该将密码的上次设置时间保存到数据库/缓存中（在下次登录时也要设置此时间）用户在初始注册时设置密码）。只要授权了用户操作，就应该从数据库/缓存中获取用户更改密码的日期时间，并将其与生成给定JWT的日期时间进行比较，并禁止在该日期之前生成的JWT的操作。 -凭证重置时间，因此实质上使这种JWT变得无用。这意味着将JWT的生成日期时间保存为JWT本身的声明。在ASP.NET Core中，可以使用策略/要求进行此比较，并且在失败时，将禁止客户端。因此，每当凭证重置完成时，这都会在后端注销全局用户。但是，在JWT到期之前可以采取什么措施阻止攻击者呢？这是实际的全局注销。它类似于上面针对凭证重置所述的内容。为此，通常将用户发起全局注销的日期时间保存在数据库/缓存中，并在授权用户操作时将其获取，并将其与给定JWT的生成日期时间进行比较，并禁止该操作用于在上述全局注销日期时间之前生成的JWT，因此实际上使此类JWT变得无用。可以使用ASP.NET Core中的策略/要求来完成此操作，如前所述。
现在，您如何检测JWT的盗窃案？我现在的答案是偶尔提醒用户全局注销并再次登录，因为这肯定会使攻击者注销。

#22 楼

我要回答的是，当我们使用JWT时是否需要从所有设备功能中注销。这种方法将对每个请求使用数据库查找。因为即使服务器崩溃，我们也需要持久性安全状态。在用户表中，我们将有两列


LastValidTime（默认值：创建时间）
已登录（默认值：true）

是来自用户的注销请求，我们会将LastValidTime更新为当前时间，并将Logged-In更新为false。如果有登录请求，我们将不会更改LastValidTime，但Logged-In将设置为true。

创建JWT时，我们将在有效负载中包含JWT创建时间。当我们授权服务时，我们将检查3个条件


JWT有效吗？ br />
让我们看一个实际的情况。

用户X有两个设备A，B。他在晚上7点使用设备A和设备B登录到我们的服务器。到期时间为12小时）。 A和B都具有创建时间为JWT的JWT：晚上7点

，晚上9点，他丢失了设备B。他立即从设备A注销。这意味着现在数据库X用户条目的LastValidTime为“ ThatDate： 9：00：xx：xxx”，并以“假”身份登录。输入是错误的，所以我们不允许。

晚上10点，X先生从他的设备A登录。现在设备A的JWT创建时间为：晚上10点。现在，数据库Logged-In设置为“ true”

在晚上10：30，Mr.Thief尝试登录。即使Logged-In为true。数据库中的LastValidTime是晚上9点，但是B的JWT已将时间创建为晚上7点。因此，将不允许他访问该服务。因此，在没有密码的情况下使用设备B时，一台设备注销后他将无法使用已创建的JWT。

#23 楼

IAM解决方案，例如Keycloak（我已经尝试过），提供了令牌撤销端点，例如
/realms/{realm-name}/protocol/openid-connect/revoke

如果您只是想注销用户代理（或用户），您也可以调用一个端点（这只会使令牌无效）。同样，对于Keycloak，依赖方只需要呼叫端点

/realms/{realm-name}/protocol/openid-connect/logout

如果您想了解更多，请链接

#24 楼

另一种选择是只为关键的API端点提供一个中间件脚本。
如果管理员使令牌无效，则该中间件脚本将在数据库中检入。必须立即完全阻止用户访问。

#25 楼

在此示例中，我假设最终用户也有一个帐户。如果不是这种情况，则其余方法不太可能起作用。
创建JWT时，将其持久保存在与登录帐户相关联的数据库中。这确实意味着JWT，您可以提取有关用户的其他信息，因此根据环境的不同，可能不行。
在每次请求之后，您不仅要执行（我希望）随附的标准验证，无论您使用哪种框架（用于验证JWT均有效），它还包括诸如用户ID或其他令牌（需要与数据库中的令牌匹配）之类的东西。
注销时，删除cookie（如果使用），并使数据库中的JWT（字符串）无效。如果无法从客户端删除cookie，那么至少注销过程将确保令牌被销毁。
我发现这种方法与另一个唯一标识符一起使用（因此，数据库，并且可用于前端），因此会话非常灵活

#26 楼

如果没有DB查找每个令牌验证，这似乎很难解决。我能想到的另一种方法是在服务器端保留一个无效令牌的黑名单。每当发生更改以在重新启动期间持久保留更改时，都应在数据库上更新该更新，方法是使服务器在重新启动时检查数据库以加载当前黑名单。

但是，如果将其保存在服务器内存中（某种全局变量），则如果使用多个服务器，则无法在多台服务器上进行扩展，因此在这种情况下，可以将其保持打开状态一个共享的Redis缓存，应该进行设置以将数据持久保存在某个地方（数据库，文件系统？），以防万一必须重新启动它，并且每次启动新服务器时，都必须订阅Redis缓存。

替代黑名单，使用相同的解决方案，您可以使用每个会话的redis中保存的哈希来完成此操作，正如其他答案所指出的那样（不确定如果许多用户登录，这样做会更有效虽然如此）。

听起来很复杂吗？

免责声明：我尚未使用Redis。

#27 楼

如果您使用的是axios或类似的基于Promise的http请求库，则只需在.then()部分内部的前端销毁令牌即可。用户执行此功能后，它将在response .then（）部分中启动（来自服务器端点的结果代码必须可以，200）。用户在搜索数据时单击此路由后，如果数据库字段user_enabled为false，将触发销毁令牌，并且用户将立即注销并停止访问受保护的路由/页面。当用户永久登录时，我们不必等待令牌过期。

function searchForData() {   // front-end js function, user searches for the data
    // protected route, token that is sent along http request for verification
    var validToken = 'Bearer ' + whereYouStoredToken; // token stored in the browser 

    // route will trigger destroying token when user clicks and executes this func
    axios.post('/my-data', {headers: {'Authorization': validToken}})
     .then((response) => {
   // If Admin set user_enabled in the db as false, we destroy token in the browser localStorage
       if (response.data.user_enabled === false) {  // user_enabled is field in the db
           window.localStorage.clear();  // we destroy token and other credentials
       }  
    });
     .catch((e) => {
       console.log(e);
    });
}

#28 楼

我只是将令牌保存到用户表中，当用户登录时，我将更新新令牌，并且当auth等于用户当前的jwt时。 br />