对于我正在从事的一个新的node.js项目，我正在考虑从基于cookie的会话方法(我的意思是，将id存储到用户浏览器中包含用户会话的键值存储中)切换到使用JSON Web Tokens (jwt)的基于令牌的会话方法(没有键值存储)。
这个项目是一个利用socket的游戏。IO——在一个会话(web和socket.io)中有多个通信通道的情况下，有一个基于令牌的会话会很有用。
如何使用jwt方法从服务器提供令牌/会话失效?
我还想了解使用这种范例应该注意哪些常见的(或不常见的)陷阱/攻击。例如，如果这种模式容易受到与基于会话存储/cookie的方法相同/不同类型的攻击。
所以，假设我有以下内容(改编自this和this):
会话存储登录:
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});
});
}
--
会话存储方法的注销(或失效)需要更新KeyValueStore
使用指定的令牌创建数据库。
在基于令牌的方法中似乎不存在这样的机制，因为令牌本身将包含通常存在于键值存储中的信息。
我也一直在研究这个问题，虽然下面的想法都不是完整的解决方案，但它们可能会帮助其他人排除这些想法，或者提供进一步的解决方案。
1)简单地从客户端删除令牌
显然，这对服务器端安全没有任何帮助，但它确实通过删除令牌来阻止攻击者。他们必须在登出之前窃取令牌)。
2)创建一个令牌区块列表
您可以将无效令牌存储到它们最初的到期日期，并将它们与传入的请求进行比较。这似乎否定了首先完全基于令牌的原因，因为每个请求都需要访问数据库。存储大小可能会更小，因为您只需要存储注销时间和到期时间之间的令牌(这是一种直觉，而且肯定取决于上下文)。
3)保持代币到期时间短，并经常轮换
如果您将令牌过期时间保持在足够短的间隔内，并让运行中的客户端保持跟踪并在必要时请求更新，那么第1条将有效地作为一个完整的注销系统。这种方法的问题是，它不可能在客户端代码关闭之间保持用户登录(取决于您设置的过期间隔多长时间)。
应急计划
如果出现紧急情况，或者用户令牌被破坏，您可以做的一件事是允许用户使用其登录凭据更改底层用户查找ID。这将使所有关联的令牌无效，因为将不再能够找到关联的用户。
我还想指出，在令牌中包含最后一次登录日期是个好主意，这样您就可以在一段时间后强制重新登录。
关于使用令牌的攻击的相似/不同之处，这篇文章解决了这个问题:https://github.com/dentarg/blog/blob/master/_posts/2014-01-07-angularjs-authentication-with-cookies-vs-token.markdown
使用刷新jwt…
我采用的一种比较实用的方法是在数据库中存储一个刷新令牌(可以是GUID)和对应的刷新令牌ID(无论进行多少次刷新都不会改变)，并在生成用户的JWT时将它们作为用户的声明添加。可以使用数据库的替代方案，例如内存缓存。但我用的是数据库。
然后，创建一个JWT刷新Web API端点，客户机可以在JWT到期之前调用该端点。当调用刷新时，从JWT中的声明中获取刷新令牌。
在对JWT刷新端点的任何调用中，在数据库上验证当前刷新令牌和刷新令牌ID为一对。生成一个新的刷新令牌，并使用刷新令牌ID替换数据库上的旧刷新令牌。记住它们是可以从JWT中提取出来的声明
从当前JWT中提取用户的声明。开始生成一个新的JWT的过程。将旧的刷新令牌声明的值替换为新生成的刷新令牌，该刷新令牌也是新保存在数据库上的。完成所有这些后，生成新的JWT并将其发送给客户端。
因此，在使用了刷新令牌之后，无论是目标用户还是攻击者，在数据库上使用未与其刷新令牌ID配对的/刷新令牌的任何其他尝试都不会导致生成新的JWT，从而阻止任何拥有该刷新令牌ID的客户端不再能够使用后端，从而导致此类客户端(包括合法客户端)的完全注销。
这解释了基本信息。
The next thing to add to that is to have a window for when a JWT can be refreshed, such that anything outside that window would be a suspicious activity. For example, the window can be 10min before the expiration of a JWT. The date-time a JWT was generated can be saved as a claim in that JWT itself. And when such suspicious activity occurs, i.e. when someone else tries to reuse that refresh token ID outside or within the window after it has already been used within the window, should mark the refresh token ID as invalid. Hence, even the valid owner of the refresh token ID would have to log in afresh.
如果在数据库上找不到与所提供的刷新令牌ID配对的刷新令牌，则表明刷新令牌ID应该无效。因为空闲用户可能会尝试使用攻击者已经使用过的刷新令牌。
如前所述，在目标用户之前被攻击者窃取和使用的JWT，在用户尝试使用刷新令牌时也会被标记为无效。
唯一没有涉及的情况是，即使攻击者可能已经窃取了JWT，客户端也从未尝试刷新它。但是这种情况不太可能发生在不受攻击者监管(或类似)的客户端上，这意味着攻击者无法预测客户端何时停止使用后端。
如果客户端发起常规注销。应该通过注销从数据库中删除刷新令牌ID和相关记录，从而防止任何客户端生成刷新JWT。
