Token生成必须绑定明确scope和过期时间，按最小权限切分（如"user:read"）、硬编码有效期，JWT校验exp/nbf并NTP同步，payload仅存不可逆标识，opaque token用随机字符串存DB，secret须32字节以上且环境隔离管理，配合短时效token+refresh token实现吊销。
token 生成必须绑定明确的 scope 和过期时间
不设 scope 的 token 就像没锁门的保险柜——哪怕用了 secrets.token_urlsafe()，只要权限泛化、长期有效，就等于把系统入口敞开了。scope 要按最小权限原则切分，比如 "user:read" 和 "user:write" 必须分离；过期时间不能靠“先发着再说”，得在生成时硬编码进 payload（JWT）或数据库字段（opaque token）。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
datetime.utcnow() + timedelta(hours=1)算过期时间，别依赖客户端传入或环境变量配置 - scope 字符串统一小写、冒号分隔、无空格，避免
"User:Read"或"user read"这类不一致写法 - JWT 场景下，务必校验
exp和nbf，且服务端时间需 NTP 同步，否则会莫名失效
不要在 token 里塞敏感字段或可推导信息
有人习惯把 user_id、email、role 直接明文塞进 JWT payload，结果前端一解码全看见——这不是授权，是裸奔。更糟的是用 user_id + 时间戳拼接再哈希当 token，攻击者批量注册就能反推生成逻辑。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- JWT payload 只放不可逆标识，比如
"jti"（唯一 token ID），查库关联真实用户 - opaque token 更省心：用
secrets.token_hex(32)生成随机字符串，只存 DB，不带任何业务含义 - 绝对禁止在 token 中存放密码哈希、API 密钥、手机号后四位等能辅助撞库的信息
对称加密签发 JWT 时，secret 必须足够长且隔离管理
HS256 看似简单，但用 "mysecret123" 当 secret，等于给攻击者送字典。一旦 secret 泄露，所有 token 都可伪造；若多个服务共用同一 secret，一个服务沦陷就全盘崩塌。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- secret 至少 32 字节，用
secrets.token_urlsafe(48)生成，别手敲 - 不同环境（dev/staging/prod）用不同 secret，通过
os.getenv("JWT_SECRET_KEY")注入，不硬编码 - secret 不进 Git：加进
.gitignore，CI/CD 用 secrets manager 注入，本地用.env（确保不提交）
token 吊销机制不能只靠过期时间
用户改密码、登出、设备异常时，token 还没过期就得立即作废。光靠删客户端 cookie 或清 localStorage 没用——攻击者手里那个 token 还能继续调接口。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 短生命周期 token（如 15 分钟）+ refresh token（7 天），refresh token 存 DB 并绑定
fingerprint（UA + IP 哈希），每次换新都更新 - 高频敏感操作（如转账）强制二次验证，不复用已有 token
- 吊销列表（RBL）慎用：高并发下查 DB 成瓶颈，可用 Redis 存
"jti:expired"布尔值，TTL 对齐 token 过期时间
