Token的应用场景
JWT
- JWT由三部分组成：头部（Header）、有效载荷（Payload）和签名（Signature）
- 头部通常指定了Token的类型和使用的哈希算法；有效载荷包含了一系列的声明，例如用户的ID、Token的发行者和过期时间；签名用于验证消息的完整性和确保Token没有被篡改
- JWT通常用作访问Token，用户登录后会收到一个JWT，之后每次请求需要访问受保护的资源时都需要携带该JWT
- 优点: 由于Token自包含（即包含了所有用户状态信息），这减少了服务器查数据库的需要
- 缺点: 存储在客户端，如果Token被截获将会暴露所有用户信息
Token一旦被发出就无法在服务器端废除它（即除非过期，否则一直有效）
双token机制
- 适用场景：用户登录权限
- 用户首次成功登录后，服务端生成两个令牌：access_token 和 refresh_token。
refresh_token 拥有比 access_token 更长的有效期，用于在 access_token 过期时进行刷新 - 服务端将两个令牌返回给用户，用户将它们储存起来以便之后使用
- 用户在之后的每个请求中将 access_token 放入请求的授权头（Authorization header），以便服务端验证用户的身份及有效性
- 如果服务端检测到 access_token 已失效，它会返回相关的错误响应（如HTTP 401状态码）
- App在接收到令牌失效的响应后，不会直接通知用户，而是自动使用储存的 refresh_token 向服务端发起请求，请求新的 access_token
- 服务端接收 refresh_token，验证其有效性，然后生成新的 access_token（和可选的 refresh_token），并将它们返回给用户
- 这一步骤中，服务端可能只返回新的 access_token，或同时返回新的 access_token 和 refresh_token，具体取决于安全策略和令牌的生命周期管理
- 用户使用新的 access_token 继续他们的请求，而服务端继续验证新令牌的有效性
主从token机制
- 适用场景：支付/转账场景
- 当用户1首次请求支付订单时，服务端为该次交易生成一个唯一的主令牌（master_token）
- 服务端将生成的master_token返回给用户1，用户1需要保存这个令牌以完成接下来的支付过程
- 当用户2请求支付订单，且此时用户1的master_token已经过期时，服务端会生成一个新的master_token，已过期的master_token不会被立即废弃，而是作为备用令牌（backup_token）被存储起来
- 服务端将新生成的master_token返回给用户2，用户2同样需要将此令牌保存以用于支付
- 用户1使用其保存的（现在已过期的）master_token尝试进行支付，服务端检测到该令牌无效后，会尝试验证之前存储为backup_token的过期令牌，如果backup_token有效，服务端允许支付动作完成
- 用户2使用其有效的master_token进行支付，服务端校验成功后允许支付动作完成
- 当用户3请求支付订单时，与用户2被发放的master_token也已经过期，服务端重复前面的过程：生成新的master_token，且旧的master_token转变为backup_token