对于我正在从事的一个新的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的刷新…
我想到了两种袭击的场景。一个是关于登录凭证的泄露。另一个是对JWT的盗窃。
For compromised login credentials, when a new login happens, normally send the user an email notification. So, if the customer doesn't consent to being the one who logged in, they should be advised to do a reset of credentials, which should save to database/cache the date-time the password was last set (and set this too when user sets password during initial registration). Whenever a user action is being authorized, the date-time a user changed their password should be fetched from database/cache and compared to the date-time a given JWT was generated, and forbid the action for JWTs that were generated before the said date-time of credentials reset, hence essentially rendering such JWTs useless. That means save the date-time of generation of a JWT as a claim in the JWT itself. In ASP.NET Core, a policy/requirement can be used to do do this comparison, and on failure, the client is forbidden. This consequently logs out the user on the backend, globally, whenever a reset of credentials is done.
For actual theft of JWT... A theft of JWT is not easy to detect but a JWT that expires easily solves this. But what can be done to stop the attacker before the JWT expires? It is with an actual global logout. It is similar to what was described above for credentials reset. For this, normally save on database/cache the date-time a user initiated a global logout, and on authorizing a user action, get it and compare it to the date-time of generation of a given JWT too, and forbid the action for JWTs that were generated before the said date-time of global logout, hence essentially rendering such JWTs useless. This can be done using a policy/requirement in ASP.NET Core, as previously described.
现在，你如何发现JWT被盗?目前我对此的回答是，偶尔提醒用户全局注销并重新登录，因为这肯定会让攻击者注销。
Kafka消息队列和本地黑名单
我想过使用像kafka这样的消息系统。让我解释一下:
例如，您可以有一个微服务(我们称之为userMgmtMs服务)，它负责登录和注销，并生成JWT令牌。然后将这个令牌传递给客户端。
现在客户端可以使用这个令牌来调用不同的微服务(让我们称之为pricesMs)，在pricesMs中，将没有数据库检查用户表，从这个表中触发了最初的令牌创建。该数据库只能存在于userMgmtMs中。此外，JWT令牌应该包括权限/角色，这样pricesm就不需要从DB中查找任何东西来允许spring安全性工作。
JwtRequestFilter可以提供一个UserDetails对象，该对象由JWT令牌中提供的数据创建(显然没有密码)，而不是去到pricesMs中的DB。
那么，如何注销或使令牌失效呢?由于我们不想在每次请求priecesm时都调用userMgmtMs的数据库(这会引入很多不必要的依赖关系)，因此解决方案可以使用这个令牌黑名单。
我建议使用kafka消息队列，而不是保持这个黑名单集中，并依赖于所有微服务的一个表。
userMgmtMs仍然负责注销，一旦注销完成，它就会把它放入自己的黑名单(一个微服务之间不共享的表)。此外，它还将带有此令牌内容的kafka事件发送到订阅了所有其他微服务的内部kafka服务。
一旦其他微服务接收到kafka事件，它们也会将其放入内部黑名单。
即使一些微服务在注销时关闭了，它们最终也会重新启动，并在稍后的状态下接收消息。
由于kafka是这样开发的，客户端有他们自己的引用，他们读了哪些消息，确保没有客户端，down或up将错过任何这些无效的令牌。
The only issue again what I can think of is that the kafka messaging service will again introduce a single point of failure. But it is kind of reversed because if we have one global table where all invalid JWT tokens are saved and this db or micro service is down nothing works. With the kafka approach + client side deletion of JWT tokens for a normal user logout a downtime of kafka would in most cases not even be noticeable. Since the black lists are distributed among all microservies as an internal copy.
在关闭的情况下，你需要使一个被黑客攻击的用户无效，kafka宕机了，这就是问题开始的地方。在这种情况下，作为最后的手段改变秘密可能会有所帮助。或者在这样做之前确保卡夫卡已经起床了。
免责声明:我还没有实现这个解决方案，但不知怎么的，我觉得大多数提议的解决方案都否定了JWT令牌的想法，因为它有一个中央数据库查找。所以我在考虑另一种解决方案。
请让我知道你的想法，它是有意义的还是有一个明显的原因为什么它不能?
