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