刷新令牌必须是随机字符串吗？能否使用JWT库生成刷新令牌？

你观察到的25位及以上长度的随机字符串是刷新令牌的经典实现形式，这类方案依赖服务端存储随机串与对应绑定的用户身份、过期时间、权限范围等信息的映射关系，校验时必须查询数据库或缓存才能完成验证。而使用和访问令牌相同的JWT方案生成刷新令牌，确实能带来校验便捷的优势，也完全符合安全规范。

JWT形式刷新令牌的核心优势 #

• 支持半无状态校验：无需每次校验都查询服务端存储，通过JWT签名即可快速验证令牌合法性，直接读取payload内的用户ID、过期时间、绑定客户端标识等信息，校验流程更轻量高效
• 可灵活承载自定义业务字段：可以将刷新次数限制、权限范围、令牌签发版本等信息直接存入payload，前置校验逻辑不需要额外查询存储就能执行，比如发现请求客户端和payload内绑定的客户端ID不匹配时可以直接拒绝
• 实现成本更低：如果访问令牌已经在使用JWT方案，可以直接复用现有JWT库的签名、校验逻辑，不需要单独开发一套随机串生成、存储、校验的配套逻辑

使用JWT作为刷新令牌的注意事项 #

• 不要在payload内存储敏感信息：JWT的payload仅为Base64编码，未做加密处理，不要存放用户隐私、密钥等敏感内容
• 单独配置过期规则：刷新令牌的有效期通常远长于访问令牌，签发时要单独设置exp（过期时间）字段，不要和访问令牌共用过期配置
• 配套实现黑名单机制：JWT本身不支持主动作废，遇到用户主动登出、账号封禁、令牌泄露等场景时，需要将对应JWT的jti（JWT唯一标识）存入黑名单缓存，校验时先查黑名单，存在对应标识直接拒绝请求
• 区分签名密钥：刷新令牌和访问令牌要使用不同的签名密钥，避免其中一类令牌的密钥泄露，影响另一类令牌的安全性

内容的提问来源于stack exchange，提问作者Овов Очоы