Token | 清弦子@博客

理解1

在使用JSON Web Tokens（JWT）时，Token的生成和验证并不依赖于服务器的状态。也就是说，Token一旦生成，除非过期或被显式吊销，否则它的有效性不会因服务重启、服务中断或其他外部因素而改变。让我们逐步解释这个机制的工作原理和相关问题。

JWT的生成

在您提供的代码中，JWT的生成过程如下：

使用用户信息加密：jwt.sign(user, config.jwtSecretKey, {expiresIn: '10h'})这行代码中，jwt.sign方法用config.jwtSecretKey密钥对user信息进行加密，生成一个JWT。这个JWT设置了10小时的有效期限。

返回Token：生成的JWT（即Token）随后被发送给客户端，通常通过在响应头或响应体中返回。

JWT的验证

当客户端在随后的请求中携带此Token（一般放在请求头Authorization中），服务器会使用相同的密钥config.jwtSecretKey来验证这个Token。

验证过程包括检查签名是否有效（确保Token未被篡改），以及检查Token是否过期。

对服务重启的影响

服务重启对JWT的影响：理论上，JWT的验证过程并不依赖于服务的运行状态。只要Token未过期，并且提供的密钥config.jwtSecretKey保持不变，那么即使服务重启，之前生成的Token仍然有效。

jwtSecretKey的重要性：config.jwtSecretKey用于签名JWT。只要这个密钥保持一致，就可以验证任何使用该密钥生成的Token。如果jwtSecretKey发生变化（例如，在服务重启后更改了密钥），那么之前使用旧密钥生成的Token将无法验证通过，因为签名不再匹配。

机制的原理

JWT机制基于不对称加密或对称加密。在你的例子中，使用的是对称加密，因为jwtSecretKey同时用于生成Token和验证Token。JWT包含三部分：

Header（头部）：通常描述JWT使用的算法（如HMAC SHA256）。

Payload（负载）：包含声明，即传输的信息。虽然它可以用来存放任何信息，但不应该将敏感信息放在这里，因为Base64编码不是一种加密机制。

Signature（签名）：由Base64编码的Header和Payload，加上一个secret（jwtSecretKey），通过一个事先定义好的算法生成。这个签名用于验证Token的合法性。

结论

只要jwtSecretKey保持不变，服务重启不应对之前生成的JWT的有效性产生影响。

为了安全，JWT设置了过期时间，以确保即使Token被泄露，也无法长期被滥用。

在实际应用中，jwtSecretKey应该保持安全，并且不要轻易更改，以避免使所有已发行的Token失效。

理解2

JSON Web Tokens（JWT）在生成后，并不需要在服务器端保存。这就是JWT相比于其他需要服务器端保存会话状态（如Session ID）的认证机制，更加轻量和便于扩展的原因之一。让我们来具体解析JWT的存储和有效性保证的原理。

Token的存储位置

客户端存储：

在发放JWT给客户端之后，JWT通常存储在客户端的某个地方。常见存储方案包括：

浏览器的Cookie：简单易用，但需要注意安全和HttpOnly等标志的设置。
Local Storage或Session Storage：HTML5提供的浏览器存储机制，比Cookie灵活，但需要注意防范XSS攻击。
安全的HTTP头：最典型的就是放在Authorization HTTP请求头中，但需要注意每次请求都需要把这个Token附在HTTP请求头中发送回服务器。

服务器端并不存储Token：

服务器端不会存储JWT本身。服务器只需保留签发JWT时所使用的密钥（或者公钥）即可。这样，在接收到客户端请求时，服务器可以使用这个密钥来验证JWT签名的合法性。

保证Token的有效性

Token的有效期：

在JWT生成时，可以通过设置expiresIn或exp来指定JWT的有效期。这个有效期定义了JWT的生存周期，超过这个时间，JWT就应该被客户端丢弃，无法再用来进行认证。

Token的验证：

当客户端携带JWT发起请求时，服务器使用事先约定好的密钥（或公钥）对JWT的签名进行验证。如果签名验证通过，并且JWT未过期，服务器就会认为这个请求是合法的。

如何处理Token

生成和发放：当用户登录或其他需要认证的操作成功时，服务器生成一个JWT，并发回给客户端。

客户端使用：客户端在每次请求时，需要将JWT包含在HTTP请求中（通常是在Authorization头部）。

服务器验证：对于每个携带JWT的请求，服务器会验证JWT的签名和有效期，以确认请求的合法性。

服务器与Token的交互

虽然服务器不存储JWT本身，但服务器端代码需要知道JWT签发时使用的密钥（或者对于RSASSA算法，使用对应的公钥）。这样才能验证JWT的有效性。

服务器还可以实现一些额外的逻辑，比如黑名单机制（虽然JWT规范本身不支持撤销），或者在数据库中记录JWT的签发情况，以追踪和分析用户行为等。

总结

JWT的机制允许在不需要服务器端存储的情况下，实现用户的认证和状态管理。通过在客户端存储JWT，并在每个请求中附带这个Token，同时让服务器端验证Token的有效性，JWT提供了一种轻量级的、无状态的方法来管理用户的认证和授权。

理解三

个人理解：登陆时生成token，我们将token放在Authorization请求头上，而token里面包含用户的信息和token的有效起始时间和有效结束时间，之后通过解析出来，再与之匹配。

1. 用户登录和Token生成

当用户通过提供的用户名和密码成功登录后，服务器生成一个JSON Web Token（JWT）。这个JWT包含了以下信息：

用户信息：通常包含用户ID、用户名或其他用户属性，但请注意，避免将敏感信息放入JWT的负载中，因为JWT的负载部分在解密后是可读的。

Token的有效起始和结束时间：通过在生成JWT时设置expiresIn或直接设置exp（过期时间戳）来实现。这定义了JWT的有效期，确保了Token只能在指定时间内有效。

签名：使用服务器端的密钥（jwtSecretKey）对前面提到的信息进行签名。这个签名保证了JWT的完整性，确保了JWT在传输过程中未被篡改。

2. 发送Token给客户端

一旦JWT生成，服务器会将其发送给客户端。通常，这个JWT会放在登录成功的响应中返回给客户端。

3. 客户端存储和使用Token

客户端接收到JWT后，一般会在后续的所有请求中将其带上。最常见的方式是放在HTTP请求头Authorization字段中，格式通常为Bearer <token>。这样，客户端每发起一个请求，服务器就可以从请求头中提取和验证JWT。

4. 服务器端验证Token

对于携带JWT的每个请求，服务器会：

提取JWT：从请求头的Authorization字段中提取出JWT。

验证签名：使用保存的密钥（jwtSecretKey）来验证JWT签名的合法性，确保JWT是来自自己的服务器并且未被篡改。

检查有效期：检查JWT是否过期。如果当前时间早于JWT的起始有效时间或晚于结束有效时间，JWT就是无效的。

解析负载信息：如果签名验证通过且Token在有效期内，服务器就可以信任JWT中包含的用户信息，进而处理请求。

5. 基于Token的用户认证

通过上述步骤，服务器确认了请求的合法性，并可以基于JWT中包含的用户信息来处理请求。这种无状态的认证机制使得JWT在web应用和API认证中非常流行。

总结

在用户登录时生成包含用户信息和有效期的JWT，然后客户端在每个请求中通过Authorization请求头带上这个Token。服务器通过验证这个Token来确认用户的身份和请求的合法性，进而处理请求。这种方法既简单又安全，尤其适合于分布式和无状态的RESTful应用。