动态授权令牌必须加密存储、严格时效控制并绑定上下文，因其明文存储会导致数据库泄露后被直接冒用，违反owasp asvs 2.1.2和gdpr第32条；须用chacha20-poly1305等aead算法加密，密钥独立管理，每token配唯一nonce，解密后内存清零；同时绑定设备指纹与ip，拒绝跨端复用，并通过goroutine定时+后台cron双重清理过期token。
动态授权令牌（如 OAuth2 access_token、JWT）不能存数据库主表或日志里，必须加密存储 + 严格时效控制 + 绑定上下文
为什么不能直接存 raw token 字符串
很多开发者把 access_token 当成普通字符串塞进 MySQL 的 users.tokens 字段，这是高危操作：一旦数据库泄露，攻击者可直接用该 token 冒充用户调用第三方 API；token 若含敏感 scope（如 https://www.googleapis.com/auth/drive.file），危害更大。更糟的是，部分 OAuth2 提供商（如 GitHub）返回的 token 是长期有效的，没过期时间，靠人工轮换极不可靠。
- token 本身不是密码，但等价于“临时密码+权限凭证”
- 明文存储违反 OWASP ASVS 2.1.2 和 GDPR 第32条“适当安全措施”要求
- 日志中打
token或Authorization: Bearer xxx头会留下永久痕迹，必须脱敏
加密存储必须用 AEAD 模式，别碰 AES-CBC
用 golang.org/x/crypto/chacha20poly1305 或 golang.org/x/crypto/nacl/secretbox —— 它们自带认证加密（AEAD），能同时保证机密性与完整性。AES-CBC 没认证标签，容易被 padding oracle 攻击篡改。
- 密钥必须独立管理：不硬编码，走环境变量或 Vault；每条 token 用唯一 nonce（可用
crypto/rand.Read生成 24 字节） - 加密后存入字段如
encrypted_token（BLOB 或 base64 string），原始access_token、refresh_token、expires_in全部丢弃 - 解密只在需要调用下游 API 前一刻做，且解密后立即从内存清零（
bytes.Equal后用bytes.ReplaceAll覆盖）
绑定设备指纹和 IP，拒绝跨端复用
OAuth2 token 本质是“授权委托”，不是“身份证明”。同一用户在手机端拿的 token，不该能在桌面浏览器里直接使用——这能大幅降低 token 泄露后的横向移动风险。
- 生成加密 token 时，把
sha256(user_agent + remote_ip + os_version)作为附加数据（additional data）传给 AEAD 加密函数 - 每次解密前校验当前请求的
User-Agent和X-Forwarded-For是否匹配原始指纹，不匹配直接拒绝 - 对
refresh_token尤其要严：每次刷新都生成新 fingerprint，并使旧 refresh_token 失效（存 Redis 做单次有效标记）
自动清理过期 token，别依赖 TTL 字段
光靠数据库里的 expires_at 时间戳不够：如果服务宕机几小时，期间过期的 token 可能仍被误用。必须有主动清理机制。
- 用
time.AfterFunc启动延迟清理 goroutine：解密 token 后，按expires_in设置定时器，到期后调用deleteFromStorage()删除加密 blob - 同时配一个后台 cron job（如每 5 分钟执行一次），扫描
encrypted_token表中created_at 的记录强制清除（防 goroutine 漏杀） - 注意：JWT 类型 token 不适用此法，因其无状态，只能靠短有效期（≤30 分钟）+ 黑名单兜底
真正麻烦的不是加解密，而是让每个 token 都带上上下文约束并确保它只活在该上下文里。漏掉设备绑定或清理逻辑，再强的加密也白搭。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
