JWT鉴权核心是每次请求校验签名、有效期及自定义声明；解析需显式启用jwt.WithExpirationRequired()等选项，middleware中须严格校验Bearer头并安全注入claims。
JWT鉴权的核心判断：它不是“登录即发token”，而是“每次请求都校验签名+有效期+自定义声明”
Go Web 里用 JWT，最容易错的地方是把 jwt.Parse 当成万能解码器——它只做解析和基础校验，不自动检查 exp、不验证 iss、也不拦截已注销的 token。真正起作用的是你手动调用 token.Valid 后的一系列判断逻辑。
用 github.com/golang-jwt/jwt/v5 解析并校验 token 的标准写法
注意 v4 升级到 v5 后，Parse 方法签名变了，且默认不再自动校验 exp 和 nbf。必须显式传入 jwt.WithValidMethods 和 jwt.WithExpirationRequired() 等选项。
func parseToken(tokenString string) (*jwt.Token, error) {
keyFunc := func(t *jwt.Token) (interface{}, error) {
if _, ok := t.Method.(*jwt.SigningMethodHMAC); !ok {
return nil, fmt.Errorf("unexpected signing method: %v", t.Header["alg"])
}
return []byte("your-secret-key"), nil
}
token, err := jwt.Parse(tokenString, keyFunc,
jwt.WithValidMethods([]string{"HS256"}),
jwt.WithExpirationRequired(),
jwt.WithIssuedAt(),
)
if err != nil {
return nil, err
}
if !token.Valid {
return nil, errors.New("token is invalid")
}
return token, nil
}
-
jwt.WithExpirationRequired()是关键：没有它，过期的 token 仍会返回token.Valid == true -
keyFunc必须返回interface{}，不能直接返回[]byte（v5 要求更严格） - 如果用了 RSA，
keyFunc应返回*rsa.PublicKey，且需提前加载 PEM 文件
在 HTTP middleware 中提取并验证 token 的常见陷阱
很多人直接从 r.Header.Get("Authorization") 取值，但漏掉前缀校验或空值处理，导致 panic 或静默失败。
- Authorization header 格式必须是
"Bearer xxx"，要切分并校验前缀 - token 字符串可能含空格、换行或 URL 编码，需先
strings.TrimSpace - 不要在 middleware 里直接
http.Error，应统一返回http.StatusUnauthorized并提前return - 解析失败时，别返回详细错误（如 “token expired”），避免泄露信息；统一返回
401 Unauthorized
func authMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
authHeader := r.Header.Get("Authorization")
if authHeader == "" {
http.Error(w, "missing Authorization header", http.StatusUnauthorized)
return
}
parts := strings.Split(authHeader, " ")
if len(parts) != 2 || parts[0] != "Bearer" {
http.Error(w, "invalid Authorization format", http.StatusUnauthorized)
return
}
token, err := parseToken(parts[1])
if err != nil {
http.Error(w, "invalid token", http.StatusUnauthorized)
return
}
// 把 user ID 或 claims 注入 context，供后续 handler 使用
ctx := context.WithValue(r.Context(), "user_id", token.Claims.(jwt.MapClaims)["user_id"])
next.ServeHTTP(w, r.WithContext(ctx))
})
}
如何安全地刷新 token 而不暴露 refresh token 泄露风险
JWT 本身不可撤销，所以 refresh token 必须单独存储、限制使用次数、绑定设备指纹，并走独立 endpoint。
- refresh token 不该和 access token 用同一密钥签名，建议用不同 secret 或 RSA 私钥
- refresh endpoint 必须要求原始 access token（用于校验当前会话有效性），再核对 DB 中的 refresh token 是否未失效、未被使用过
- 每次成功刷新后，旧 refresh token 必须立即失效（DB 标记为 used/expired）
- 不要把 refresh token 放在 localStorage —— 推荐用 httpOnly + Secure Cookie 存储
复杂点在于：access token 过期时间短（如 15 分钟），refresh token 过期时间长（如 7 天），但它的生命周期必须可主动终止。这需要服务端维护一个极简的 refresh token 白名单或黑名单（比如 Redis 中存 refresh_token → user_id + expires_at）。
