节点js，JWT令牌和逻辑背后
我正在使用JWT来保护节点js https://github.com/auth0/express-jwt
要创build一个JWT令牌用户会话，我只需要：
-> auth/signup -> jwt.sign(user_profile,secret,expireInMinutes:{900000000 /*almost never expires*/}); 或者在login电话的情况下
-> auth/login -> jwt.sign(user_profile,secret,expireInMinutes:{900000000 /*almost never expires*/});
每次调用受保护的url时，我都会检查由JWT中间件自动设置的req.user 。
现在我想知道：
1 – 调用sign（）时，JWT标记存储在哪里？
2 – 我必须validation（）令牌每次被保护的url被称为？ 如果是，为什么？
3 – 当我为已经签名的用户设置一个新的令牌时，旧的令牌（如果存在）被删除？ 如果到期没有设立，或者是5年如果呢？
4 – 为什么我不能在同一个浏览器/应用程序页面上设置新的令牌？ 我得到无效的签名错误，如果我注册一个新的令牌，但令牌匹配（我检查）这就像我不能在同一浏览器上签署超过1个用户
您必须已经使用之前的其他用户的回复来找出您以前所有问题的答案，但是我也会尝试为其他用户解决一些问题：
1 – 调用sign（）时，JWT标记存储在哪里？
当你调用sign时，签名的token不会存储在任何地方，它是由sign函数返回的，那么你必须把它发送给客户端，这样就可以存储在客户端。 （如会话存储，本地存储或cookie）
2 – 我必须validation（）令牌每次受保护的url被称为？ 如果是，为什么？
是的你是。 这个想法一旦客户端拥有令牌，他们会在每次发出请求时将令牌发送给服务器。 令牌由服务器处理以确定特定客户端是否已经被authentication。
3 – 当我为已经签名的用户设置一个新的令牌时，旧的令牌（如果存在）被删除？ 如果到期没有设定，或者是5年如果？
与第1点的答案略有关系。调用符号函数只会生成另一个标记。 令牌的到期存储在签名令牌本身内。 因此，每次服务器从客户端获取令牌时，都会将过期作为令牌validation的一部分进行检查。 需要注意的是，签名标记只是在签名过程中作为参数传入的“user_profile”对象，以及添加到该对象的额外字段（如过期date）。
所以客户端可以有多个令牌存储在客户端。 只要还没有到期，他们都是有效的。 然而，这个想法是只有当老客户过期后才再给客户端发送令牌。
4 – 为什么我不能在同一个浏览器/应用程序页面设置新的令牌？ 我得到无效的签名错误，如果我注册一个新的令牌，但令牌匹配（我选中）这就像我不能在同一浏览器上签署超过1个用户
这个想法是每个浏览器有1个用户。 因为在这种情况下浏览器是客户端。 我不能想到你需要每个浏览器/客户端有多个用户的用例，所以你显然做错了。 这并不是说不可能发送多个令牌到同一个浏览器/客户端。
-
您需要将令牌存储在客户端（本地存储或cookie）
-
是。 HTTP是无状态的。 如果您不validation每次都有人可以在没有令牌或无效令牌的情况下调用您的URL。 如果您担心性能，HMACSHA256检查速度非常快。
-
这是没有道理的，你一定是做错了什么。
2 – 我必须validation（）令牌每次受保护的url被称为？ 如果是，为什么？
是。 但“validation”是一个有点令人困惑的术语。
- 当客户端调用/authentication时，服务器首先根据数据库validation用户凭证以使该用户通过authentication。 而这个“昂贵的”操作对整个令牌生命只进行一次。 然后，服务器准备JSON对象，保存有用的用户信息，并encryption它以获得JWT令牌。
- 该令牌只向客户端发送一次，存储在浏览器中，然后在每个客户端请求发送回服务器到/ api。
- 在处理客户端/ API请求期间，服务器必须“validation”令牌的有效性（JWT为您执行）。 但这并不意味着再次检查数据库的用户凭据。 只有解密令牌才能获得JSON对象，HMAC-SHA256validation – 相当快。
- 让JSON对象具有有用的用户信息（声明），服务器可以允许或不允许这个特定的用户访问/ apipath下所请求的资源。
在令牌validation期间，不需要检查用户凭证的数据库，因为服务器必须信任已接收和validation（已成功解密）的令牌。 不需要服务器会话存储来识别用户。
您可以将JWT令牌想像为简单的会话信息，以encryption的forms存储在客户端上。 但是，如果您需要在用户会话信息中caching更多的数据，我认为，您仍然需要在服务器上存储某种会话存储，与传统的会话ID相比，JWT的想法几乎没有用处。
抱歉。 这应该是对以前的答复评论，但我没有足够的代表评论，所以他去
@sbaang：每次validation的另一个原因是令牌中可能有一些有趣的“claim2”，比如允许用户访问特定的端点，而不是全部。因此，在每次validation中，您不仅validation用户是否被允许访问受保护的API，但是该特定端点不是基于具有有效令牌，而是具有专门允许该令牌的令牌。