JWT当然不是玩具，理解其设计意图，和适用场景自然会发现存在的就是有价值的
JWT: JSON Web Token
起源和定义
JWT（JSON Web Token）是由 IETF（Internet Engineering Task Force）基于 RFC 7519 规范定义的。它是一种用于在网络应用间传递信息的标准方法。JWT 最初由无状态的分布式应用场景需求而定义，以提供一种简洁的方式来传递信息，同时保证安全性。
JWT的结构
JWT 由三部分组成，它们使用点号（.）分隔开来：
-
Header（头部）：包含了令牌的元数据信息，例如算法和类型。
如{ "alg": "HS256", "typ": "JWT" } -
Payload（负载）：包含了要传递的用户数据，例如用户ID、角色等。
如{ "sub": "1234567890", "username": "exampleUser", "role": "admin" } -
Signature（签名）：对头部和负载进行签名，以确保消息的完整性。
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)其中，认证秘钥（secret）用于对签名进行验证和生成，确保令牌的真实性和完整性。密钥本身的安全非常重要，如果密钥泄漏那么签名本身等于裸奔
验证机制
JWT 的验证主要依赖于签名和有效期：
-
签名验证：接收方通过验证 JWT 中的签名来确保消息的完整性，防止篡改。
这一过程包括：
分离出Header和Payload并分别进行Base64Url解码。
使用Header中定义的算法和服务器的私有密钥对（Header + Payload）进行签名运算。
比较计算得出的签名与接收到的Token中的Signature部分是否一致。 -
有效期验证：接收方验证 JWT 的过期时间（exp），确保 JWT 在有效期内使用。
对Payload部分进行检查，包括但不限于：
过期时间（Expiration Time, exp）：确认Token未过期。
生效时间（Not Before, nbf）：确认Token已生效。
发行者（Issuer, iss） 和 受众（Audience, aud）：确认Token是由预期的发行者为预期的受众发布的。
处理流程
- 客户端请求：客户端在后续请求中携带JWT，通常放在Authorization HTTP头的Bearer模式下。
- 服务器响应：服务器提取JWT，按照上述步骤验证其签名和载荷的有效性。
- 授权决策：如果JWT验证通过，则服务器信任客户端提供的用户身份和权限信息，允许访问受保护的资源。
使用JWT认证流程图
安全考虑
- 服务器端保存的蜜钥不可泄漏，最好定期刷新
- 为了保持安全性，应设置合理的Token有效期，并提供Token刷新机制
- 考虑提供Token撤销机制：创建一个可分布式存储的黑名单（例如，Redis缓存、数据库表或其他高效存储解决方案），用于存储撤销的token的相关信息。这可能是整个JWT令牌，或者是JWT中的唯一标识符（如JTI，JWT ID），当想要撤销某个已经下发的 token就将它加入到名单。需要注意的是，验证的时候肯定是先去验证有效期，如果已经过期，不需要关注是否在黑名单。而且黑名单本身也会自动过期并删除即可，毕竟一支存放它浪费空间毫无意义
优点和缺点
优点：
- 无状态性：JWT 不需要服务器存储会话信息，减轻了服务器负担。传统方式下，我们需要将会话信息持久化到DB、缓存等服务中，每次都避免不了要获取才能验证。
- 跨域支持：JWT 可在不同域之间轻松传递信息。
- 安全性：JWT 使用签名验证消息完整性，防止数据篡改。
缺点：
- Token 大小：JWT 包含了额外信息，增加了网络传输负担。
- 无法撤销：JWT 一旦发放，无法撤销，除非设置短期过期时间。
- 不是那么安全：不能传递敏感信息，本身虽然签名但是荷载部分知识base64，当然可以选择使用一种对成签名算法来对荷载部分加密