17370845950

应选golang-jwt/jwt/v5，因jwt-go已归档且存在alg:none漏洞；golang-jwt修复安全问题、API更清晰、算法支持更全、错误类型更明确。

Token鉴权该用 jwt-go 还是 golang-jwt

直接选 golang-jwt/jwt/v5。原 jwt-go 项目已归档，v4 及之前版本存在未修复的 alg:none 绕过漏洞和反序列化隐患，且不再接收安全更新。golang-jwt 是社区维护的正式继任者，API 更清晰，对 Ed25519、RS384 等算法支持更完整，错误类型也做了区分（比如 jwt.ErrTokenExpired 而非笼统的 ValidationError）。

实操建议：

• 初始化时显式指定签名方法：jwt.SigningMethodHS256，避免依赖默认或运行时推断
• 解析 Token 必须校验 aud（受众）和 iss（签发者），尤其在多租户或网关透传场景下
• 使用 ParseWithClaims 并传入自定义 jwt.Claims 结构体，而非泛型 map[string]interface{}，便于字段类型检查和 IDE 提示

如何在 Gin 中统一拦截并注入用户上下文

Gin 的中间件是自然选择，但关键在于「不提前解析、不重复解析、不泄露敏感字段」。常见错误是中间件里直接调 c.Set("user_id", ...) 后在 handler 里强转，一旦 Token 无效就 panic；或者每次请求都重新解析同一串 Token 字符串，浪费 CPU。

实操建议：

• 用 c.Request.Header.Get("Authorization") 提取 Bearer Token，空值或格式不符直接返回 401
• 解析成功后，把完整 *jwt.Token 和解析出的 claims 一起存入 c.Request.Context()，而不是塞进 c 的键值对 —— 避免被下游中间件意外覆盖
• 写一个 MustGetUser 工具函数，在 handler 内部安全取值：

  func MustGetUser(c *gin.Context) (uint64, error) {
      token, ok := c.Request.Context().Value("jwt_token").(*jwt.Token)
      if !ok || !token.Valid {
          return 0, errors.New("invalid token context")
      }
      claims, ok := token.Claims.(jwt.MapClaims)
      if !ok {
          return 0, errors.New("invalid claims type")
      }
      uid, ok := claims["uid"].(float64)
      if !ok {
          return 0, errors.New("missing or invalid uid claim")
      }
      ret
  urn uint64(uid), nil
  }

Refresh Token 怎么设计才不被滥用

Refresh Token 不是延长 Access Token 有效期的快捷方式，而是用于可控的凭证轮换。典型陷阱是：把 Refresh Token 存在前端 localStorage、不绑定设备指纹、不限制单次使用、不记录失效时间。

实操建议：

• Refresh Token 必须 HttpOnly + Secure + SameSite=Strict 的 Cookie 返回，禁止 JS 访问
• 数据库中需持久化存储其哈希值（如 sha256(refresh_token + salt)）、关联的 user_id、expires_at 和 used_at（首次使用时间）
• 每次用 Refresh Token 换新 Access Token 时，必须同时作废旧 Refresh Token，并生*新的一对（即“滚动刷新”），防止长期泄露
• Access Token 过期时间建议 ≤ 15 分钟，Refresh Token 过期时间 ≤ 7 天，且登录态活跃时才允许刷新

服务间调用要不要再验 Token

要，但方式不同。内部服务（如 OrderSvc → UserSvc）若走内网直连，不应再走完整 JWT 解析流程，而应由 API 网关统一完成鉴权，并通过轻量 header（如 X-Auth-User-ID: 123、X-Auth-Role: "buyer"）透传可信身份信息。

实操建议：

• 网关层验证 JWT 后，用内部密钥对用户 ID 和角色做一次短时效加密（如 AES-GCM，ttl=60s），写入 X-Internal-Auth header
• 下游服务只解密并校验这个 header 的时效与 MAC，不查 Redis、不验签名公钥、不访问 Keycloak
• 禁止任何内部服务直接解析原始 Authorization header —— 这意味着它绕过了网关策略（如限流、审计、RBAC）

最易被忽略的是：跨服务传递时忘记清理原始 Authorization header，导致下游误以为这是终端用户直连，从而执行了不该有的权限逻辑。