这是一个noob问题。我正在使用nodejs处理一个rest api服务。我读过关于代币的文章。我不明白网站是如何识别用户的。想想这个。我的终端有特定于用户的数据。现在，用户登录，我使用数据库验证他/她的凭据。然后我返回一个令牌给它。现在在后续的请求中只有令牌到达，那么我如何知道必须访问哪个用户的数据
您可以使用JSON Web Token来存储一些用户基本数据(如ID或角色)。
然后，这是流程：
- 用户登录并检索JWT
- 令牌存储在用户的localStorage或cookie中
- 在每个下一个请求中，您需要在HTTP标头
Authorization中发送令牌 - 对于每个请求，您需要在后端检查此令牌
- 要注销，您只需要删除localStorage中的令牌或cookie
它没有魔力，令牌必须存储在某个地方，在现代架构中，我们通常使用DB，因为我们正在远离会话，因为我们必须考虑横向扩展，在横向扩展中，跨服务器的会话管理会出现问题。
下面是你可以做的
- 登录后返回用户令牌并将该令牌保存在用户集合中(？)
- 后续调用将在标头中包含该令牌
- 使用该令牌查询用户集合，看看它是有效的用户还是有效的令牌。对于每次通话，您还可以维护时间戳，确保两次通话之间的持续时间不应超过设定的持续时间。因此模拟服务器会话。尽管这是可选的
但是，如果您使用mongoDB，可能还有其他方法。
- 为会话维护一个单独的集合，在文档中保存令牌和其他详细信息(用户代理、ip等)
- 在token字段上放置一个唯一的索引
- 维护一个时间戳字段，我们称之为sessionTimeOut，并在该字段上添加一个TTL索引，持续设置的时间(比如1小时)
- 现在，下次在标头中获得令牌时，使用令牌尝试将sessionTimeOut字段更新(而不是追加)额外的设置持续时间(1小时)
- 检查写入结果中更新了多少条记录，如果为0条记录，则表示会话已过期，因此请向客户端发送相应的消息以再次登录
- 如果它更新了一条记录，则会话将再延长1小时
该模型的优点是很少
- 在任何时候，你都可以看到谁都登录了
- 如果您将其作为一个有上限的集合，您可以定义应用程序中一次可以登录的用户数量。(尽管没有必要)
- 在每次调用的用户验证中，您的用户表不会受到不必要的影响，特别是如果您将基本的用户详细信息放入与令牌相关的集合中
- TTL索引会删除过期的用户，因此集合永远不会太大