golang如何实现无状态认证方案_golang无状态认证方案实现方案

先说几个核心判断：JWT（JSON Web Token）是Go语言实现无状态认证的基石，但直接套用示例代码，大概率会在生产环境出问题。密钥硬编码、exp校验失败、中间件透传丢失上下文、Token被重放——这些都不是“跑通就行”的小麻烦。

JWT的核心结构，说白了就是Header.Payload.Signature这三部分。Header声明类型和算法，Payload里放声明（注意，这只是Base64URL编码，不是加密），Signature确保完整性。数据都是明牌，但怎么用，区别很大。

jwt.Parse() 必须与 ParseWithClaims 和 SigningMethod.KeyFunc 配合使用

你猜最容易栽在哪儿？是调用 jwt.ParseUnverified() 解析payload后，手动判断 exp。这等于主动放弃签名验证，攻击者可以任意修改 user_id 或 exp，伪造一个看起来合法的token。

正确的做法始终是：用 jwt.ParseWithClaims()，并且确保 KeyFunc 返回的密钥类型跟签名算法匹配。具体来说：

• HS256：必须返回 []byte，不能传字符串。从环境变量读取时，要用 []byte(os.Getenv("JWT_SECRET"))。
• RS256：KeyFunc 需要返回 *rsa.PublicKey，而私钥签名时要用对应的 *rsa.PrivateKey。
• 校验时如果密钥类型搞错了（比如HS256传了个rsa.PublicKey），jwt.ParseWithClaims() 会静默失败，token.Valid 为false，但 err 可能是nil。这很要命，因为代码如果只检查 err，就会误以为token有效。

AuthMiddleware 中必须显式注入 context 并校验 token 有效性

很多中间件只做了解析，没检查 token.Claims.(jwt.MapClaims)["user_id"] 是否存在，或者忽略了 token.Header["alg"] 是否被篡改为 none（这是一个已知漏洞）。

关键逻辑一步都不能省：

• 先通过 strings.TrimPrefix(tokenStr, "Bearer ") 剥离前缀，再用 strings.TrimSpace() 清空两端空格。
• 解析后必须同时判断 err == nil 和 token.Valid == true，二者缺一不可。
• 把用户标识写入 c.Request.Context()（Gin框架）或 r.Context()（net/http），而不是 c.Set() 这类框架内部存储，避免handler里取不到。
• 如果使用自定义的 UserClaims 结构体，务必实现 Valid() 方法来校验 exp、nbf 等标准字段。

refresh token 不该用 JWT 实现，而应走服务端存储 + 单次失效

把refresh token也做成JWT是一个典型误区。JWT无法主动作废，一旦泄露，就等于给了攻击者一张长期通行证。

生产环境应该这么干：

• refresh token存在Redis里，key用 refresh:，value存关联的user_id和过期时间。
• 签发新access token时，生成唯一的 jti，存其SHA256哈希到Redis，并设置跟refresh token一样的TTL。
• 每次使用refresh token，先查Redis是否存在且未被标记为已使用，成功后立即 DEL 这个key，做到一用即废。
• access token的 exp 控制在15–60分钟，refresh token的TTL控制在7天以内。

最容易被忽略的是时钟偏移处理。服务端和客户端系统时间差超过1秒，exp 就会校验失败。别调服务器时间，改用 jwt.WithLeeway(5 * time.Second) 传入 ParseWithClaims 的选项参数，这才是省心又靠谱的做法。